2024/01/22までの原文変更点を反映。

original-en/authorization.md

@@ -245,7 +245,7 @@ Similar to the `before` method, if the `after` closure returns a non-null result
 <a name="inline-authorization"></a>
 ### Inline Authorization
 
-Occasionally, you may wish to determine if the currently authenticated user is authorized to perform a given action without writing a dedicated gate that corresponds to the action. Laravel allows you to perform these types of "inline" authorization checks via the `Gate::allowIf` and `Gate::denyIf` methods:
+Occasionally, you may wish to determine if the currently authenticated user is authorized to perform a given action without writing a dedicated gate that corresponds to the action. Laravel allows you to perform these types of "inline" authorization checks via the `Gate::allowIf` and `Gate::denyIf` methods. Inline authorization does not execute any defined ["before" or "after" authorization hooks](#intercepting-gate-checks):
 
 ```php
 use App\Models\User;

original-en/cashier-paddle.md

@@ -10,6 +10,9 @@
     - [Paddle JS](#paddle-js)
     - [Currency Configuration](#currency-configuration)
     - [Overriding Default Models](#overriding-default-models)
+- [Quickstart](#quickstart)
+    - [Selling Products](#quickstart-selling-products)
+    - [Selling Subscriptions](#quickstart-selling-subscriptions)
 - [Checkout Sessions](#checkout-sessions)
     - [Overlay Checkout](#overlay-checkout)
     - [Inline Checkout](#inline-checkout)
@@ -192,17 +195,234 @@ After defining your model, you may instruct Cashier to use your custom model via
         Cashier::useTransactionModel(Transaction::class);
     }
 
+<a name="quickstart"></a>
+## Quickstart
+
+<a name="quickstart-selling-products"></a>
+### Selling Products
+
+> [!NOTE]
+> Before utilizing Paddle Checkout, you should define Products with fixed prices in your Paddle dashboard. In addition, you should [configure Paddle's webhook handling](#handling-paddle-webhooks).
+
+Offering product and subscription billing via your application can be intimidating. However, thanks to Cashier and [Paddle's Checkout Overlay](https://www.paddle.com/billing/checkout), you can easily build modern, robust payment integrations.
+
+To charge customers for non-recurring, single-charge products, we'll utilize Cashier to charge customers with Paddle's Checkout Overlay, where they will provide their payment details and confirm their purchase. Once the payment has been made via the Checkout Overlay, the customer will be redirected to a success URL of your choosing within your application:
+
+    use Illuminate\Http\Request;
+
+    Route::get('/buy', function (Request $request) {
+        $checkout = $request->user()->checkout('pri_deluxe_album')
+            ->returnTo(route('dashboard'));
+
+        return view('buy', ['checkout' => $checkout]);
+    })->name('checkout');
+
+As you can see in the example above, we will utilize Cashier's provided `checkout` method to create a checkout object to present the customer the Paddle Checkout Overlay for a given "price identifier". When using Paddle, "prices" refer to [defined prices for specific products](https://developer.paddle.com/build/products/create-products-prices).
+
+If necessary, the `checkout` method will automatically create a customer in Paddle and connect that Paddle customer record to the corresponding user in your application's database. After completing the checkout session, the customer will be redirected to a dedicated success page where you can display an informational message to the customer.
+
+In the `buy` view, we will include a button to display the Checkout Overlay. The `paddle-button` Blade component is included with Cashier Paddle; however, you may also [manually render an overlay checkout](#manually-rendering-an-overlay-checkout):
+
+```html
+<x-paddle-button :checkout="$checkout" class="px-8 py-4">
+    Buy Product
+</x-paddle-button>
+```
+
+<a name="providing-meta-data-to-paddle-checkout"></a>
+#### Providing Meta Data to Paddle Checkout
+
+When selling products, it's common to keep track of completed orders and purchased products via `Cart` and `Order` models defined by your own application. When redirecting customers to Paddle's Checkout Overlay to complete a purchase, you may need to provide an existing order identifier so that you can associate the completed purchase with the corresponding order when the customer is redirected back to your application.
+
+To accomplish this, you may provide an array of custom data to the `checkout` method. Let's imagine that a pending `Order` is created within our application when a user begins the checkout process. Remember, the `Cart` and `Order` models in this example are illustrative and not provided by Cashier. You are free to implement these concepts based on the needs of your own application:
+
+    use App\Models\Cart;
+    use App\Models\Order;
+    use Illuminate\Http\Request;
+
+    Route::get('/cart/{cart}/checkout', function (Request $request, Cart $cart) {
+        $order = Order::create([
+            'cart_id' => $cart->id,
+            'price_ids' => $cart->price_ids,
+            'status' => 'incomplete',
+        ]);
+
+        $checkout = $request->user()->checkout($order->price_ids)
+            ->customData(['order_id' => $order->id]);
+
+        return view('billing', ['checkout' => $checkout]);
+    })->name('checkout');
+
+As you can see in the example above, when a user begins the checkout process, we will provide all of the cart / order's associated Paddle price identifiers to the `checkout` method. Of course, your application is responsible for associating these items with the "shopping cart" or order as a customer adds them. We also provide the order's ID to the Paddle Checkout Overlay via the `customData` method.
+
+Of course, you will likely want to mark the order as "complete" once the customer has finished the checkout process. To accomplish this, you may listen to the webhooks dispatched by Paddle and raised via events by Cashier to store order information in your database.
+
+To get started, listen for the `TransactionCompleted` event dispatched by Cashier. Typically, you should register the event listener in the `boot` method of one of your application's service providers:
+
+    use App\Listeners\CompleteOrder;
+    use Illuminate\Support\Facades\Event;
+    use Laravel\Paddle\Events\TransactionCompleted;
+
+    /**
+     * Bootstrap any application services.
+     */
+    public function boot(): void
+    {
+        Event::listen(TransactionCompleted::class, CompleteOrder::class);
+    }
+
+In this example, the `CompleteOrder` listener might look like the following:
+
+    namespace App\Listeners;
+
+    use App\Models\Order;
+    use Laravel\Cashier\Cashier;
+    use Laravel\Cashier\Events\TransactionCompleted;
+
+    class CompleteOrder
+    {
+        /**
+         * Handle the incoming Cashier webhook event.
+         */
+        public function handle(TransactionCompleted $event): void
+        {
+            $orderId = $event->payload['data']['custom_data']['order_id'] ?? null;
+
+            $order = Order::findOrFail($orderId);
+
+            $order->update(['status' => 'completed']);
+        }
+    }
+
+Please refer to Paddle's documentation for more information on the [data contained by the `transaction.completed` event](https://developer.paddle.com/webhooks/transactions/transaction-completed).
+
+<a name="quickstart-selling-subscriptions"></a>
+### Selling Subscriptions
+
+> [!NOTE]  
+> Before utilizing Paddle Checkout, you should define Products with fixed prices in your Paddle dashboard. In addition, you should [configure Paddle's webhook handling](#handling-paddle-webhooks).
+
+Offering product and subscription billing via your application can be intimidating. However, thanks to Cashier and [Paddle's Checkout Overlay](https://www.paddle.com/billing/checkout), you can easily build modern, robust payment integrations.
+
+To learn how to sell subscriptions using Cashier and Paddle's Checkout Overlay, let's consider the simple scenario of a subscription service with a basic monthly (`price_basic_monthly`) and yearly (`price_basic_yearly`) plan. These two prices could be grouped under a "Basic" product (`pro_basic`) in our Paddle dashboard. In addition, our subscription service might offer an Expert plan as `pro_expert`.
+
+First, let's discover how a customer can subscribe to our services. Of course, you can imagine the customer might click a "subscribe" button for the Basic plan on our application's pricing page. This button will invoke a Paddle Checkout Overlay for their chosen plan. To get started, let's initiate a checkout session via the `checkout` method:
+
+    use Illuminate\Http\Request;
+
+    Route::get('/subscribe', function (Request $request) {
+        $checkout = $request->user()->checkout('price_basic_monthly')
+            ->returnTo(route('dashboard'));
+
+        return view('subscribe', ['checkout' => $checkout]);
+    })->name('subscribe');
+
+In the `subscribe` view, we will include a button to display the Checkout Overlay. The `paddle-button` Blade component is included with Cashier Paddle; however, you may also [manually render an overlay checkout](#manually-rendering-an-overlay-checkout):
+
+```html
+<x-paddle-button :checkout="$checkout" class="px-8 py-4">
+    Subscribe
+</x-paddle-button>
+```
+
+Now, when the Subscribe button is clicked, the customer will be able to enter their payment details and initiate their subscription. To know when their subscription has actually started (since some payment methods require a few seconds to process), you should also [configure Cashier's webhook handling](#handling-paddle-webhooks).
+
+Now that customers can start subscriptions, we need to restrict certain portions of our application so that only subscribed users can access them. Of course, we can always determine a user's current subscription status via the `subscribed` method provided by Cashier's `Billable` trait:
+
+```blade
+@if ($user->subscribed())
+    <p>You are subscribed.</p>
+@endif
+```
+
+We can even easily determine if a user is subscribed to specific product or price:
+
+```blade
+@if ($user->subscribedToProduct('pro_basic'))
+    <p>You are subscribed to our Basic product.</p>
+@endif
+
+@if ($user->subscribedToPrice('price_basic_monthly'))
+    <p>You are subscribed to our monthly Basic plan.</p>
+@endif
+```
+
+<a name="quickstart-building-a-subscribed-middleware"></a>
+#### Building a Subscribed Middleware
+
+For convenience, you may wish to create a [middleware](/docs/{{version}}/middleware) which determines if the incoming request is from a subscribed user. Once this middleware has been defined, you may easily assign it to a route to prevent users that are not subscribed from accessing the route:
+
+    <?php
+
+    namespace App\Http\Middleware;
+
+    use Closure;
+    use Illuminate\Http\Request;
+    use Symfony\Component\HttpFoundation\Response;
+
+    class Subscribed
+    {
+        /**
+         * Handle an incoming request.
+         */
+        public function handle(Request $request, Closure $next): Response
+        {
+            if (! $request->user()?->subscribed()) {
+                // Redirect user to billing page and ask them to subscribe...
+                return redirect('/subscribe');
+            }
+
+            return $next($request);
+        }
+    }
+
+Once the middleware has been defined, you may assign it to a route:
+
+    use App\Http\Middleware\Subscribed;
+
+    Route::get('/dashboard', function () {
+        // ...
+    })->middleware([Subscribed::class]);
+
+<a name="quickstart-allowing-customers-to-manage-their-billing-plan"></a>
+#### Allowing Customers to Manage Their Billing Plan
+
+Of course, customers may want to change their subscription plan to another product or "tier". In our example from above, we'd want to allow the customer to change their plan from a monthly subscription to a yearly subscription. For this you'll need to implement something like a button that leads to the below route:
+
+    use Illuminate\Http\Request;
+
+    Route::put('/subscription/{price}/swap', function (Request $request, $price) {
+        $user->subscription()->swap($price); // With "$price" being "price_basic_yearly" for this example.
+
+        return redirect()->route('dashboard');
+    })->name('subscription.swap');
+
+Besides swapping plans you'll also need to allow your customers to cancel their subscription. Like swapping plans, provide a button that leads to the following route:
+
+    use Illuminate\Http\Request;
+
+    Route::put('/subscription/cancel', function (Request $request, $price) {
+        $user->subscription()->cancel();
+
+        return redirect()->route('dashboard');
+    })->name('subscription.cancel');
+
+And now your subscription will get cancelled at the end of its billing period.
+
+> [!NOTE]  
+> As long as you have configured Cashier's webhook handling, Cashier will automatically keep your application's Cashier-related database tables in sync by inspecting the incoming webhooks from Paddle. So, for example, when you cancel a customer's subscription via Paddle's dashboard, Cashier will receive the corresponding webhook and mark the subscription as "cancelled" in your application's database.
+
 <a name="checkout-sessions"></a>
 ## Checkout Sessions
 
-Most operations to bill customers are performed using "checkouts" via Paddle's [checkout overlay widget](https://developer.paddle.com/build/checkout/build-overlay-checkout) or by utilizing [inline checkout](https://developer.paddle.com/build/checkout/build-branded-inline-checkout).
+Most operations to bill customers are performed using "checkouts" via Paddle's [Checkout Overlay widget](https://developer.paddle.com/build/checkout/build-overlay-checkout) or by utilizing [inline checkout](https://developer.paddle.com/build/checkout/build-branded-inline-checkout).
 
 Before processing checkout payments using Paddle, you should define your application's [default payment link](https://developer.paddle.com/build/transactions/default-payment-link#set-default-link) in your Paddle checkout settings dashboard.
 
 <a name="overlay-checkout"></a>
 ### Overlay Checkout
 
-Before displaying the checkout overlay widget, you must generate a checkout session using Cashier. A checkout session will inform the checkout widget of the billing operation that should be performed:
+Before displaying the Checkout Overlay widget, you must generate a checkout session using Cashier. A checkout session will inform the checkout widget of the billing operation that should be performed:
 
     use Illuminate\Http\Request;
 

original-en/homestead.md

@@ -20,7 +20,7 @@
     - [Connecting to Databases](#connecting-to-databases)
     - [Database Backups](#database-backups)
     - [Configuring Cron Schedules](#configuring-cron-schedules)
-    - [Configuring MailHog](#configuring-mailhog)
+    - [Configuring Mailpit](#configuring-mailpit)
     - [Configuring Minio](#configuring-minio)
     - [Laravel Dusk](#laravel-dusk)
     - [Sharing Your Environment](#sharing-your-environment)
@@ -36,7 +36,7 @@
 <a name="introduction"></a>
 ## Introduction
 
-Laravel strives to make the entire PHP development experience delightful, including your local development environment. [Laravel Homestead](https://github.com/laravel/homestead) is an official, pre-packaged Vagrant box that provides you a wonderful development environment without requiring you to install PHP, a web server, and any other server software on your local machine.
+Laravel strives to make the entire PHP development experience delightful, including your local development environment. [Laravel Homestead](https://github.com/laravel/homestead) is an official, pre-packaged Vagrant box that provides you a wonderful development environment without requiring you to install PHP, a web server, or any other server software on your local machine.
 
 [Vagrant](https://www.vagrantup.com) provides a simple, elegant way to manage and provision Virtual Machines. Vagrant boxes are completely disposable. If something goes wrong, you can destroy and re-create the box in minutes!
 
@@ -58,8 +58,9 @@ Homestead runs on any Windows, macOS, or Linux system and includes Nginx, PHP, M
 
 <div id="software-list" markdown="1">
 
-- Ubuntu 20.04
+- Ubuntu 22.04
 - Git
+- PHP 8.3
 - PHP 8.2
 - PHP 8.1
 - PHP 8.0
@@ -80,7 +81,7 @@ Homestead runs on any Windows, macOS, or Linux system and includes Nginx, PHP, M
 - Redis
 - Memcached
 - Beanstalkd
-- Mailhog
+- Mailpit
 - avahi
 - ngrok
 - Xdebug
@@ -116,7 +117,6 @@ Homestead runs on any Windows, macOS, or Linux system and includes Nginx, PHP, M
 - Grafana
 - InfluxDB
 - Logstash
-- Mailpit <small>(Replaces Mailhog)</small>
 - MariaDB
 - Meilisearch
 - MinIO
@@ -346,12 +346,10 @@ features:
     - grafana: true
     - influxdb: true
     - logstash: true
-    - mailpit: true
     - mariadb: true
     - meilisearch: true
     - minio: true
     - mongodb: true
-    - mysql: true
     - neo4j: true
     - ohmyzsh: true
     - openresty: true
@@ -558,15 +556,15 @@ Below is a list of additional Homestead service ports that you may wish to map f
 - **MySQL:** 33060 &rarr; To 3306
 - **PostgreSQL:** 54320 &rarr; To 5432
 - **MongoDB:** 27017 &rarr; To 27017
-- **Mailhog:** 8025 &rarr; To 8025
+- **Mailpit:** 8025 &rarr; To 8025
 - **Minio:** 9600 &rarr; To 9600
 
 </div>
 
 <a name="php-versions"></a>
 ### PHP Versions
 
-Homestead supports running multiple versions of PHP on the same virtual machine. You may specify which version of PHP to use for a given site within your `Homestead.yaml` file. The available PHP versions are: "5.6", "7.0", "7.1", "7.2", "7.3", "7.4", "8.0", "8.1", and "8.2" (the default):
+Homestead supports running multiple versions of PHP on the same virtual machine. You may specify which version of PHP to use for a given site within your `Homestead.yaml` file. The available PHP versions are: "5.6", "7.0", "7.1", "7.2", "7.3", "7.4", "8.0", "8.1", "8.2", and "8.3", (the default):
 
 ```yaml
 sites:
@@ -587,6 +585,7 @@ php7.4 artisan list
 php8.0 artisan list
 php8.1 artisan list
 php8.2 artisan list
+php8.3 artisan list
 ```
 
 You may change the default version of PHP used by the CLI by issuing the following commands from within your Homestead virtual machine:
@@ -601,6 +600,7 @@ php74
 php80
 php81
 php82
+php83
 ```
 
 <a name="connecting-to-databases"></a>
@@ -636,10 +636,10 @@ sites:
 
 The cron job for the site will be defined in the `/etc/cron.d` directory of the Homestead virtual machine.
 
-<a name="configuring-mailhog"></a>
-### Configuring MailHog
+<a name="configuring-mailpit"></a>
+### Configuring Mailpit
 
-[MailHog](https://github.com/mailhog/MailHog) allows you to intercept your outgoing email and examine it without actually sending the mail to its recipients. To get started, update your application's `.env` file to use the following mail settings:
+[Mailpit](https://github.com/axllent/mailpit) allows you to intercept your outgoing email and examine it without actually sending the mail to its recipients. To get started, update your application's `.env` file to use the following mail settings:
 
 ```ini
 MAIL_MAILER=smtp
@@ -650,7 +650,7 @@ MAIL_PASSWORD=null
 MAIL_ENCRYPTION=null
 ```
 
-Once MailHog has been configured, you may access the MailHog dashboard at `http://localhost:8025`.
+Once Mailpit has been configured, you may access the Mailpit dashboard at `http://localhost:8025`.
 
 <a name="configuring-minio"></a>
 ### Configuring Minio