bhavin-gajjar/laravel-coder-lora-train huggingface dataset:
[Laravel 13] Explain boost: Available MCP Tools

<div class="overflow-auto">

| Name                 | Notes                                                                                                       |
| -------------------- | ----------------------------------------------------------------------------------------------------------- |
| Application Info     | Read PHP & Laravel versions, database engine, list of ecosystem packages with versions, and Eloquent models |
| Browser Logs         | Read logs and errors from the browser                                                                       |
| Database Connections | Inspect available database connections, including the default connection                                    |
| Database Query       | Execute a query against the database                                                                        |
| Database Schema      | Read the database schema                                                                                    |
| Get Absolute URL     | Convert relative path URIs to absolute so agents generate valid URLs                                        |
| Last Error           | Read the last error from the application's log files                                                        |
| Read Log Entries     | Read the last N log entries                                                                                 |
| Search Docs          | Query the Laravel hosted documentation API service to retrieve documentation based on installed packages    |

</div>

<a name="manually-registering-the-mcp-server"></a>
[Laravel 13] 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, Vue, or Svelte
- 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 13] 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>
[Laravel 13] Explain broadcasting: Quickstart

By default, broadcasting is not enabled in new Laravel applications. You may enable broadcasting using the install:broadcasting Artisan command:

The install:broadcasting command will prompt you for which event broadcasting service you would like to use. In addition, it will create the config/broadcasting.php configuration file and the routes/channels.php file where you may register your application's broadcast authorization routes and callbacks.

Laravel supports several broadcast drivers out of the box: Laravel Reverb, Pusher Channels, Ably, and a log driver for local development and debugging. Additionally, a null driver is included which allows you to disable broadcasting during testing. A configuration example is included for each of these drivers in the config/broadcasting.php configuration file.

All of your application's event broadcasting configuration is stored in the config/broadcasting.php configuration file. Don't worry if this file does not exist in your application; it will be created when you run the install:broadcasting Artisan command.

<a name="quickstart-next-steps"></a>
[Laravel 13] Explain broadcasting: Next Steps

Once you have enabled event broadcasting, you're ready to learn more about defining broadcast events and listening for events. If you're using Laravel's React, Vue, or Svelte starter kits, you may listen for events using Echo's useEcho hook.

> [!NOTE]
> Before broadcasting any events, you should first configure and run a queue worker. All event broadcasting is done via queued jobs so that the response time of your application is not seriously affected by events being broadcast.

<a name="server-side-installation"></a>
[Laravel 13] Explain broadcasting: Server Side Installation

To get started using Laravel's event broadcasting, we need to do some configuration within the Laravel application as well as install a few packages.

Event broadcasting is accomplished by a server-side broadcasting driver that broadcasts your Laravel events so that Laravel Echo (a JavaScript library) can receive them within the browser client. Don't worry - we'll walk through each part of the installation process step-by-step.

<a name="reverb"></a>
[Laravel 13] Explain cache: Cache

- Introduction
- Configuration
    - Driver Prerequisites
- Cache Usage
    - Obtaining a Cache Instance
    - Retrieving Items From the Cache
    - Storing Items in the Cache
    - Extending Item Lifetime
    - Removing Items From the Cache
    - Cache Memoization
    - The Cache Helper
- Cache Tags
- Atomic Locks
    - Managing Locks
    - Managing Locks Across Processes
    - Refreshing Locks
    - Concurrency Limiting
- Cache Failover
- Adding Custom Cache Drivers
    - Writing the Driver
    - Registering the Driver
- Events

<a name="introduction"></a>
[Laravel 13] Explain cache: Introduction

Some of the data retrieval or processing tasks performed by your application could be CPU intensive or take several seconds to complete. When this is the case, it is common to cache the retrieved data for a time so it can be retrieved quickly on subsequent requests for the same data. The cached data is usually stored in a very fast data store such as Memcached or Redis.

Thankfully, Laravel provides an expressive, unified API for various cache backends, allowing you to take advantage of their blazing fast data retrieval and speed up your web application.

<a name="configuration"></a>
[Laravel 13] Explain cache: Configuration

Your application's cache configuration file is located at config/cache.php. In this file, you may specify which cache store you would like to be used by default throughout your application. Laravel supports popular caching backends like Memcached, Redis, DynamoDB, relational databases, and filesystem disks out of the box. In addition, a file based cache driver is available, while array and null cache drivers provide convenient cache backends for your automated tests.

The cache configuration file also contains a variety of other options that you may review. By default, Laravel is configured to use the database cache driver, which stores the serialized, cached objects in your application's database.

<a name="driver-prerequisites"></a>
[Laravel 13] Explain cache: Memcached

Using the Memcached driver requires the Memcached PECL package to be installed. You may list all of your Memcached servers in the config/cache.php configuration file. This file already contains a memcached.servers entry to get you started:

If needed, you may set the host option to a UNIX socket path. If you do this, the port option should be set to 0:

<a name="redis"></a>
[Laravel 13] Explain cache: Redis

Before using a Redis cache with Laravel, you will need to either install the PhpRedis PHP extension via PECL or install the predis/predis package (~2.0) via Composer. Laravel Sail already includes this extension. In addition, official Laravel application platforms such as Laravel Cloud and Laravel Forge have the PhpRedis extension installed by default.

For more information on configuring Redis, consult its Laravel documentation page.

<a name="storage"></a>
[Laravel 13] Explain cashier paddle: Laravel Cashier (Paddle)

- Introduction
- Upgrading Cashier
- Installation
    - Paddle Sandbox
- Configuration
    - Billable Model
    - API Keys
    - Paddle JS
    - Currency Configuration
    - Overriding Default Models
- Quickstart
    - Selling Products
    - Selling Subscriptions
- Checkout Sessions
    - Overlay Checkout
    - Inline Checkout
    - Guest Checkouts
- Price Previews
    - Customer Price Previews
    - Discounts
- Customers
    - Customer Defaults
    - Retrieving Customers
    - Creating Customers
- Subscriptions
    - Creating Subscriptions
    - Checking Subscription Status
    - Subscription Single Charges
    - Updating Payment Information
    - Changing Plans
    - Subscription Quantity
    - Subscriptions With Multiple Products
    - Multiple Subscriptions
    - Pausing Subscriptions
    - Canceling Subscriptions
- Subscription Trials
    - With Payment Method Up Front
    - Without Payment Method Up Front
    - Extend or Activate a Trial
- Handling Paddle Webhooks
    - Defining Webhook Event Handlers
    - Verifying Webhook Signatures
- Single Charges
    - Charging for Products
    - Refunding Transactions
    - Crediting Transactions
- Transactions
    - Past and Upcoming Payments
- Testing

<a name="introduction"></a>
[Laravel 13] Explain cashier paddle: Introduction

> [!WARNING]
> This documentation is for Cashier Paddle 2.x's integration with Paddle Billing. If you're still using Paddle Classic, you should use Cashier Paddle 1.x.

Laravel Cashier Paddle provides an expressive, fluent interface to Paddle's subscription billing services. It handles almost all of the boilerplate subscription billing code you are dreading. In addition to basic subscription management, Cashier can handle: swapping subscriptions, subscription "quantities", subscription pausing, cancelation grace periods, and more.

Before digging into Cashier Paddle, we recommend you also review Paddle's concept guides and API documentation.

<a name="upgrading-cashier"></a>
[Laravel 13] Explain cashier paddle: Installation

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

Next, you should publish the Cashier migration files using the vendor:publish Artisan command:

Then, you should run your application's database migrations. The Cashier migrations will create a new customers table. In addition, new subscriptions and subscription_items tables will be created to store all of your customer's subscriptions. Lastly, a new transactions table will be created to store all of the Paddle transactions associated with your customers:

> [!WARNING]
> To ensure Cashier properly handles all Paddle events, remember to set up Cashier's webhook handling.

<a name="paddle-sandbox"></a>
[Laravel 13] Explain cashier paddle: Paddle Sandbox

During local and staging development, you should register a Paddle Sandbox account. This account will give you a sandboxed environment to test and develop your applications without making actual payments. You may use Paddle's test card numbers to simulate various payment scenarios.

When using the Paddle Sandbox environment, you should set the PADDLE_SANDBOX environment variable to true within your application's .env file:

After you have finished developing your application you may apply for a Paddle vendor account. Before your application is placed into production, Paddle will need to approve your application's domain.

<a name="configuration"></a>
[Laravel 13] Explain collections: Introduction

The Illuminate\Support\Collection class provides a fluent, convenient wrapper for working with arrays of data. For example, check out the following code. We'll use the collect helper to create a new collection instance from the array, run the strtoupper function on each element, and then remove all empty elements:

As you can see, the Collection class allows you to chain its methods to perform fluent mapping and reducing of the underlying array. In general, collections are immutable, meaning every Collection method returns an entirely new Collection instance.

<a name="creating-collections"></a>
[Laravel 13] Explain collections: Extending Collections

Collections are "macroable", which allows you to add additional methods to the Collection class at run time. The Illuminate\Support\Collection class' macro method accepts a closure that will be executed when your macro is called. The macro closure may access the collection's other methods via $this, just as if it were a real method of the collection class. For example, the following code adds a toUpper method to the Collection class:

Typically, you should declare collection macros in the boot method of a service provider.

<a name="macro-arguments"></a>
[Laravel 13] Explain collections: Available Methods

For the majority of the remaining collection documentation, we'll discuss each method available on the Collection class. Remember, all of these methods may be chained to fluently manipulate the underlying array. Furthermore, almost every method returns a new Collection instance, allowing you to preserve the original copy of the collection when necessary:

<style>
    .collection-method-list > p {
        columns: 10.8em 3; -moz-columns: 10.8em 3; -webkit-columns: 10.8em 3;
    }

    .collection-method-list a {
        display: block;
        overflow: hidden;
        text-overflow: ellipsis;
        white-space: nowrap;
    }
</style>

<div class="collection-method-list" markdown="1">

after
all
average
avg
before
chunk
chunkWhile
collapse
collapseWithKeys
collect
combine
concat
contains
containsStrict
count
countBy
crossJoin
dd
diff
diffAssoc
diffAssocUsing
diffKeys
doesntContain
doesntContainStrict
dot
dump
duplicates
duplicatesStrict
each
eachSpread
ensure
every
except
filter
first
firstOrFail
firstWhere
flatMap
flatten
flip
forget
forPage
fromJson
get
groupBy
has
hasAny
hasMany
hasSole
implode
intersect
intersectUsing
intersectAssoc
intersectAssocUsing
intersectByKeys
isEmpty
isNotEmpty
join
keyBy
keys
last
lazy
macro
make
map
mapInto
mapSpread
mapToGroups
mapWithKeys
max
median
merge
mergeRecursive
min
mode
multiply
nth
only
pad
partition
percentage
pipe
pipeInto
pipeThrough
pluck
pop
prepend
pull
push
put
random
range
reduce
reduceSpread
reject
replace
replaceRecursive
reverse
search
select
shift
shuffle
skip
skipUntil
skipWhile
slice
sliding
sole
some
sort
sortBy
sortByDesc
sortDesc
sortKeys
sortKeysDesc
sortKeysUsing
splice
split
splitIn
sum
take
takeUntil
takeWhile
tap
times
toArray
toJson
toPrettyJson
transform
undot
union
unique
uniqueStrict
unless
unlessEmpty
unlessNotEmpty
unwrap
value
values
when
whenEmpty
whenNotEmpty
where
whereStrict
whereBetween
whereIn
whereInStrict
whereInstanceOf
whereNotBetween
whereNotIn
whereNotInStrict
whereNotNull
whereNul
[Laravel 13] Explain concurrency: How it Works

Laravel achieves concurrency by serializing the given closures and dispatching them to a hidden Artisan CLI command, which unserializes the closures and invokes it within its own PHP process. After the closure has been invoked, the resulting value is serialized back to the parent process.

The Concurrency facade supports three drivers: process (the default), fork, and sync.

The fork driver offers improved performance compared to the default process driver, but it may only be used within PHP's CLI context, as PHP does not support forking during web requests. Before using the fork driver, you need to install the spatie/fork package:

The sync driver is primarily useful during testing when you want to disable all concurrency and simply execute the given closures in sequence within the parent process.

<a name="running-concurrent-tasks"></a>
[Laravel 13] Explain concurrency: Running Concurrent Tasks

To run concurrent tasks, you may invoke the Concurrency facade's run method. The run method accepts an array of closures which should be executed simultaneously in child PHP processes:

To use a specific driver, you may use the driver method:

Or, to change the default concurrency driver, you should publish the concurrency configuration file via the config:publish Artisan command and update the default option within the file:

<a name="named-results"></a>
[Laravel 13] Explain configuration: The `about` Command

Laravel can display an overview of your application's configuration, drivers, and environment via the about Artisan command.

If you're only interested in a particular section of the application overview output, you may filter for that section using the --only option:

Or, to explore a specific configuration file's values in detail, you may use the config:show Artisan command:

<a name="environment-configuration"></a>
[Laravel 13] Explain configuration: Environment Configuration

It is often helpful to have different configuration values based on the environment where the application is running. For example, you may wish to use a different cache driver locally than you do on your production server.

To make this a cinch, Laravel utilizes the DotEnv PHP library. In a fresh Laravel installation, the root directory of your application will contain a .env.example file that defines many common environment variables. During the Laravel installation process, this file will automatically be copied to .env.

Laravel's default .env file contains some common configuration values that may differ based on whether your application is running locally or on a production web server. These values are then read by the configuration files within the config directory using Laravel's env function.

If you are developing with a team, you may wish to continue including and updating the .env.example file with your application. By putting placeholder values in the example configuration file, other developers on your team can clearly see which environment variables are needed to run your application.

> [!NOTE]
> Any variable in your .env file can be overridden by external environment variables such as server-level or system-level environment variables.

<a name="environment-file-security"></a>
[Laravel 13] Explain configuration: Environment File Security

Your .env file should not be committed to your application's source control, since each developer / server using your application could require a different environment configuration. Furthermore, this would be a security risk in the event an intruder gains access to your source control repository, since any sensitive credentials would get exposed.

However, it is possible to encrypt your environment file using Laravel's built-in environment encryption. Encrypted environment files may be placed in source control safely.

<a name="additional-environment-files"></a>
[Laravel 13] Explain console tests: Success / Failure Expectations

To get started, let's explore how to make assertions regarding an Artisan command's exit code. To accomplish this, we will use the artisan method to invoke an Artisan command from our test. Then, we will use the assertExitCode method to assert that the command completed with a given exit code:

You may use the assertNotExitCode method to assert that the command did not exit with a given exit code:

Of course, all terminal commands typically exit with a status code of 0 when they are successful and a non-zero exit code when they are not successful. Therefore, for convenience, you may utilize the assertSuccessful and assertFailed assertions to assert that a given command exited with a successful exit code or not:

<a name="input-output-expectations"></a>
[Laravel 13] Explain console tests: Input / Output Expectations

Laravel allows you to easily "mock" user input for your console commands using the expectsQuestion method. In addition, you may specify the exit code and text that you expect to be output by the console command using the assertExitCode and expectsOutput methods. For example, consider the following console command:

You may test this command with the following test:

If you are utilizing the search or multisearch functions provided by Laravel Prompts, you may use the expectsSearch assertion to mock the user's input, search results, and selection:

You may also assert that a console command does not generate any output using the doesntExpectOutput method:

The expectsOutputToContain and doesntExpectOutputToContain methods may be used to make assertions against a portion of the output:

<a name="confirmation-expectations"></a>
[Laravel 13] Explain container: Service Container

- Introduction
    - Zero Configuration Resolution
    - When to Utilize the Container
- Binding
    - Binding Basics
    - Binding Interfaces to Implementations
    - Contextual Binding
    - Contextual Attributes
    - Binding Primitives
    - Binding Typed Variadics
    - Tagging
    - Extending Bindings
- Resolving
    - The Make Method
    - Automatic Injection
- Method Invocation and Injection
- Container Events
    - Rebinding
- PSR-11

<a name="introduction"></a>
[Laravel 13] Explain container: Introduction

The Laravel service container is a powerful tool for managing class dependencies and performing dependency injection. Dependency injection is a fancy phrase that essentially means this: class dependencies are "injected" into the class via the constructor or, in some cases, "setter" methods.

Let's look at a simple example:

In this example, the PodcastController needs to retrieve podcasts from a data source such as Apple Music. So, we will **inject** a service that is able to retrieve podcasts. Since the service is injected, we are able to easily "mock", or create a dummy implementation of the AppleMusic service when testing our application.

A deep understanding of the Laravel service container is essential to building a powerful, large application, as well as for contributing to the Laravel core itself.

<a name="zero-configuration-resolution"></a>
[Laravel 13] Explain container: Zero Configuration Resolution

If a class has no dependencies or only depends on other concrete classes (not interfaces), the container does not need to be instructed on how to resolve that class. For example, you may place the following code in your routes/web.php file:

In this example, hitting your application's / route will automatically resolve the Service class and inject it into your route's handler. This is game changing. It means you can develop your application and take advantage of dependency injection without worrying about bloated configuration files.

Thankfully, many of the classes you will be writing when building a Laravel application automatically receive their dependencies via the container, including controllers, event listeners, middleware, and more. Additionally, you may type-hint dependencies in the handle method of queued jobs. Once you taste the power of automatic and zero configuration dependency injection it feels impossible to develop without it.

<a name="when-to-use-the-container"></a>