The Great Laravel Soiree: An Eventful Revelry! 🎉🎊

A Grand Introduction 👋🏻

Welcome to the wild world of Laravel Events! Here’s where you’ll learn to turn your app into a dance floor, letting it groove to custom actions when triggered. 💃🏼🕺🏼

Cue the Sparklers: Generating Events and Listeners 🔥✨

Ever wanted your app to do a moonwalk? That’s what events are for! Generate ‘em, then assign some cool listeners to make it dance. 🕺🏼💃🏼

Let the Party Begin: Registering Events and Listeners 🎉🎊

Invite your cool new friends (events) over to your party, then introduce them to the right crowd (listeners). You can do it automatically or personally - whatever tickles your fancy. 🤝🏻💃🏼

The Matchmaker: Event Discovery 🧔🏻👰🏼‍♀️

Laravel’s matchmaking service helps introduce events and listeners without the need for a formal introduction. Just let them bump into each other at the right party! 💃🏼🕺🏼🤝🏻

The Party Planner: Manually Registering Events 📝🎨

If you’re more of a control freak, manually register events. Just make sure they find the right listeners to keep the party going! 🕺🏼💃🏼🤝🏻

The Closure Companion: Closure Listeners 📜👥

Closure listeners are like that friend who always knows the right thing to say or do. They’re flexible, easy to make, and can be a real hit at your app party! 💃🏼🕺🏼🤝🏻

The Party Host: Defining Events 🎫🎉

Design your own events - the theme, the music, even the dress code! Just remember to make them interesting enough for the cool kids (listeners) to show up. 💃🏼🕺🏼🤝🏻

The Guest List: Defining Listeners 👥🎫

Decide who gets to attend your event - the cool, fun listeners. They’ll be responsible for making sure everything runs smoothly and everyone has a great time! 💃🏼🕺🏼🤝🏻

The VIP Room: Queued Event Listeners 🎫🥳

Need to handle some heavy lifting? Put your event listeners in the VIP room - they’ll get processed later, ensuring your party doesn’t slow down. 🕺🏼💃🏼🤝🏻

Backstage Pass: Manually Interacting With the Queue 🎫STAGESTAGE🎫

If you want to hang out with your VIP listeners, use a backstage pass to interact directly with the queue. Just don’t let them see you sweat! 🕺🏼💃🏼🤝🏻

The Transaction Tango: Queued Event Listeners and Database Transactions 💰💸💵

When your VIP listeners need to do some serious banking, make sure they’re wrapped in a transaction. It keeps everything neat and tidy - just like a tango! 🕺🏼💃🏼🤝🏻

The Security Detail: Queued Listener Middleware 👨‍✈️👩‍✈️🔒

Add some security to your VIP area with middleware. It’ll make sure only the coolest listeners get in, and keep things running smoothly at the party! 🕺🏼💃🏼🤝🏻

The Safe: Encrypted Queued Listeners 🔐📦🔒

If you want to keep some secrets from the other listeners, encrypt your VIP listeners’ code. Just make sure they know how to unlock it when they arrive! 🕺🏼💃🏼🤝🏻

The Bouncer: Unique Event Listeners 🔒🛑🔓

Keep unwanted listeners from joining the same event by using unique locks. It’ll make sure everything runs smoothly, and no one gets left out of the fun! 🕺🏼💃🏼🤝🏻

The First Come, First Served Policy: Keeping Listeners Unique Until Processing Begins 🕒⏰📝

Make sure your bouncer sticks to the first come, first served policy. It’ll ensure a smooth flow of listeners and prevent chaos at the party! 🕺🏼💃🏼🤝🏻

The VIP Lounge: Unique Listener Locks 🔓🛑🎫

Give your VIP listeners their own exclusive lounge with unique listener locks. It’ll keep them separated from the general population and make your party run smoother! 🕺🏼💃🏼🤝🏻

The Party Cleanup Crew: Handling Failed Jobs 🚮🗑️🧹

When some listeners can’t keep up with the party, assign a cleanup crew to handle failed jobs. They’ll make sure everything stays tidy and runs smoothly! 🕺🏼💃🏼🤝🏻

The Event Announcer: Dispatching Events 🎉🎊📣

Ready to get the party started? Announce your events with dispatch, and let the good times roll! 🕺🏼💃🏼🤝🏻

The Afterparty: Dispatching Events After Database Transactions 🎊🎉📝

If your database needs a little time to process things, dispatch events during the afterparty. It’ll keep the main party going while your listeners catch up! 🕺🏼💃🏼🤝🏻

The Rain Check: Deferring Events 📅☎️🔔

If you can’t throw the event right away, defer it! Your listeners will get a rain check, and you can plan the perfect party later. 🕺🏼💃🏼🤝🏻

The Social Butterfly: Event Subscribers 👥🎫🌹

Event subscribers are like the social butterflies of your app - they flit from event to event, making sure everything runs smoothly and everyone has a great time! 🕺🏼💃🏼🤝🏻

The Socialite: Writing Event Subscribers 👥🎫🌹

If you want to be the life of the party, write your own event subscribers! Just make sure they’re charming, friendly, and know how to have a good time. 🕺🏼💃🏼🤝🏻

The Party Planner: Registering Event Subscribers 📝🎫🎉

Once your event subscribers are ready to go, register them! They’ll be the life of every party from now on. 🕺🏼💃🏼🤝🏻

The Quality Assurance Squad: Testing 📝☑️🎯

Don’t forget to test your event management skills! Your quality assurance squad will make sure everything runs smoothly at every party. 🕺🏼💃🏼🤝🏻

The Practice Session: Faking a Subset of Events 🎬📽️🔄

Practice makes perfect! Fake a subset of events to test your event management skills before the real party starts. 🕺🏼💃🏼🤝🏻

The Themed Party: Scoped Event Fakes 🎉🎊🎭

Plan a themed party and use scoped event fakes to test your skills in specific scenarios. It’ll help you become the ultimate event manager! 🕺🏼💃🏼🤝🏻

Welcome to Laravel’s Eventful Adventure! 🚀🎊

Get ready to unleash the power of our superheroic event system, providing a fun and easy implementation of the legendary Observer pattern. It’s like inviting Spider-Man to join your party, he just shows up when something exciting happens! 🕷️🎉

Your events hang out in the app/Events directory, while their pals (listeners) reside in the app/Listeners. If you don’t find these neighborhoods in your application yet, fear not! Laravel will build them for you as soon as you summon events and listeners with Artisan console commands. 🏗️👷‍♂️

Events are the perfect icebreaker to decouple different parts of your application, making it a giant party where everyone can mingle without stepping on each other’s toes! For instance, you might want to send a Slack message (party invite) every time an order has been shipped (arrived). Instead of having your order processing code crash the dance floor with your Slack notification code, let your event system host a grand ball where listeners can listen in and use the news of an App\Events\OrderShipped to dispatch a Slack message. 🎧💫

Now, gather ‘round for the secret recipe on how to summon events and listeners with Artisan console commands! (Cue dramatic music) 🎶🎺

Alrighty, let’s dive into the world of Laravel events and listeners! It’s like the party planning committee of your app – they celebrate (or mourn) whenever something significant happens. To get this bash started, you can use the magical make:event and make:listener Artisan commands:

php artisan make:event PodcastProcessed 🎧 (It's like naming your newborn baby)

php artisan make:listener SendPodcastNotification --event=PodcastProcessed (Now you have the perfect date for sending notifications)

But wait, there’s more! For those lazy bones who can’t be bothered to type out the whole name, Laravel offers a shortcut. You can omit the arguments:

php artisan make:event 👋 (Laravel will ask you what the heck it should call this event)

php artisan make:listener 🎉 (And of course, it'll also ask who the lucky event is that this listener will be hanging out with)

Now, you might be wondering how these events and listeners end up getting invited to your app’s party. Well, my friend, there’s a section for that – the event registration area! It’s like the guest list for your bash, where you can add your events and listeners so they know when to show up.

Alright, buckle up, programming cowboys! Let’s dive into Laravel’s wild west of events and listeners—where every shootout is a symphony of code harmony! 🤠

First off, it’s essential to understand that an event in Laravel isn’t just another excuse for a rodeo; it’s a way for different components to communicate without knowing each other intimately. You know, like cowboys sending smoke signals without sharing their secret chicken recipes! 🐔

So how do we register these events and listeners? Fear not, young gun, for there’s an Event Service Provider waiting to help you out! Just create a new provider in the app/Providers directory, register it in your config/app.php, and fire away with your listener classes.

Now, listeners are like that quirky bartender in Dodge City who knows everyone’s business but doesn’t judge—they listen to events and perform actions when triggered. You can create a custom listener by implementing the EventSubscriber interface or extending the Subscription class. But hey, we ain’t here for formal dances; let’s get our hands dirty with some code!

namespace App\Listeners;

use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Auth\Events\Registered;

class WelcomeEmailSubscriber implements ShouldQueue
{
    public function handle(Registered $event)
    {
        // Send welcome email here!
    }
}

And that’s a wrap, partner! Registering events and listeners in Laravel is as easy as roasting marshmallows over a campfire—and way more fun too! Now go forth and make your Laravel herd sing harmonious tunes with custom event handling! 🎵🌈🐄🎉

Ahoy there, Laravel pirates! 🌴🐻 Let’s set sail through the choppy waters of Event Discovery, shall we? By default, our trusty ship (your Laravel app) will auto-magically hoist your event listeners like Jolly Roger flags by rummaging through your application’s Listeners port (directory). 🏴‍☠️

If it stumbles upon any listener captain (class) with a method that kicks off with “handle” or “__invoke”, it’ll rope them in as event listeners for the event that they type-hinted like a parrot on their shoulder.

Use yer old peg-leg, App\Events\PodcastProcessed;

Class SendPodcastNotification {
    /**
     * Listen up, matey!
     */
    public function handle(PodcastProcessed $event): void {
        // Arrrgh... Do some stuff! 🍻
    }
}

Want to listen to multiple events? Why not use PHP’s union types (or union squids, as I like to call ‘em)?

/**
 * Listen up, matey!
 */
public function handle(PodcastProcessed|PodcastPublished $event): void {
    // Arrrgh... Do some stuff for two events now! 🍻🐳
}

If ye plan to stow away your listeners in a different port or multiple ports, ye can guide Laravel to scan those with the withEvents method in yer ship’s bootstrap (bootstrap/app.php).

->withEvents(discover: [
    __DIR__.'/../app/Domain/Orders/Listeners',
])

Ye can scan for listeners in multiple similar ports using the * character as a wildcard:

->withEvents(discover: [
    __DIR__.'/../app/Domain/*/Listeners',
])

To check which event listeners ye have on board, ye can issue the event:list command. 📜

php artisan event:list

Now that we’ve sailed through the shores of Event Discovery, let’s raise the Jolly Roger and conquer the seas of Laravel together! Yarr! 🏴‍☠️🐳

Alright, let’s get this party started! To make your app faster than a cheetah on roller skates, you need to cache a swanky disco ball of all your application’s listeners. You can do this by running the optimize or event:cache Artisan commands, which are like the bouncers at a cool club checking guest lists before letting them in.

Usually, this command should be run during your app’s deployment process. Think of it as pre-gaming with caffeine! This disco ball will help the framework speed-dance through the event registration process. If you ever feel like you need a fresh start (maybe after a wild night), you can always use the event:clear command to dump this disco ball into the dancefloor recycling bin.

Now, if you’re feeling extra fancy and want to manually register events, feel free to cut in line and skip the bouncer! Just remember, while it’s fun to be the life of the party, don’t forget that a little organization goes a long way. Happy coding! 💃🕺🚀

Alright, buckle up, Laravel enthusiasts! We’re about to dive into a whirlwind adventure of event registration, but fear not, for this journey will be as amusing as it is informative.

So, you wanna register events like a pro? Well, grab your trusty Event facade and let’s get started! You can manually register events and their loyal listeners right inside the boot method of your application’s AppServiceProvider. Don’t worry if it sounds fancy – think of it as inviting your pals to a party (only here, they’ll be handling events instead of RSVPs).

Use PodcastProcessed as your house party's hot topic, SendPodcastNotification as the trusty messenger who'll spread the news, and Event as the matchmaker that introduces them.

/**
 * Bootstrap any application services.
 */
public function boot(): void
{
    Event::listen(
        PodcastProcessed::class, // Hey Event! Here's our party theme - PodcastProcessed!
        SendPodcastNotification::class, // This is our messenger, SendPodcastNotification.
    );
}

Want to know who else’s been invited to the event? No problem! Just use the event:list command like a VIP guest list scanner and take a peek at all the registered listeners within your application:

php artisan event:list

Now, aren’t you feeling like the event mastermind already? Go on, register those events and let the party begin! 🥳🎉

Closure Chatterboxes! 🗣️🤖

In the grand tradition of parties where everyone’s got a different dance move, Laravel events can be joined by various listeners - some classy, some not-so-much. But did you know you can also rock up uninvited with your own anonymous closure listener? 😎

Here’s how to crash the event with style:

Use the force, Obi-Wan! I mean...

use App\Events\PodcastProcessed;
use Illuminate\Support\Facades\Event;

/**
 * A galactic dancefloor where services get busy. 💃️🕺️
 */
public function boot(): void
{
    // Break the fourth wall and join the event like a true intergalactic DJ!
    Event::listen(function (PodcastProcessed $event) {
        // ...
    });
}

Don’t forget to keep your closure tight-lipped about any sensitive data or else you might end up as the life of the party… 🤫

Alright, let’s dive into the delightful world of Laravel’s Queueable Anonymous Event Listeners! You know, the party animals of the PHP event scene. 🥳

When you want to throw a bash (register an event listener), but don’t wanna commit to a plus one just yet (closure-based), wrap that casual acquaintance within the fabulous Illuminate\Events\queueable shindig! This fancy function tells Laravel, “Hey buddy, let’s get this party started using the queue!” 🎧

use App\Events\PodcastProcessed;
use function Illuminate\Events\queueable;
use Illuminate\Support\Facades\Event;

public function boot(): void
{
    Event::listen(queueable(function (PodcastProcessed $event) {
        // ...
    }));
}

Now, just like queued jobs, you can customize the bash with the onConnection, onQueue, and delay methods:

Event::listen(queueable(function (PodcastProcessed $event) {
    // ...
})->onConnection('redis')->onQueue('podcasts')->delay(now()->plus(seconds: 10)));

But what if your bash gets crashed (listener fails)? Fear not! You can provide a closure to the catch method while defining the queueable listener. This closure will be there to clean up the mess and handle those unexpected guests (Throwables) that crashed the party:

use App\Events\PodcastProcessed;
use function Illuminate\Events\queueable;
use Illuminate\Support\Facades\Event;
use Throwable;

Event::listen(queueable(function (PodcastProcessed $event) {
    // ...
})->catch(function (PodcastProcessed $event, Throwable $e) {
    // Oops! The queued listener failed...
}));

Now you’re all set to host the most fabulous event listeners in town! 🎉

Ahoy there, code cowboys and codettes! Let’s gallop into the world of Laravel’s event listeners, where even the wildest events can be tamed with a sprinkle of PHP magic.

First off, you might be wondering: what’s the deal with these starry-eyed (get it?) listeners? Well, they’re like the groupies of the coding world - ready to catch any event that comes their way! By using the * character as a wildcard param, you can hook them up to multiple events without breaking a sweat.

Here’s a little example of how these listeners strut their stuff:

Event::listen('event.*', function (string $eventName, array $data) {
    // ... This is where the real party starts!
});

In this code snippet, our wildcard listener is waiting in the wings for any event starting with ‘event.’. When an event happens, it’ll receive two arguments - the name of the event as a $string and the entire event data array as a $data[]. So, if you want to listen for all sorts of events without creating a hundred different listeners, this is your ticket to the dance!

Just remember: these wildcard listeners are like those one-size-fits-all cowboy hats. They work well in a pinch, but sometimes you might need something more specific to handle each event with finesse (check out Laravel’s documentation for Defining Events if that tickles your fancy).

Happy coding, y’all! 🤠

Alrighty, let’s unravel the mysteries of Laravel events! Imagine you’re throwing a party and an event class is like your invitation - it carries all the crucial details but doesn’t exactly know what the night will bring.

Take our pal OrderShipped for instance:

<?php

namespace App\Events;

use App\Models\Order;
use Illuminate\Broadcasting\InteractsWithSockets;
use Illuminate\Foundation\Events\Dispatchable;
use Illuminate\Queue\SerializesModels;

class OrderShipped
{
    use Dispatchable, InteractsWithSockets, SerializesModels;

    /**
     * Create a new event instance.
     */
    public function __construct(
        public Order $order,
    ) {}
}

Now, you’re probably thinking - “But this event class is as dry as a desert! Where’s the fun?” Well, fear not, for it’s more of a container party favor than a party animal. It stores that swanky App\Models\Order guest who just made a purchase.

The SerializesModels trait, on the other hand, is like the event’s designated bartender - making sure all Eloquent models (guests) are properly prepared when the event object (party invitation) gets mixed up with PHP’s serialize function. You know, like during those queued listener dance-offs! 💃🕺️

Now that you’ve got the gist of it, go forth and create more events - because a good party needs many invitations, after all! 🎉🎊

Alrighty, buckle up! We’re about to dive into the world of event listeners in Laravel - it’s like being a superhero with powers activated when events occur!

So, you’ve got this swanky superpower called an OrderShipped event that’s just itching to be handled by someone. That’s where our new friend, SendShipmentNotification, comes in! This chap is here to catch the event instances in his handle method, which is a bit like receiving a mission briefing before diving into action.

Now, creating this guy is as simple as using the make:listener Artisan command, and if you fancy yourself a detective, you can even throw in the --event option to make him automatically import the proper event class (that’s like having your trusty crime lab do the hard work for you). The handle method will then be all tidied up with type-hinting of the event itself.

Inside the handle method, feel free to perform whatever magic is necessary to respond to the event - think of it as a superhero’s secret lair filled with gadgets and gizmos!

Oh, and just in case you need some extra helpers, your event listeners can also type-hint any dependencies they require on their constructors. With Laravel’s superpowered service container handling things automatically, it’s like having a butler who never forgets to bring the tea and biscuits!

Remember, just like in a comic book, you can even stop the propagation of an event if needed (we’ll leave that for another time though). For now, enjoy being a Laravel superhero with these nifty event listeners!

Ahoy there, coding cowpoke! Ever found yourself in a situation where you wished to halt the wild west gunfight of events in Laravel? Fret not, for I shall enlighten you on how to wrangle that rowdy event propagation!

When an event’s outlaw triggers your listener’s saloon, you can put an end to its mischief by returning a humble false from the handle method. This will ensure that further notifications to other law-abiding citizens (listeners) are halted in their tracks, like a coyote snared by a trapper’s snare!

Now, if you’re dealing with events of an asynchronous nature, don’t worry, partner. The trusty Queue will step in to save the day. You can register your listener using the queueable interface, and let it loose on a job queue for processing when the time is right. Once the listener has done its deed, you’ll find it returns the same humble false, ensuring that further event propagation meets its untimely demise! 🤠

Now go forth and tame those events, cowboy! And remember: in Laravel, sometimes returning false is the secret sauce to a well-behaved event!

Alrighty, let’s dive into the whimsical world of Laravel Queue Listeners! 🎉🎧🎙️

These bad boys are perfect for tasks that take longer than your average coffee break - think sending emails or making calls to intergalactic dance-offs (just kidding about the latter). But before you jump in, make sure your server or local development environment is properly outfitted with a queue configuration. Picture it like setting up a funfair ride; you wouldn’t want to start without checking if all the bolts are securely fastened!

To indicate that a listener should be queued, simply sprinkle some ShouldQueue interface magic on your listener class. Listeners generated by our trusty make:listener Artisan commands already come pre-seasoned with this tasty blend of code, so you can start using it right away! 🍴

<?php

namespace App\Listeners;

use App\Events\OrderShipped;
use Illuminate\Contracts\Queue\ShouldQueue;

class SendShipmentNotification implements ShouldQueue
{
    // ...
}

Now when an event handled by this listener is dispatched, it’ll be queued like a boss by the event dispatcher using Laravel’s robust queue system. If the listener executes without throwing any exceptions (like your pet parrot flying into the circuit board), the job will vanish automatically once it’s finished processing - just like a well-timed magic trick! 🎩✨

For those of you who enjoy customizing their queue settings, feel free to do so! You can choose the connection and queue name for your jobs to ensure they’re processed efficiently. It’s like picking out the perfect playlist for a dance party! 💃🕺️

Alrighty then, let’s dive into the ticklish world of Laravel queue customization! 🌊🍔

If you’re feeling fancy and want to personalize your event listener’s connection, name, or delay time, you can sprinkle some magical attributes on your listener class like a fairy dust of code.

<?php

namespace App\Listeners;

use App\Events\OrderShipped;
use Illuminate\Contracts\Queue\ShouldQueue;
// Let's call our listener "Squidward" - just because! 🐙
class SendShipmentNotification implements ShouldQueue
{
    // ...
}
// But now we dress Squidward up in some fancy attributes to make him stand out:
#[Connection('sqs')] // Squidward joins the circus, under the big top called 'sqs'
#[Queue('listeners')] // Squidward starts performing in the 'listeners' show
#[Delay(60)] // Squidward takes a 60-second nap before each performance 😴

Now, if you fancy setting Squidward’s queue connection, name, or delay at runtime, you can teach him a few new tricks with viaConnection, viaQueue, and withDelay methods:

/**
 * Get Squidward's queue connection.
 */
public function viaConnection(): string
{
    return 'sqs'; // "Squidward, get ready to join the big top circus!" 🎪
}

/**
 * Get Squidward's queue name.
 */
public function viaQueue(): string
{
    return 'listeners'; // "Squidward, time for your big debut in the 'listeners' show!" 💃
}

/**
 * Get the number of seconds before Squidward should perform.
 */
public function withDelay(OrderShipped $event): int
{
    return $event->highPriority ? 0 : 60; // "Squidward, if it's a high priority event, skip your nap!" ⏰
}

Now that Squidward is all dressed up and knows his cues, sit back, relax, and watch the magic unfold! 🎬🍿

Alright, let’s dive into the fun world of Laravel queues, where your listeners don’t just dance to the beat of their own drum, but can also decide whether they want to join the party based on some sneaky runtime data!

To make this happen, you’d add a shouldQueue method to your listener, like a bouncer checking IDs at the door. If this method returns false, your listener will politely decline the invitation to the queue:

<?php

namespace App\Listeners;

use App\Events\OrderCreated;
use Illuminate\Contracts\Queue\ShouldQueue;

class RewardGiftCard implements ShouldQueue
{
    /**
     * Reward a gift card to the customer.
     */
    public function handle(OrderCreated $event): void
    {
        // ... (the dance floor)
    }

    /**
     * Determine whether the listener should be queued (or if they're VIP enough to bypass the line).
     */
    public function shouldQueue(OrderCreated $event): bool
    {
        return $event->order->subtotal >= 5000; // VIP status check: if subtotal > 5k, queue 'em up!
    }
}

Now, you might be wondering how to interact with this fancy queue system manually. Well, buckle up! Here’s the link to find out more (or scroll down if you’re feeling lazy).

Unleashing the Queue Beast (Manually Interacting With the Queue)

Ah, the thrill of getting your hands dirty with the raw power of our queue system! If you’re the type who enjoys wrestling a tiger instead of riding in a Ferrari, this section is for you.

To access the hidden, mystical delete and release methods of your listener’s queue job, you’ll need to don the powerful Illuminate\Queue\InteractsWithQueue trait. This magical cloak is bestowed upon generated listeners by default, granting you access to these legendary spells:

<?php

namespace App\Listeners;

use App\Events\OrderShipped;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Queue\InteractsWithQueue;

class SendSOSToNemesis implements ShouldQueue
{
    use InteractsWithQueue;

    /**
     * Handle the event.
     */
    public function handle(OrderShipped $event): void
    {
        if ($condition) {
            // Unleash the beast, let it run free for 30 seconds!
            $this->release(30);
        }
    }
}

Cave of Transactions (Queued Event Listeners and Database Transactions)

Now, let’s talk about the perilous cave where database transactions reside. When a queued event listener interacts with the database, it’s essential to ensure that all database operations within the listener are part of a single transaction. This way, if one operation fails, the entire cave remains intact and no chaos ensues!

To accomplish this, you can use Laravel’s built-in database_transactions method. Here’s an example:

<?php

namespace App\Listeners;

use Illuminate\Queue\InteractsWithQueue;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Database\Eloquent\Model;
use Database\Factories\ProductFactory;

class CreateBackups implements ShouldQueue
{
    use InteractsWithQueue;

    /**
     * Handle the event.
     */
    public function handle(): void
    {
        // Begin our daring adventure into the cave of transactions!
        \DB::transaction(function () {
            // Perform database operations here, like creating backups or summoning a dragon.

            $product = ProductFactory::new()->create([
                'name' => 'Dragon's Breath',
                'price' => 'Priceless',
            ]);

            // If you fall into the pit of doom, make sure to rollback all changes!
        });
    }
}

Remember, adventuring in the cave of transactions can be dangerous, but with a little caution and our trusty database_transactions method, you’ll conquer the perils and become a true Laravel master!

Alrighty, let’s dive into the wild world of Laravel’s Queued Event Listeners and Database Transactions! 🐲💣

Imagine this: You’re in the middle of a high-stakes poker game with all your models as chips. Suddenly, someone (the database transaction) announces they’re going to the bathroom, but before they can flush, you get called away to deal with a queued event listener 🎙️. Now, when you return, the game has changed! Your updates have vanished into thin air, and some new models have appeared out of nowhere. You’re left scratching your head and asking “What just happened here?”

Well, this is exactly what can occur when queued listeners are dispatched during active database transactions 🤪. To prevent such chaos, let’s talk about how to ensure your listener doesn’t get caught with their pants down (or models missing)!

First things first: check your queue connection settings. If the after_commit option is set to false, it means your queued listeners might process before the transaction has been fully committed 😱. This can lead to unexpected errors and lost model updates that’ll make you wish you stuck with Texas Hold ‘em instead!

But fear not, dear listener! If you find yourself in this precarious situation, simply implement the ShouldQueueAfterCommit interface on your listener class 🤖. This magical piece of code will ensure your listener hangs around until all open database transactions have been committed and all models are accounted for 🕵️‍♂️.

<?php

namespace App\Listeners;

use Illuminate\Contracts\Queue\ShouldQueueAfterCommit;
use Illuminate\Queue\InteractsWithQueue;

class SendShipmentNotification implements ShouldQueueAfterCommit
{
    use InteractsWithQueue;
}

For more tips on navigating these tricky waters, be sure to check out our comprehensive documentation on queued jobs and database transactions 📚. Happy coding, and may the odds be ever in your favor! 💪✨

Rockin’ Queue Rodeo Middleware! 🎠

Get ready to lasso some fun with our Queued Listener Middleware! It’s like the trusty sidekick your queued listeners never knew they needed. Job middleware is a wrangler that lets you saddle up custom logic for the rodeo of queued listener execution, corralling all that boilerplate right outta town!

Once you’ve roped in some job middleware, it’s time to saddle ‘em up and attach them to your listener. Here’s how you do that cowpoke:

<?php

namespace App\Listeners;

use App\Events\OrderShipped;
use App\Jobs\Middleware\RateLimited as JobSheriff; // Yeah, we named it after Clint Eastwood!
use Illuminate\Contracts\Queue\ShouldQueue;

class SendCattleCallNotification implements ShouldQueue {
    /**
     * Handle the event.
     */
    public function handle(OrderShipped $event): void
    {
        // Saddle up and ride out, partner!
    }

    /**
     * Get the middleware the listener should pass through.
     *
     * @return array<int, object>
     */
    public function middleware(OrderShipped $event): array
    {
        return [new JobSheriff]; // You're welcome for the name change!
    }
}

Now that your listener is all saddled up and ready to ride, sit back and enjoy some well-deserved peace and quiet while Laravel takes care of the rest. Happy queuing, partner! 🤠

Secret Agent Queue Jockeys in Laravel Land! 🕵️‍♂️🚀

Ever wanted to be a super-spy in the world of queued listeners? Well, your dreams have come true! In Laravel, we’ve got you covered with our top-secret data encryption technology. 🔒

To start your new undercover mission, all you need is to sprinkle some secret agent dust (the ShouldBeEncrypted interface) on your listener class. Once this magic formula is applied, Laravel will whip up a tasty encryption cocktail for your covert operation, ensuring your data stays secure as a government vault before it gets zapped onto the queue:

<?php

namespace App\Listeners;

use App\Events\OrderShipped;
use Illuminate\Contracts\Queue\ShouldBeEncrypted; // Here comes the secret agent dust! 💫
use Illuminate\Contracts\Queue\ShouldQueue;

class SendShipmentNotification implements ShouldQueue, ShouldBeEncrypted {
    // ...
}

Now, you’re ready to blend in with the crowd while keeping your sensitive mission data secure! 🕵️‍♂️🚀🔒

One-of-a-kind Event Listeners: The Lone Wolf of the Queue! 🐺

[!ALERT] To be a lone wolf, your listener needs a cache driver that can handle lockdowns. Currently, the memcached, redis, dynamodb, database, file, and array cache drivers have this kind of ‘lock-in’ arrangement.

You might find yourself in a situation where you want to make sure only one specific listener is lounging around on the queue at any given moment. This is achievable by making your listener class join the exclusive ShouldBeUnique pack:

<?php

namespace App\Listeners;

use App\Events\LicenseSaved;
use Illuminate\Contracts\Queue\ShouldBeUnique; // Think of this as a "Membership Card" to the unique club 🏛️
use Illuminate\Contracts\Queue\ShouldQueue;

class AcquireProductKey implements ShouldQueue, ShouldBeUnique
{
    public function __invoke(LicenseSaved $event): void
    {
        // ...
    }
}

In the example above, our AcquireProductKey listener is a lone wolf, so it won’t be added to the queue if another instance of this listener has already joined and hasn’t finished its business. This ensures that only one product key is snatched for each license, even if the license is saved multiple times in rapid succession.

In some cases, you may want to define a specific “secret handshake” or specify a time limit after which this lone wolf can join the queue again. To do so, you can define uniqueId and uniqueFor properties or methods on your listener class. These methods receive the event instance, allowing you to use event data to construct the return value:

<?php

namespace App\Listeners;

use App\Events\LicenseSaved;
use Illuminate\Contracts\Queue\ShouldBeUnique; // Still that exclusive membership card 🏛️
use Illuminate\Contracts\Queue\ShouldQueue;

class AcquireProductKey implements ShouldQueue, ShouldBeUnique
{
    /**
     * The number of seconds after which this lone wolf will abandon its den.
     *
     * @var int
     */
    public $uniqueFor = 3600; // In the wilderness for one hour 🕒

    public function __invoke(LicenseSaved $event): void
    {
        // ...
    }

    /**
     * Get this lone wolf's unique identification.
     */
    public function uniqueId(LicenseSaved $event): string
    {
        return 'listener:'.$event->license->id; // Identified by license ID 🔑
    }
}

In the example above, our AcquireProductKey listener is a lone wolf by license ID. Any new summons of this listener for the same license will be ignored until the existing one has completed its business. This prevents multiple product keys from being acquired for the same license. In addition, if the existing listener is not processed within an hour, the unique lock will be lifted, and another listener with the same unique key can be queued.

[!ALERT] If your pack of listeners is dispatched from multiple web servers or containers, make sure they’re all communicating with the same central cache server so that Laravel can accurately determine if a listener is unique. 🐺🏞️🌲

Alrighty then! Let’s get this listener party started without a hitch – or at least with as few hitches as possible. By default, these Laravel listeners of ours are like the rebellious teenagers who refuse to stay in their rooms until they’ve caused enough chaos and exhausted all their do-over chances. But what if you want your rebel with a cause to stay put? That’s where our little chat about ShouldBeUniqueUntilProcessing comes into play!

In simple terms, this contract is like telling your listener, “Hey, no matter what happens before you start processing, make sure you stay locked and loaded!” By implementing this contract instead of the vanilla ShouldBeUnique, you can ensure that your listener remains unique (and out of trouble) until it’s ready to dive headfirst into its duties.

Here’s a little code snippet to help you wrap your mind around it:

<?php

namespace App\Listeners;

use App\Events\LicenseSaved; // This event is like calling, "Hey listener, there's work for ya!"
use Illuminate\Contracts\Queue\ShouldBeUniqueUntilProcessing; // This contract is like saying, "Stay put until it's go-time!"
use Illuminate\Contracts\Queue\ShouldQueue; // Because, duh, we're queuing this task up!

class AcquireProductKey implements ShouldQueue, ShouldBeUniqueUntilProcessing
{
    // ...
}

Now you and your listeners can keep the peace (and unique status) until it’s time to rock that dance floor – or in this case, process those events! 💃🕺️

Alrighty, let’s dive into Laravel’s secret squirrel club: the Unique Listener Locks!

Imagine you’re at a chaotic office party where everyone is trying to grab the last slice of pizza. Our friendly Laravel decides to play bouncer and make sure only one person can claim that cheesy glory at a time (because let’s face it, nobody wants a soggy slice).

When a ShouldBeUnique event is thrown, Laravel will try to grab the pizza ticket (lock) with the unique ID. If someone else already has the ticket, our Laravel will politely wait for them to finish their pizza before throwing another slice our way. Once the ticket holder finishes or the pizza becomes inedible (all retry attempts are exhausted), the lock is released and the next hungry listener can try for the prize!

By default, Laravel uses its own party supplies (default cache driver) to hand out tickets. But if you want to bring your own coolers (another driver for acquiring the lock), you can define a uniqueVia method that specifies which cooler to use:

<?php

namespace App\Listeners;

use App\Events\LicenseSaved;
use Illuminate\Contracts\Cache\Repository;
use Illuminate\Support\Facades\Cache;

class AcquireProductKey implements ShouldQueue, ShouldBeUnique
{
    // ...

    /**
     * Get the cache driver for the unique listener lock.
     */
    public function uniqueVia(LicenseSaved $event): Repository
    {
        return Cache::driver('redis'); // Bringing our own cooler! 😎
    }
}

P.S.: If all you need is to control the number of partygoers (concurrent listener processing), use the WithoutOverlapping job middleware instead. It’s like bringing a whistle to manage the crowd! 🎯📣

Dealing with a Miserable Job: A Guide to Handling Failed Laravel Jobs

Ah, the joys of programming! Sometimes your queued event listeners can turn into grumpy, sulking teens. When these little troublemakers fail to deliver, and if they’ve pushed their luck past the maximum number of attempts as set by the wise queue worker, it’s time for the failed method to step in and play referee.

<?php

namespace App\Listeners;

use App\Events\OrderShipped;
use Illuminate\Contracts\Queue\ShouldQueue; // They said they could handle pressure!
use Illuminate\Queue\InteractsWithQueue;    // Because who doesn't want to party with the queue?
use Throwable;                              // Just in case a temper tantrum ensues...

class SendShipmentNotification implements ShouldQueue
{
    use InteractsWithQueue;

    /**
     * Get the job done, young man!
     */
    public function handle(OrderShipped $event): void
    {
        // ... A job well done, I hope!
    }

    /**
     * Time-out for bad behavior.
     */
    public function failed(OrderShipped $event, Throwable $exception): void
    {
        // ... Time to ground this event listener and send it to its room for a thinking-time-out!
    }
}

And if you want to set some boundaries for these rascals, you can specify the maximum attempts for your queued listener:

<?php

namespace App\Providers;

use Illuminate\Foundation\Support\Providers\EventServiceProvider as ServiceProvider;
use Illuminate\Queue\InteractsWithQueue;
use Illuminate\Contracts\Queue\ShouldQueue;

class EventServiceProvider extends ServiceProvider
{
    /**
     * Register any events for your application.
     */
    protected $listen = [
        OrderShipped::class => [
            SendShipmentNotification::class, // Yeah, you!
        ],
    ];

    /**
     * Configure the queue connection and retry attempts for jobs relating to the 'app' queue.
     *
     * Note that by default all jobs will have 3 retries with a 1 minute delay between each attempt.
     */
    public function broker()
    {
        return [
            'default' => [
                'connection' => 'database', // Don't mess this up!
                'table' => 'jobs', // Where the jobs live!
                'retry_after' => 60, // Time to cool off between attempts.
                'max_attempts' => 5, // The limit for how many times a job can fail before being killed.
            ],
        ];
    }
}

Alrighty, let’s dive into the world of Laravel queues, where your listeners are like the life of the party – always ready to dance but not to a point of exhaustion! 💃🕺

Imagine you’ve invited that one friend who can’t stop tripping over their own feet (our humble listener). If they keep falling, you don’t want them to get up and try again indefinitely, right? Well, Laravel has got your back with a variety of ways to set the maximum number of attempts or the duration for our clumsy friend to recover. 🤕

First off, you can utilize the Tries attribute on your listener class to specify how many times our friend can trip before calling it quits:

<?php

namespace App\Listeners;

use App\Events\OrderShipped;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Queue\Attributes\Tries;
use Illuminate\Queue\InteractsWithQueue;

#[Tries(5)] // Our friend gets 5 chances to avoid tripping over.
class SendShipmentNotification implements ShouldQueue
{
    use InteractsWithQueue;

    // ...
}

Now, if you’d rather set a time limit for our friend instead of a specific number of attempts, you can do so by defining a timeout:

use DateTime;

/**
 * Timeout our friend at the party.
 */
public function timeout(): DateTime
{
    return now()->addMinutes(5); // Our friend gets 5 minutes to sober up and dance without tripping.
}

In case both timeout() and tries are defined, Laravel will prioritize the time limit. And remember, our friend is still learning to dance! 🕺💃

Now that you’ve got a handle on setting the maximum attempts for your queued listeners, let’s keep the party going! 🎉

Alrighty then! If you’re hankerin’ for some control over how long Laravel should twiddle its thumbs before giving your listener another whirl after it’s encountered an error, you can make use of the Backoff attribute in your listener class’s wardrobe:

namespace App\Listeners;

use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Queue\Attributes\Backoff;

#[Backoff(3)] // Three seconds, like a quick bathroom break.
class SendShipmentNotification implements ShouldQueue
{
    // ...
}

But if you’re after more sophisticated logic to determine your listener’s time-out length, you can sew the backoff() method into your class:

/**
 * Figure out how many seconds to wait before trying again with the queued listener.
 */
public function backoff(OrderShipped $event): int
{
    return 3; // That's one episode of "Three's Company".
}

Should you need “exponential” backoffs, simply return an array of timeouts from the backoff() method. Here, the delay between retries goes like this: 1 second for the first attempt, 5 seconds for the second, 10 seconds for the third, and 10 seconds for each subsequent try if you’ve got more attempts left:

/**
 * Figure out how many seconds to wait before trying again with the queued listener.
 *
 * @return list<int>
 */
public function backoff(OrderShipped $event): array
{
    return [1, 5, 10]; // Exponential? More like "Fast and Furious"-ial!
}

Now go forth and conquer those listeners with your newfound patience skills, partner!

Alright, Laravel peeps! Let’s get this party started with somequeue shenanigans! 🥳

Giving Your Queue Listener a Chance: The Max Exceptions Trickery

Ever found yourself in a situation where you want your queued listener to give it another go, but not when things get unbearably chaotic with too many unwieldy exceptions? Fret not! We’ve got the answer – or rather, the attributes. 🤓

To make your listener class more resilient, yet still know when to call it quits, you can employ the Tries and MaxExceptions magic spells:

<?php

namespace App\Listeners;

use App\Events\OrderShipped;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Queue\Attributes\MaxExceptions;
use Illuminate\Queue\Attributes\Tries;
use Illuminate\Queue\InteractsWithQueue;

// Our cape-wearing, problem-solver extraordinaire!
#[Tries(25)] // 🎈 "Hold on, there are 25 tries left!"
#[MaxExceptions(3)] // 🚫 "That's a wrap, we've hit our exception limit!"
class SendShipmentNotification implements ShouldQueue
{
    use InteractsWithQueue; // The secret ingredient that makes it all work!

    /**
     * Handle the event.
     */
    public function handle(OrderShipped $event): void
    {
        // Investigate, analyze, and process the event like a pro!
    }
}

This spectacle demonstrates that our listener will attempt solving the mystery up to 25 times. But, if three unhandled exceptions are unleashed by the listener in this quest, it’ll finally throw in the towel and call for backup – or a requeue, as we Laravelites like to say. 🦸‍♂️🎉

Alright, Laravel peeps! Let’s dive into the world of queued listener timeouts. Ever found yourself waiting for your listeners to churn out results, feeling like a cat patiently waiting for a laser pointer to move? Well, Laravel’s got your back!

You see, just as you might estimate how long it takes your cats to reach that darn laser dot, Laravel lets you guess the processing time of your queued listeners. And, in true tech fashion, if one of those listeners gets stuck on a 9-life marathon, Laravel will give it a gentle nudge and make it exit with an error after the number of seconds specified by the timeout value.

How do you set this magical timeout time? Simply slap the Timeout attribute on your listener class like a digital bullseye:

<?php

namespace App\Listeners;

use App\Events\OrderShipped;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Queue\Attributes\Timeout;

#[Timeout(120)] // Now your listener knows not to overstay its welcome by 120 seconds!
class SendShipmentNotification implements ShouldQueue
{
    // ...
}

Feeling a bit more adventurous? You can also mark a listener as failed on timeout. This is like giving it a big red X when it’s stuck in a loop, forcing it to clean up its act and move along:

<?php

namespace App\Listeners;

use App\Events\OrderShipped;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Queue\Attributes\FailOnTimeout;

#[FailOnTimeout] // Say goodbye to time wasters, this listener won't stick around if it hits the timeout limit!
class SendShipmentNotification implements ShouldQueue
{
    // ...
}

Happy coding, folks! Now you can manage your listeners like a boss, ensuring they don’t overstay their welcome or get stuck in an endless loop. Keep those queues flowing smoothly!

Unleashing Events, Like Summoning Pixelated Phoenixes!

Alrighty, buckle up for some coding shenanigans, folks! To summon an event, you can channel the static dispatch magic spell on your event apparatus. This enchantment is bestowed upon your event by the Illuminate\Foundation\Events\Dispatchable charm. Any potions (er, arguments) you toss into the dispatch cauldron will be brewed into the event’s constructor:

<?php

namespace App\Http\Controllers;

use App\Events\OrderShipped;
use App\Models\Order;
use Illuminate\Http\RedirectResponse;
use Illuminate\Http\Request;

class OrderShipmentController extends Controller
{
    /**
     * Send that order off on its postal adventure!
     */
    public function store(Request $request): RedirectResponse
    {
        $order = Order::findOrFail($request->order_id);

        // Order shipment sorcery...

        OrderShipped::dispatch($order); // Zap! It's dispatched!

        return redirect('/orders');
    }
}

Now, if you fancy dispatching events based on conditions, we’ve got a couple of tricks up our sleeve: the dispatchIf and dispatchUnless incantations. Use them wisely, my dear!

// If the condition is true, conjure OrderShipped!
OrderShipped::dispatchIf($condition, $order);

// If the condition isn't met, let OrderShipped bloom!
OrderShipped::dispatchUnless($condition, $order);

[!NOTE] When testing your spells, it can be handy to verify that certain events were summoned without unleashing their listener minions. With Laravel’s built-in testing helpers, casting a spell becomes child’s play.

Now, when you want to dispatch events after database transactions, here’s the deal:

First off, wrap your event summoning within a transaction block using beginTransaction() and commit(). If things go south during the transaction, use rollBack() to make it rain rejection errors. Then, if you want your event to be dispatched after the transaction commits, use the afterCommit event listener method:

use Illuminate\Database\Eloquent\Model;
use Illuminate\Queue\InteractsWithQueue;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Foundation\Events\Dispatchable;
use Illuminate\Database\Eloquent\Event as EloquentEvent;
use Illuminate\Queue\SerializesModels;

class OrderShipped extends Model implements ShouldQueue, EloquentEvent
{
    use Dispatchable, InteractsWithQueue, SerializesModels;

    public function afterCommit()
    {
        // Your event handling logic here!
    }
}

In this example, the OrderShipped model will dispatch itself after a successful transaction. Happy coding, magic-makers!

Unleashing Events post-Database Shenanigans! 🤖

Ever found yourself in a pickle where you wanted Laravel to let loose with an event after the current database transaction has taken a shower and hung up its towel? Well, buckle up, buttercup, because we’re about to take you on a wild ride! 🚀

To make that magic happen, all you need is to sprinkle some stardust (a.k.a implement) the ShouldDispatchAfterCommit interface onto your event class like a boss. This fairy dust tells Laravel to hold its horses until the current database transaction has taken a ride on the commitment carousel. If the transaction trips and falls, the event will be given a rain check and forgotten about as quickly as last week’s meme. But if there ain’t no active database transaction when the event is dispatched, Laravel will throw caution to the wind and dispatch that event faster than you can say “database transaction” three times fast! 💨

<?php

namespace App\Events;

use App\Models\Order;
use Illuminate\Broadcasting\InteractsWithSockets;
use Illuminate\Contracts\Events\ShouldDispatchAfterCommit;
use Illuminate\Foundation\Events\Dispatchable;
use Illuminate\Queue\SerializesModels;

class OrderShipped implements ShouldDispatchAfterCommit
{
    use Dispatchable, InteractsWithSockets, SerializesModels;

    /**
     * Constructor for the event, carrying the spirit of a wild night out!
     */
    public function __construct(
        public Order $order,
    ) {}
}

And there you have it! By implementing ShouldDispatchAfterCommit, you’ve transformed your events into those cool kids at the party who only start to dance after everyone else has settled in and the DJ has started spinning tunes. 🕺️✨

Alright, let’s dive into the world of Laravel event deferral - it’s like setting up a sneaky ambush for your model events! 🕵️‍♂️

Deferred events are your secret weapon when you want to make sure all related records are accounted for before triggering those nosy event listeners. Think of it as a get-together where everyone shows up only after the hors d’oeuvres are gone, leaving no crumbs behind. 🥄🍽️

To pull off this covert operation, you simply need to hand over a secret mission (closure) to the Event::defer() method:

use App\Models\User;
use Illuminate\Support\Facades\Event;

Event::defer(function () {
    $user = User::create(['name' => 'Victoria Otwell']);

    // Party time! Create a new post for the host. 🥳
    $user->posts()->create(['title' => 'My first post!']);
});

Any events that take place within the secret mission (closure) will not be dispatched until after the mission is accomplished. This ensures that event listeners can party with all the related records created during the deferred execution, no invitations lost in the mail! 📩

However, if anything goes awry within the secret mission and an exception occurs, the whole operation will be called off, and deferred events will not be dispatched. 🚨

For even more precision, you can defer only specific events by passing an array of events as the second argument to the defer method:

use App\Models\User;
use Illuminate\Support\Facades\Event;

Event::defer(function () {
    $user = User::create(['name' => 'Victoria Otwell']);

    // Party time! Create a new post for the host. 🥳
    $user->posts()->create(['title' => 'My first post!']);
}, ['eloquent.created: '.User::class]);

This way, only the eloquent.created event related to the User model will be deferred – leaving all other events free to do their thing right away! 🎊💥

Alright, buckle up, coding cowboy! It’s time we talk about Event Subscribers in Laravel – your new best friend for handling all those hootenannies that break out unexpectedly in your app.

First off, let me set the scene: you’re hosting a digital barn dance, and everything’s going great… until Cletus accidentally kicks over the punch bowl, causing chaos! In Laravel world, this is an “event,” a sudden change of state in your application that needs a quick response.

That’s where Event Subscribers swoop in on their white horses. They listen for the faint sound of broken punch bowls (or events) and know just what to do when they hear it. With event subscribers, you can clean up Cletus’ mess or maybe even prevent him from kicking over the bowl in the first place!

Here’s how it works: Instead of writing separate functions to handle each event, you create a class that extends Laravel’s EventSubscriber and marks your methods with the listen() annotation. This magical incantation tells Laravel which events your subscriber should listen for. For example:

namespace App\Listeners;

use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Queue\InteractsWithQueue;
use Illuminate\Foundation\Events\Dispatchable;
use App\Events\PunchBowlKicked;

class PunchBowlListener implements ShouldQueue
{
    use Dispatchable, InteractsWithQueue, Queueable;

    public function handle(PunchBowlKicked $event)
    {
        // Handle the punch bowl being kicked event
        dd('Oh no! The punch bowl has been kicked! Someone call security!');
    }
}

In this example, we’ve created a class PunchBowlListener that listens for the App\Events\PunchBowlKicked event. When this event occurs, our handle() function springs into action to deal with the crisis at hand.

Now, you might be wondering, “But how do I make sure my cowboy hats and boots are in the right saloon?” Well, registering an Event Subscriber is as easy as adding it to your app’s service provider. Here’s what that looks like:

namespace App\Providers;

use Illuminate\Support\Facades\Event;
use App\Listeners\PunchBowlListener;

class EventServiceProvider extends ServiceProvider
{
    protected $listen = [
        PunchBowlKicked::class => [
            PunchBowlListener::class,
        ],
    ];
}

And there you have it! You’re now armed and ready to handle any punch bowl disasters (or events) that come your way. Happy coding! 🤠

Unleashing the Power of Event Sherpas!

Event Sherpas, much like seasoned mountaineers, traverse treacherous terrain (your application) to catch crucial events happening along the way. Unlike regular citizens who can only subscribe to one event at a time, these superheroes can hook themselves up to multiple events within their very own sherpa camp!

To become an event Sherpa, your class needs to define a subscribe method, which will receive a trusty event dispatcher instance. After receiving this badge of honor, you may summon the dispatcher’s might by calling its listen method to register event listeners:

<?php

namespace App\MountainGuides; // Because we're going on an adventure!

use Illuminate\Auth\Events\LoginEvent as UserLoggedIn;
use Illuminate\Auth\Events\LogoutEvent as UserLoggedOut;
use Illuminate\Events\Dispatcher;

class UserEventHandler
{
    /**
     * Handle user login events.
     */
    public function greetUser(UserLoggedIn $event): void {
        echo "Welcome back, ${$event->user->name}! Enjoy the journey.";
    }

    /**
     * Handle user logout events.
     */
    public function farewellUser(UserLoggedOut $event): void {
        echo "Goodbye, ${$event->user->name}. We hope to see you again soon!";
    }

    /**
     * Register the listeners for the Sherpa.
     */
    public function registerCamp(Dispatcher $dispatcher): void
    {
        $dispatcher->listen(
            UserLoggedIn::class,
            [$this, 'greetUser']
        );

        $dispatcher->listen(
            UserLoggedOut::class,
            [$this, 'farewellUser']
        );
    }
}

If you prefer to define your event listeners directly within the Sherpa camp, you might find it more comfortable to return an array of events and method names from the Sherpa’s registerCamp method. Laravel will magically figure out the Sherpa’s name when registering the event listeners:

<?php

namespace App\MountainGuides; // Still on an adventure!

use Illuminate\Auth\Events\LoginEvent as UserLoggedIn;
use Illuminate\Auth\Events\LogoutEvent as UserLoggedOut;
use Illuminate\Events\Dispatcher;

class UserEventHandler
{
    /**
     * Handle user login events.
     */
    public function greetUser(UserLoggedIn $event): void {
        echo "Welcome back, ${$event->user->name}! Enjoy the journey.";
    }

    /**
     * Handle user logout events.
     */
    public function farewellUser(UserLoggedOut $event): void {
        echo "Goodbye, ${$event->user->name}. We hope to see you again soon!";
    }

    /**
     * Register the listeners for the Sherpa.
     *
     * @return array<string, string>
     */
    public function registerCamp(Dispatcher $dispatcher): array
    {
        return [
            UserLoggedIn::class => 'greetUser',
            UserLoggedOut::class => 'farewellUser',
        ];
    }
}

Now, let’s get those event Sherpas on the trail!

Unleashing the Superheroes of Your App! (AKA Registering Event Subscribers)

Listen up, caped crusaders! In this thrilling tale of Laravel’s event management system, you’ve written your very own superhero sidekick - aka an event subscriber. But before we send it out to patrol the event horizon, let’s make sure it gets recognized by our trusty AI butler, Jarvis (aka Laravel).

Now, there are two ways to get this hero into the game:

1. The Automatic Route: If your sidekick follows our conventions like a well-trained Batman sidekick should, Laravel will automatically register its superpowers (handler methods) within the subscriber. Think of it as Batman’s utility belt, magically filled with Batarangs and other gadgets.

2. The Manual Approach: But what if your sidekick is a bit rebellious and doesn’t follow the conventions? Fear not! You can still manually register your subscriber using the subscribe method of the Event facade (our Jarvis AI). This should be done in the boot method of your application’s AppServiceProvider - think of it as the Batcave’s command center.

Here’s how to do it:

<?php

namespace App\Providers;

use App\Listeners\UserEventSubscriber; // Our newly trained sidekick
use Illuminate\Support\Facades\Event; // Jarvis, our AI butler
use Illuminate\Support\ServiceProvider; // The Batcomputer

class AppServiceProvider extends ServiceProvider
{
    /**
     * Bootstrap any application services.
     */
    public function boot(): void
    {
        Event::subscribe(UserEventSubscriber::class); // We're adding our new sidekick to the roster
    }
}

And just like that, your superhero sidekick is now a part of the team, ready to swoop in and save the day whenever an event occurs! But remember, with great power comes great responsibility. Make sure to test your sidekick thoroughly before sending it out into the field! (Check out our testing section for more details.)

Now, who’s ready to build some more crime-fighting machines? The city needs us, caped crusaders!

Alright, buckle up, coding cowboys and cowgirls! Let’s dive into the wild west of Laravel event testing where you can herd those rowdy listeners like a pro!

Sometimes when you’re writing code that fires up events, you might want to lasso Laravel and tell it not to actually saddle up the event listeners. Why? Because their code is as tough as rawhide and deserves a test all on its own, separate from the event-dispatching cowpoke. No worries! You can catch a listener instance by the horns and rope in its handle method directly in your test.

Hold onto your Stetsons, for with the Event facade’s trusty fake method, you can corral those runaway listeners, let loose the event wrangling code, and then round ‘em up using the assertDispatched, assertNotDispatched, and assertNothingDispatched methods!

<?php

use App\Events\GunslingerDrew;
use App\Events\PosseFormed;
use Illuminate\Support\Facades\Event;

test('posses can be formed', function () {
    Event::fake();

    // Saddle up and form a posse...

    // Assert that a posse was formed...
    Event::assertDispatched(PosseFormed::class);

    // Assert the posse was formed twice...
    Event::assertDispatched(PosseFormed::class, 2);

    // Assert the posse was formed once...
    Event::assertDispatchedOnce(PosseFormed::class);

    // Assert no gunslingers were drawn...
    Event::assertNotDispatched(GunslingerDrew::class);

    // Assert nobody's drawin' their six-shooters...
    Event::assertNothingDispatched();
});

<?php

namespace Tests\Feature;

use App\Events\GunslingerDrew;
use App\Events\PosseFormed;
use Illuminate\Support\Facades\Event;
use Tests\TestCase;

class SaloonTest extends TestCase
{
    /**
     * Test posse formation.
     */
    public function test_poses_can_be_formed(): void
    {
        Event::fake();

        // Saddle up and form a posse...

        // Assert that a posse was formed...
        Event::assertDispatched(PosseFormed::class);

        // Assert the posse was formed twice...
        Event::assertDispatched(PosseFormed::class, 2);

        // Assert the posse was formed once...
        Event::assertDispatchedOnce(PosseFormed::class);

        // Assert no gunslingers were drawn...
        Event::assertNotDispatched(GunslingerDrew::class);

        // Assert nobody's drawin' their six-shooters...
        Event::assertNothingDispatched();
    }
}

Feeling lucky, partner? You can pass a closure to the assertDispatched or assertNotDispatched methods to ensure an event is dispatched that passes a given “truth test”. If at least one event matches the criteria, you’ve got yourself a winner!

Event::assertDispatched(function (PosseFormed $event) use ($posse) {
    return $event->leader === $posse->getLeader();
});

If you just need to verify that an event listener is keeping its ears pinned back for a specific event, then ride on over to the assertListening method!

Event::assertListening(
    PosseFormed::class,
    Marshal::class
);

[!WARNING] After calling Event::fake(), no event listeners will be lasso’d. So, if your tests hitch up their horses with model factories that rely on events, like creating a UUID during a model’s creating event, you should call Event::fake() after using your factories!

But wait, there’s more! You can even selectively corral events with the assertDispatched, assertNotDispatched, and assertNothingDispatched methods. How you ask? By using an array to specify a list of event classes:

<?php

use App\Events\PosseFormed;
use App\Events\GunslingerDrew;
use Illuminate\Support\Facades\Event;

test('posses can be formed without gunslingers being drawn', function () {
    Event::fake([PosseFormed::class]);

    // Saddle up and form a posse...

    // Assert that a posse was formed...
    Event::assertDispatched(PosseFormed::class);

    // Assert no gunslingers were drawn...
    Event::assertNotDispatched(GunslingerDrew::class);
});

Alrighty then! Let’s dive into Laravel’s event faking feature, shall we? This is the superhero cape for your tests, allowing you to control which events are dispatched and when. 😊

First off, if you want to trick out a selective group of event listeners, you can do so by passing them to either the fake or fakeFor method:

test('Orders can be processed like Neo dodging bullets', function () {
    Event::fake([
        OrderCreated::class, // This is our bullet!
    ]);

    $order = Order::factory()->create(); // Bam! An order just appeared.

    Event::assertDispatched(OrderCreated::class); // Checking if the bullet was fired.

    // Other events are dispatched as normal...
    $order->update([
        // ...
    ]);
});

/**
 * Test order process.
 */
public function test_orders_can_be_processed(): void
{
    Event::fake([
        OrderCreated::class, // It's the hammer we're pretending not to drop!
    ]);

    $order = Order::factory()->create(); // Curly just made an order!

    Event::assertDispatched(OrderCreated::class); // Checking if the hammer was dropped.

    // Other events are dispatched as normal...
    $order->update([
        // ...
    ]);
}

Now, you can fake all events except for a specific subset using the except method:

Event::fake()->except([
    OrderCreated::class, // This event is now the invisible man!
]);

And voila! Now you have the power to bend events to your will, making testing a whole lot more entertaining. 🎉🎈🌠

Alrighty, let’s dive into the world of Laravel test events with a dash of humor!

Fake Event Spectacles (Just for fun!)

If you only want to pull some magical event listener shenanigans for a specific segment of your test, you can summon the fakeFor method like a sorcerer casting a spell!

<?php

Use the Force, young Padawan! We're dispatching OrderCreated events here.

use App\Events\OrderCreated;
use App\Models\Order;
use Illuminate\Support\Facades\Event;

test('orders can be processed', function () {
    $order = Event::fakeFor(function () {
        // The Force awakens an order!
        $order = Order::factory()->create();

        // We cast a spell to check if the OrderCreated event has been dispatched.
        Event::assertDispatched(OrderCreated::class);

        return $order;
    });

    // Events are dispatched as normal, and we hope that our loyal Obi-Wans are listening...
    $order->update([
        // The Force is strong with this one! Make updates happen.
    ]);
});

<?php

We've summoned the Power of Potter for this test.

namespace Tests\Feature;

use App\Events\OrderCreated;
use App\Models\Order;
use Illuminate\Support\Facades\Event;
use Tests\TestCase;

class ExampleTest extends TestCase
{
    /**
     * Test order process.
     */
    public function test_orders_can_be_processed(): void
    {
        $order = Event::fakeFor(function () {
            // The wand chooses the wizard! Create an order, please.
            $order = Order::factory()->create();

            // We cast a spell to check if the OrderCreated event has been dispatched.
            Event::assertDispatched(OrderCreated::class);

            return $order;
        });

        // Events are dispatched as normal, and we hope that our faithful house elves are listening...
        $order->update([
            // A brew of updates for the order.
        ]);
    }
}

Enjoy your Laravel test event sorcery! May the Force (or Power of Potter) be with you! 😉