bhavin-gajjar/laravel-coder-lora-train huggingface dataset:
[Laravel 10] Explain verification: Routing

To properly implement email verification, three routes will need to be defined. First, a route will be needed to display a notice to the user that they should click the email verification link in the verification email that Laravel sent them after registration.

Second, a route will be needed to handle requests generated when the user clicks the email verification link in the email.

Third, a route will be needed to resend a verification link if the user accidentally loses the first verification link.

<a name="the-email-verification-notice"></a>
[Laravel 10] Explain views: Introduction

Of course, it's not practical to return entire HTML documents strings directly from your routes and controllers. Thankfully, views provide a convenient way to place all of our HTML in separate files.

Views separate your controller / application logic from your presentation logic and are stored in the resources/views directory. When using Laravel, view templates are usually written using the Blade templating language. A simple view might look something like this:

Since this view is stored at resources/views/greeting.blade.php, we may return it using the global view helper like so:

    Route::get('/', function () {
        return view('greeting', ['name' => 'James']);
    });

> [!NOTE]  
> Looking for more information on how to write Blade templates? Check out the full Blade documentation to get started.

<a name="writing-views-in-react-or-vue"></a>
[Laravel 10] Explain views: Writing Views in React / Vue

Instead of writing their frontend templates in PHP via Blade, many developers have begun to prefer to write their templates using React or Vue. Laravel makes this painless thanks to Inertia, a library that makes it a cinch to tie your React / Vue frontend to your Laravel backend without the typical complexities of building an SPA.

Our Breeze and Jetstream starter kits give you a great starting point for your next Laravel application powered by Inertia. In addition, the Laravel Bootcamp provides a full demonstration of building a Laravel application powered by Inertia, including examples in Vue and React.

<a name="creating-and-rendering-views"></a>
[Laravel 10] Explain views: Creating and Rendering Views

You may create a view by placing a file with the .blade.php extension in your application's resources/views directory or by using the make:view Artisan command:

The .blade.php extension informs the framework that the file contains a Blade template. Blade templates contain HTML as well as Blade directives that allow you to easily echo values, create "if" statements, iterate over data, and more.

Once you have created a view, you may return it from one of your application's routes or controllers using the global view helper:

    Route::get('/', function () {
        return view('greeting', ['name' => 'James']);
    });

Views may also be returned using the View facade:

    use Illuminate\Support\Facades\View;

    return View::make('greeting', ['name' => 'James']);

As you can see, the first argument passed to the view helper corresponds to the name of the view file in the resources/views directory. The second argument is an array of data that should be made available to the view. In this case, we are passing the name variable, which is displayed in the view using Blade syntax.

<a name="nested-view-directories"></a>
[Laravel 10] Explain views: Nested View Directories

Views may also be nested within subdirectories of the resources/views directory. "Dot" notation may be used to reference nested views. For example, if your view is stored at resources/views/admin/profile.blade.php, you may return it from one of your application's routes / controllers like so:

    return view('admin.profile', $data);

> [!WARNING]  
> View directory names should not contain the . character.

<a name="creating-the-first-available-view"></a>
[Laravel 10] Explain vite: Asset Bundling (Vite)

- Introduction
- Installation & Setup
  - Installing Node
  - Installing Vite and the Laravel Plugin
  - Configuring Vite
  - Loading Your Scripts and Styles
- Running Vite
- Working With JavaScript
  - Aliases
  - Vue
  - React
  - Inertia
  - URL Processing
- Working With Stylesheets
- Working With Blade and Routes
  - Processing Static Assets With Vite
  - Refreshing on Save
  - Aliases
- Custom Base URLs
- Environment Variables
- Disabling Vite in Tests
- Server-Side Rendering (SSR)
- Script and Style Tag Attributes
  - Content Security Policy (CSP) Nonce
  - Subresource Integrity (SRI)
  - Arbitrary Attributes
- Advanced Customization
  - Correcting Dev Server URLs

<a name="introduction"></a>
[Laravel 10] Explain vite: Introduction

Vite is a modern frontend build tool that provides an extremely fast development environment and bundles your code for production. When building applications with Laravel, you will typically use Vite to bundle your application's CSS and JavaScript files into production ready assets.

Laravel integrates seamlessly with Vite by providing an official plugin and Blade directive to load your assets for development and production.

> [!NOTE]  
> Are you running Laravel Mix? Vite has replaced Laravel Mix in new Laravel installations. For Mix documentation, please visit the Laravel Mix website. If you would like to switch to Vite, please see our migration guide.

<a name="vite-or-mix"></a>
[Laravel 10] Explain vite: Choosing Between Vite and Laravel Mix

Before transitioning to Vite, new Laravel applications utilized Mix, which is powered by webpack, when bundling assets. Vite focuses on providing a faster and more productive experience when building rich JavaScript applications. If you are developing a Single Page Application (SPA), including those developed with tools like Inertia, Vite will be the perfect fit.

Vite also works well with traditional server-side rendered applications with JavaScript "sprinkles", including those using Livewire. However, it lacks some features that Laravel Mix supports, such as the ability to copy arbitrary assets into the build that are not referenced directly in your JavaScript application.

<a name="migrating-back-to-mix"></a>
[Laravel 11] Explain artisan: Artisan Console

- Introduction
    - Tinker (REPL)
- Writing Commands
    - Generating Commands
    - Command Structure
    - Closure Commands
    - Isolatable Commands
- Defining Input Expectations
    - Arguments
    - Options
    - Input Arrays
    - Input Descriptions
    - Prompting for Missing Input
- Command I/O
    - Retrieving Input
    - Prompting for Input
    - Writing Output
- Registering Commands
- Programmatically Executing Commands
    - Calling Commands From Other Commands
- Signal Handling
- Stub Customization
- Events

<a name="introduction"></a>
[Laravel 11] Explain artisan: Introduction

Artisan is the command line interface included with Laravel. Artisan exists at the root of your application as the artisan script and provides a number of helpful commands that can assist you while you build your application. To view a list of all available Artisan commands, you may use the list command:

Every command also includes a "help" screen which displays and describes the command's available arguments and options. To view a help screen, precede the name of the command with help:

<a name="laravel-sail"></a>
[Laravel 11] Explain authentication: Authentication

- Introduction
    - Starter Kits
    - Database Considerations
    - Ecosystem Overview
- Authentication Quickstart
    - Install a Starter Kit
    - Retrieving the Authenticated User
    - Protecting Routes
    - Login Throttling
- Manually Authenticating Users
    - Remembering Users
    - Other Authentication Methods
- HTTP Basic Authentication
    - Stateless HTTP Basic Authentication
- Logging Out
    - Invalidating Sessions on Other Devices
- Password Confirmation
    - Configuration
    - Routing
    - Protecting Routes
- Adding Custom Guards
    - Closure Request Guards
- Adding Custom User Providers
    - The User Provider Contract
    - The Authenticatable Contract
- Automatic Password Rehashing
- Social Authentication
- Events

<a name="introduction"></a>
[Laravel 11] Explain authentication: Introduction

Many web applications provide a way for their users to authenticate with the application and "login". Implementing this feature in web applications can be a complex and potentially risky endeavor. For this reason, Laravel strives to give you the tools you need to implement authentication quickly, securely, and easily.

At its core, Laravel's authentication facilities are made up of "guards" and "providers". Guards define how users are authenticated for each request. For example, Laravel ships with a session guard which maintains state using session storage and cookies.

Providers define how users are retrieved from your persistent storage. Laravel ships with support for retrieving users using Eloquent and the database query builder. However, you are free to define additional providers as needed for your application.

Your application's authentication configuration file is located at config/auth.php. This file contains several well-documented options for tweaking the behavior of Laravel's authentication services.

> [!NOTE]  
> Guards and providers should not be confused with "roles" and "permissions". To learn more about authorizing user actions via permissions, please refer to the authorization documentation.

<a name="starter-kits"></a>
[Laravel 11] Explain authentication: Starter Kits

Want to get started fast? Install a Laravel application starter kit in a fresh Laravel application. After migrating your database, navigate your browser to /register or any other URL that is assigned to your application. The starter kits will take care of scaffolding your entire authentication system!

**Even if you choose not to use a starter kit in your final Laravel application, installing the Laravel Breeze starter kit can be a wonderful opportunity to learn how to implement all of Laravel's authentication functionality in an actual Laravel project.** Since Laravel Breeze creates authentication controllers, routes, and views for you, you can examine the code within these files to learn how Laravel's authentication features may be implemented.

<a name="introduction-database-considerations"></a>
[Laravel 11] Explain authentication: Database Considerations

By default, Laravel includes an App\Models\User Eloquent model in your app/Models directory. This model may be used with the default Eloquent authentication driver.

If your application is not using Eloquent, you may use the database authentication provider which uses the Laravel query builder. If your application is using MongoDB, check out MongoDB's official Laravel user authentication documentation .

When building the database schema for the App\Models\User model, make sure the password column is at least 60 characters in length. Of course, the users table migration that is included in new Laravel applications already creates a column that exceeds this length.

Also, you should verify that your users (or equivalent) table contains a nullable, string remember_token column of 100 characters. This column will be used to store a token for users that select the "remember me" option when logging into your application. Again, the default users table migration that is included in new Laravel applications already contains this column.

<a name="ecosystem-overview"></a>
[Laravel 11] Explain authentication: Ecosystem Overview

Laravel offers several packages related to authentication. Before continuing, we'll review the general authentication ecosystem in Laravel and discuss each package's intended purpose.

First, consider how authentication works. When using a web browser, a user will provide their username and password via a login form. If these credentials are correct, the application will store information about the authenticated user in the user's session. A cookie issued to the browser contains the session ID so that subsequent requests to the application can associate the user with the correct session. After the session cookie is received, the application will retrieve the session data based on the session ID, note that the authentication information has been stored in the session, and will consider the user as "authenticated".

When a remote service needs to authenticate to access an API, cookies are not typically used for authentication because there is no web browser. Instead, the remote service sends an API token to the API on each request. The application may validate the incoming token against a table of valid API tokens and "authenticate" the request as being performed by the user associated with that API token.

<a name="laravels-built-in-browser-authentication-services"></a>
[Laravel 11] Explain authorization: Authorization

- Introduction
- Gates
    - Writing Gates
    - Authorizing Actions
    - Gate Responses
    - Intercepting Gate Checks
    - Inline Authorization
- Creating Policies
    - Generating Policies
    - Registering Policies
- Writing Policies
    - Policy Methods
    - Policy Responses
    - Methods Without Models
    - Guest Users
    - Policy Filters
- Authorizing Actions Using Policies
    - Via the User Model
    - Via the Gate Facade
    - Via Middleware
    - Via Blade Templates
    - Supplying Additional Context
- Authorization & Inertia

<a name="introduction"></a>
[Laravel 11] Explain authorization: Introduction

In addition to providing built-in authentication services, Laravel also provides a simple way to authorize user actions against a given resource. For example, even though a user is authenticated, they may not be authorized to update or delete certain Eloquent models or database records managed by your application. Laravel's authorization features provide an easy, organized way of managing these types of authorization checks.

Laravel provides two primary ways of authorizing actions: gates and policies. Think of gates and policies like routes and controllers. Gates provide a simple, closure-based approach to authorization while policies, like controllers, group logic around a particular model or resource. In this documentation, we'll explore gates first and then examine policies.

You do not need to choose between exclusively using gates or exclusively using policies when building an application. Most applications will most likely contain some mixture of gates and policies, and that is perfectly fine! Gates are most applicable to actions that are not related to any model or resource, such as viewing an administrator dashboard. In contrast, policies should be used when you wish to authorize an action for a particular model or resource.

<a name="gates"></a>
[Laravel 11] Explain authorization: Writing Gates

> [!WARNING]  
> Gates are a great way to learn the basics of Laravel's authorization features; however, when building robust Laravel applications you should consider using policies to organize your authorization rules.

Gates are simply closures that determine if a user is authorized to perform a given action. Typically, gates are defined within the boot method of the App\Providers\AppServiceProvider class using the Gate facade. Gates always receive a user instance as their first argument and may optionally receive additional arguments such as a relevant Eloquent model.

In this example, we'll define a gate to determine if a user can update a given App\Models\Post model. The gate will accomplish this by comparing the user's id against the user_id of the user that created the post:

    use App\Models\Post;
    use App\Models\User;
    use Illuminate\Support\Facades\Gate;

    /**
     * Bootstrap any application services.
     */
    public function boot(): void
    {
        Gate::define('update-post', function (User $user, Post $post) {
            return $user->id === $post->user_id;
        });
    }

Like controllers, gates may also be defined using a class callback array:

    use App\Policies\PostPolicy;
    use Illuminate\Support\Facades\Gate;

    /**
     * Bootstrap any application services.
     */
    public function boot(): void
    {
        Gate::define('update-post', [PostPolicy::class, 'update']);
    }

<a name="authorizing-actions-via-gates"></a>
[Laravel 11] Explain authorization: Authorizing Actions

To authorize an action using gates, you should use the allows or denies methods provided by the Gate facade. Note that you are not required to pass the currently authenticated user to these methods. Laravel will automatically take care of passing the user into the gate closure. It is typical to call the gate authorization methods within your application's controllers before performing an action that requires authorization:

    <?php

    namespace App\Http\Controllers;

    use App\Http\Controllers\Controller;
    use App\Models\Post;
    use Illuminate\Http\RedirectResponse;
    use Illuminate\Http\Request;
    use Illuminate\Support\Facades\Gate;

    class PostController extends Controller
    {
        /**
         * Update the given post.
         */
        public function update(Request $request, Post $post): RedirectResponse
        {
            if (! Gate::allows('update-post', $post)) {
                abort(403);
            }

            // Update the post...

            return redirect('/posts');
        }
    }

If you would like to determine if a user other than the currently authenticated user is authorized to perform an action, you may use the forUser method on the Gate facade:

    if (Gate::forUser($user)->allows('update-post', $post)) {
        // The user can update the post...
    }

    if (Gate::forUser($user)->denies('update-post', $post)) {
        // The user can't update the post...
    }

You may authorize multiple actions at a time using the any or none methods:

    if (Gate::any(['update-post', 'delete-post'], $post)) {
        // The user can update or delete the post...
    }

    if (Gate::none(['update-post', 'delete-post'], $post)) {
        // The user can't update or delete the post...
    }

<a name="authorizing-or-throwing-exceptions"></a>
[Laravel 11] Explain authorization: Authorizing or Throwing Exceptions

If you would like to attempt to authorize an action and automatically throw an Illuminate\Auth\Access\AuthorizationException if the user is not allowed to perform the given action, you may use the Gate facade's authorize method. Instances of AuthorizationException are automatically converted to a 403 HTTP response by Laravel:

    Gate::authorize('update-post', $post);

    // The action is authorized...

<a name="gates-supplying-additional-context"></a>
[Laravel 11] Explain billing: Laravel Cashier (Stripe)

- Introduction
- Upgrading Cashier
- Installation
- Configuration
    - Billable Model
    - API Keys
    - Currency Configuration
    - Tax Configuration
    - Logging
    - Using Custom Models
- Quickstart
    - Selling Products
    - Selling Subscriptions
- Customers
    - Retrieving Customers
    - Creating Customers
    - Updating Customers
    - Balances
    - Tax IDs
    - Syncing Customer Data With Stripe
    - Billing Portal
- Payment Methods
    - Storing Payment Methods
    - Retrieving Payment Methods
    - Payment Method Presence
    - Updating the Default Payment Method
    - Adding Payment Methods
    - Deleting Payment Methods
- Subscriptions
    - Creating Subscriptions
    - Checking Subscription Status
    - Changing Prices
    - Subscription Quantity
    - Subscriptions With Multiple Products
    - Multiple Subscriptions
    - Usage Based Billing
    - Subscription Taxes
    - Subscription Anchor Date
    - Canceling Subscriptions
    - Resuming Subscriptions
- Subscription Trials
    - With Payment Method Up Front
    - Without Payment Method Up Front
    - Extending Trials
- Handling Stripe Webhooks
    - Defining Webhook Event Handlers
    - Verifying Webhook Signatures
- Single Charges
    - Simple Charge
    - Charge With Invoice
    - Creating Payment Intents
    - Refunding Charges
- Checkout
    - Product Checkouts
    - Single Charge Checkouts
    - Subscription Checkouts
    - Collecting Tax IDs
    - Guest Checkouts
- Invoices
    - Retrieving Invoices
    - Upcoming Invoices
    - Previewing Subscription Invoices
    - Generating Invoice PDFs
- Handling Failed Payments
    - Confirming Payments
- Strong Customer Authentication (SCA)
    - Payments Requiring Additional Confirmation
    - Off-session Payment Notifications
- Stripe SDK
- Testing

<a name="introduction"></a>
[Laravel 11] Explain billing: Upgrading Cashier

When upgrading to a new version of Cashier, it's important that you carefully review the upgrade guide.

> [!WARNING]  
> To prevent breaking changes, Cashier uses a fixed Stripe API version. Cashier 15 utilizes Stripe API version 2023-10-16. The Stripe API version will be updated on minor releases in order to make use of new Stripe features and improvements.

<a name="installation"></a>
[Laravel 11] Explain billing: Installation

First, install the Cashier package for Stripe using the Composer package manager:

After installing the package, publish Cashier's migrations using the vendor:publish Artisan command:

Then, migrate your database:

Cashier's migrations will add several columns to your users table. They will also create a new subscriptions table to hold all of your customer's subscriptions and a subscription_items table for subscriptions with multiple prices.

If you wish, you can also publish Cashier's configuration file using the vendor:publish Artisan command:

Lastly, to ensure Cashier properly handles all Stripe events, remember to configure Cashier's webhook handling.

> [!WARNING]  
> Stripe recommends that any column used for storing Stripe identifiers should be case-sensitive. Therefore, you should ensure the column collation for the stripe_id column is set to utf8_bin when using MySQL. More information regarding this can be found in the Stripe documentation.

<a name="configuration"></a>
[Laravel 11] Explain billing: Billable Model

Before using Cashier, add the Billable trait to your billable model definition. Typically, this will be the App\Models\User model. This trait provides various methods to allow you to perform common billing tasks, such as creating subscriptions, applying coupons, and updating payment method information:

    use Laravel\Cashier\Billable;

    class User extends Authenticatable
    {
        use Billable;
    }

Cashier assumes your billable model will be the App\Models\User class that ships with Laravel. If you wish to change this you may specify a different model via the useCustomerModel method. This method should typically be called in the boot method of your AppServiceProvider class:

    use App\Models\Cashier\User;
    use Laravel\Cashier\Cashier;

    /**
     * Bootstrap any application services.
     */
    public function boot(): void
    {
        Cashier::useCustomerModel(User::class);
    }

> [!WARNING]  
> If you're using a model other than Laravel's supplied App\Models\User model, you'll need to publish and alter the Cashier migrations provided to match your alternative model's table name.

<a name="api-keys"></a>