bhavin-gajjar/laravel-coder-lora-train huggingface dataset:
[Laravel 12] Explain ai: Installation

Boost can be installed in Laravel 10, 11, and 12 applications running PHP 8.1 or higher. To get started, install Boost as a development dependency:

Once installed, run the interactive installer:

The installer will auto-detect your IDE and AI agents, allowing you to select the integrations that make sense for your project. Boost will generate the necessary configuration files, such as .mcp.json for MCP-compatible editors and guideline files for AI context.

> [!NOTE]
> Generated configuration files like .mcp.json, CLAUDE.md, and boost.json can be safely added to your .gitignore if you prefer each developer to configure their own environment.

<a name="available-tools"></a>
[Laravel 12] 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 12] 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 12] 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 12] 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 12] 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 a starter kit can be a wonderful opportunity to learn how to implement all of Laravel's authentication functionality in an actual Laravel project.** Since the Laravel starter kits contain 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 12] 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 12] 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 12] 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 12] 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 12] 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:

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

<a name="authorizing-actions-via-gates"></a>
[Laravel 12] 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:

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:

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

<a name="authorizing-or-throwing-exceptions"></a>
[Laravel 12] 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:

<a name="gates-supplying-additional-context"></a>
[Laravel 12] 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
- Invoices
    - Retrieving Invoices
    - Upcoming Invoices
    - Previewing Subscription Invoices
    - Generating Invoice PDFs
- Checkout
    - Product Checkouts
    - Single Charge Checkouts
    - Subscription Checkouts
    - Collecting Tax IDs
    - Guest Checkouts
- 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 12] 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 16 utilizes Stripe API version 2025-06-30.basil. 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 12] 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 12] 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:

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:

> [!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>
[Laravel 12] Explain blade: Blade Templates

- Introduction
    - Supercharging Blade With Livewire
- Displaying Data
    - HTML Entity Encoding
    - Blade and JavaScript Frameworks
- Blade Directives
    - If Statements
    - Switch Statements
    - Loops
    - The Loop Variable
    - Conditional Classes
    - Additional Attributes
    - Including Subviews
    - The @once Directive
    - Raw PHP
    - Comments
- Components
    - Rendering Components
    - Index Components
    - Passing Data to Components
    - Component Attributes
    - Reserved Keywords
    - Slots
    - Inline Component Views
    - Dynamic Components
    - Manually Registering Components
- Anonymous Components
    - Anonymous Index Components
    - Data Properties / Attributes
    - Accessing Parent Data
    - Anonymous Components Paths
- Building Layouts
    - Layouts Using Components
    - Layouts Using Template Inheritance
- Forms
    - CSRF Field
    - Method Field
    - Validation Errors
- Stacks
- Service Injection
- Rendering Inline Blade Templates
- Rendering Blade Fragments
- Extending Blade
    - Custom Echo Handlers
    - Custom If Statements

<a name="introduction"></a>
[Laravel 12] Explain blade: Introduction

Blade is the simple, yet powerful templating engine that is included with Laravel. Unlike some PHP templating engines, Blade does not restrict you from using plain PHP code in your templates. In fact, all Blade templates are compiled into plain PHP code and cached until they are modified, meaning Blade adds essentially zero overhead to your application. Blade template files use the .blade.php file extension and are typically stored in the resources/views directory.

Blade views may be returned from routes or controllers using the global view helper. Of course, as mentioned in the documentation on views, data may be passed to the Blade view using the view helper's second argument:

<a name="supercharging-blade-with-livewire"></a>
[Laravel 12] Explain blade: Supercharging Blade With Livewire

Want to take your Blade templates to the next level and build dynamic interfaces with ease? Check out Laravel Livewire. Livewire allows you to write Blade components that are augmented with dynamic functionality that would typically only be possible via frontend frameworks like React, Svelte, or Vue, providing a great approach to building modern, reactive frontends without the complexities, client-side rendering, or build steps of many JavaScript frameworks.

<a name="displaying-data"></a>
[Laravel 12] Explain blade: Displaying Data

You may display data that is passed to your Blade views by wrapping the variable in curly braces. For example, given the following route:

You may display the contents of the name variable like so:

> [!NOTE]
> Blade's {{ }} echo statements are automatically sent through PHP's htmlspecialchars function to prevent XSS attacks.

You are not limited to displaying the contents of the variables passed to the view. You may also echo the results of any PHP function. In fact, you can put any PHP code you wish inside of a Blade echo statement:

<a name="html-entity-encoding"></a>
[Laravel 12] Explain boost: Laravel Boost

- Introduction
- Installation
    - Keeping Boost Resources Updated
    - Set Up Your Agents
- MCP Server
    - Available MCP Tools
    - Manually Registering the MCP Server
- AI Guidelines
    - Available AI Guidelines
    - Adding Custom AI Guidelines
    - Overriding Boost AI Guidelines
    - Third-Party Package AI Guidelines
- Agent Skills
    - Available Skills
    - Custom Skills
    - Overriding Skills
    - Third-Party Package Skills
- Guidelines vs. Skills
- Documentation API
- Extending Boost
    - Adding Support for Other IDEs / AI Agents

<a name="introduction"></a>
[Laravel 12] Explain boost: Introduction

Laravel Boost accelerates AI-assisted development by providing the essential guidelines and agent skills that help AI agents write high-quality Laravel applications that adhere to Laravel best practices.

Boost also provides a powerful Laravel ecosystem documentation API that combines a built-in MCP tool with an extensive knowledge base containing over 17,000 pieces of Laravel-specific information, all enhanced by semantic search capabilities using embeddings for precise, context-aware results. Boost instructs AI agents like Claude Code and Cursor to use this API to learn about the latest Laravel features and best practices.

<a name="installation"></a>
[Laravel 12] Explain boost: Installation

Laravel Boost can be installed via Composer:

Next, install the MCP server and coding guidelines:

The boost:install command will generate the relevant agent guideline and skill files for the coding agents you selected during the installation process.

Once Laravel Boost has been installed, you're ready to start coding with Cursor, Claude Code, or your AI agent of choice.

> [!NOTE]
> Feel free to add the generated MCP configuration file (.mcp.json), guideline files (CLAUDE.md, AGENTS.md, junie/, etc.), and the boost.json configuration file to your application's .gitignore, as these files are automatically regenerated when running boost:install and boost:update.

<a name="set-up-your-agents"></a>
[Laravel 12] Explain boost: Keeping Boost Resources Updated

You may want to periodically update your local Boost resources (AI guidelines and skills) to ensure they reflect the latest versions of the Laravel ecosystem packages you have installed. To do so, you can use the boost:update Artisan command.

You may also automate this process by adding it to your Composer "post-update-cmd" scripts:

<a name="mcp-server"></a>
[Laravel 12] Explain broadcasting: Broadcasting

- Introduction
- Quickstart
- Server Side Installation
    - Reverb
    - Pusher Channels
    - Ably
- Client Side Installation
    - Reverb
    - Pusher Channels
    - Ably
- Concept Overview
    - Using an Example Application
- Defining Broadcast Events
    - Broadcast Name
    - Broadcast Data
    - Broadcast Queue
    - Broadcast Conditions
    - Broadcasting and Database Transactions
- Authorizing Channels
    - Defining Authorization Callbacks
    - Defining Channel Classes
- Broadcasting Events
    - Only to Others
    - Customizing the Connection
    - Anonymous Events
    - Rescuing Broadcasts
- Receiving Broadcasts
    - Listening for Events
    - Leaving a Channel
    - Namespaces
    - Using React or Vue
- Presence Channels
    - Authorizing Presence Channels
    - Joining Presence Channels
    - Broadcasting to Presence Channels
- Model Broadcasting
    - Model Broadcasting Conventions
    - Listening for Model Broadcasts
- Client Events
- Notifications

<a name="introduction"></a>
[Laravel 12] Explain broadcasting: Introduction

In many modern web applications, WebSockets are used to implement realtime, live-updating user interfaces. When some data is updated on the server, a message is typically sent over a WebSocket connection to be handled by the client. WebSockets provide a more efficient alternative to continually polling your application's server for data changes that should be reflected in your UI.

For example, imagine your application is able to export a user's data to a CSV file and email it to them. However, creating this CSV file takes several minutes so you choose to create and mail the CSV within a queued job. When the CSV has been created and mailed to the user, we can use event broadcasting to dispatch an App\Events\UserDataExported event that is received by our application's JavaScript. Once the event is received, we can display a message to the user that their CSV has been emailed to them without them ever needing to refresh the page.

To assist you in building these types of features, Laravel makes it easy to "broadcast" your server-side Laravel events over a WebSocket connection. Broadcasting your Laravel events allows you to share the same event names and data between your server-side Laravel application and your client-side JavaScript application.

The core concepts behind broadcasting are simple: clients connect to named channels on the frontend, while your Laravel application broadcasts events to these channels on the backend. These events can contain any additional data you wish to make available to the frontend.

<a name="supported-drivers"></a>