bhavin-gajjar/laravel-coder-lora-train huggingface dataset:
[Laravel 13] 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 13] Explain artisan: Usage

Tinker allows you to interact with your entire Laravel application on the command line, including your Eloquent models, jobs, events, and more. To enter the Tinker environment, run the tinker Artisan command:

You can publish Tinker's configuration file using the vendor:publish command:

> [!WARNING]
> The dispatch helper function and dispatch method on the Dispatchable class depend on garbage collection to place the job on the queue. Therefore, when using Tinker, you should use Bus::dispatch or Queue::push to dispatch jobs.

<a name="command-allow-list"></a>
[Laravel 13] 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 13] 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 13] 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 13] 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 13] 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 13] Explain authentication: Laravel's Built-in Browser Authentication Services

Laravel includes built-in authentication and session services which are typically accessed via the Auth and Session facades. These features provide cookie-based authentication for requests that are initiated from web browsers. They provide methods that allow you to verify a user's credentials and authenticate the user. In addition, these services will automatically store the proper authentication data in the user's session and issue the user's session cookie. A discussion of how to use these services is contained within this documentation.

**Application Starter Kits**

As discussed in this documentation, you can interact with these authentication services manually to build your application's own authentication layer. However, to help you get started more quickly, we have released free starter kits that provide robust, modern scaffolding of the entire authentication layer.

<a name="laravels-api-authentication-services"></a>
[Laravel 13] 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 13] 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 13] 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 13] 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 13] 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 13] Explain authorization: Supplying Additional Context

The gate methods for authorizing abilities (allows, denies, check, any, none, authorize, can, cannot) and the authorization Blade directives (@can, @cannot, @canany) can receive an array as their second argument. These array elements are passed as parameters to the gate closure, and can be used for additional context when making authorization decisions:

<a name="gate-responses"></a>
[Laravel 13] 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 13] 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 13] 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 13] 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 13] Explain billing: API Keys

Next, you should configure your Stripe API keys in your application's .env file. You can retrieve your Stripe API keys from the Stripe control panel:

> [!WARNING]
> You should ensure that the STRIPE_WEBHOOK_SECRET environment variable is defined in your application's .env file, as this variable is used to ensure that incoming webhooks are actually from Stripe.

<a name="currency-configuration"></a>
[Laravel 13] 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
    - Fonts
    - 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 13] 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 13] 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 13] 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 13] Explain blade: Displaying Unescaped Data

By default, Blade {{ }} statements are automatically sent through PHP's htmlspecialchars function to prevent XSS attacks. If you do not want your data to be escaped, you may use the following syntax:

> [!WARNING]
> Be very careful when echoing content that is supplied by users of your application. You should typically use the escaped, double curly brace syntax to prevent XSS attacks when displaying user supplied data.

<a name="blade-and-javascript-frameworks"></a>
[Laravel 13] Explain boost: Laravel Boost

- Introduction
- Installation
    - Set Up Your Agents
    - Keeping Boost Resources Updated
- 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 13] 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 13] 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 13] 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:

By default, the boost:update command will only update the existing Boost resources already published within your application. If you would like Boost to scan your application for any newly installed packages and offer to publish their corresponding guidelines and skills, you may use the --discover option:

<a name="mcp-server"></a>