This course is a surprise for me on how much am I getting out of it! Thanks.

The "Disappearing Jobs" Explanation If you are using the latest Laravel 11+ skeleton, your composer run dev command uses concurrently to run a queue worker in the background automatically.

Why you don't see anything in the jobs table:

Because the worker is already running, it picks up the job, processes it (sends the email), and deletes the row from the table in milliseconds. The system is working perfectly, it's just too fast for you to see!

How to verify it's hitting the database:

• Open composer.json.

• Find the "dev" script.

• Temporarily remove the "php artisan queue:listen ..." part.

• Restart composer run dev.

Now, when you dispatch a job, it will stay in the jobs table until you manually run php artisan queue:work in a separate terminal.

Heres a bit more information for those who want to know a little more like how to queue up jobs every hour. (I think this wasn't included for simplicity)

To queue up jobs to run hourly open routes/console.php and add the below:

use App\Jobs\UpdateIdeaStatistics; use Illuminate\Support\Facades\Schedule;

// Hourly means at 10:00, 11:00 etc etc not when it was started. Schedule::job(new UpdateIdeaStatistics)->hourly();

// You could also run for every minute etc etc, which I advise for testing and making sure you've setup everything correctly. Schedule::job(new UpdateIdeaStatistics)->everyMinute();

As with everything for queues this won't just magically work, though it is super simple.

In order for it to work, we need to deply a scheduer which is responsible for co-ordinating/scheduling the repeat jobs.

Open a new cli and type php artisan schedule:work this will setup your scheduler.

Make sure to deploy a worker too in another cli by running php artisan queue:work.

Check your log file after an hour, or a minute depending on which one you choose from the above options and you should see the log in there from the logger().

You will also see the below in your scheduler CLI (the one you ran php artisan schedule:work in):

INFO Running scheduled tasks.
INFO No scheduled commands are ready to run.
2026-02-01 19:36:00 Running [App\Jobs\UpdateIdeaStatistics] ... 18.08ms DONE 2026-02-01 19:37:00 Running [App\Jobs\UpdateIdeaStatistics] ... 15.33ms DONE INFO No scheduled commands are ready to run.

Super cool and super simple :)

Great explanation & examples 🙌

@akaydin I think if you plan having undetermined amount of admins and don't want to make anything complex, you can replicate what Jeffrey suggest: A field named role and define different roles such as user, advanced user, operator, admin, superadmin, etc. According to your needs.

if you require anything more sophisticated you can create a permissions table, role table and pivot table. Then you can associate that role to a user. Each permission can correspond to a Gate. And inside the gate you have to check if you have that particular permission.

Indeed a very complex lecture, in my opinion due to the nature that most stuff is specific to "alpine.js". Apart from that it would really help a lot to use an IDE/editor where the filename is permanently visible.

Absolutely loved it 🔥

Thank you.

@lara_dev_1970 Solution: Add:

                       
                        ->decimalPlaces(0)

        Slider::make('priority')
                        ->required()
                        ->minValue(1)
                        ->maxValue(10)
                        ->pips(Slider\Enums\PipsMode::Steps)
                        ->decimalPlaces(0)
                        ->step(1)
                        ->fillTrack()
                        ->tooltips()
                        ->default(0),

🔥

🔥

🔥

In Filament 5.4.4, what I've installed following this tutorial, do not add Model::unguard on the register() method, do it in boot(). boot() runs after all providers are registered, so models are fully loaded and unguard() applies correctly. register() is too early in the lifecycle for this.

🔥 Lets blaze 🔥

@radmax @andrewdv8 @halvarado77

Solution for Browser Test Issues with File Upload Forms

I experienced the same issue and found a solution based on a comment from the next video. The problem occurs when using enctype="multipart/form-data" on forms with Playwright browser tests.

The Fix

The solution is to dynamically set the enctype attribute using Alpine.js, only when a file is actually selected.

Step 1: Update the form's x-data

In resources/views/idea/index.blade.php, add a new hasImage property to track when a file is selected:

<form
    x-data="{
        status : 'pending',
        newLink: '',
        links: [],
        newStep: '',
        steps: [],
        hasImage: false
    }"
    action="{{ route('idea.store') }}"
    method="POST"
    class="space-y-4"
    x-bind:enctype="hasImage ? 'multipart/form-data' : false"
>

Step 2: Replace static enctype with dynamic binding

Replace the static enctype="multipart/form-data" attribute with:

x-bind:enctype="hasImage ? 'multipart/form-data' : false"

Step 3: Update the file input

Add an @change event to the file input to toggle hasImage when a file is selected:

<input 
    type="file" 
    name="image" 
    accept="image/*" 
    @change="hasImage = $event.target.files.length > 0" 
/>

Why This Works

This approach prevents the form from using multipart/form-data encoding when no image is uploaded, which resolves conflicts with Playwright browser tests. The enctype is only set when an actual file is selected by the user.

Benefits

• ✅ Browser tests pass successfully without modifications to Composer packages
• ✅ File uploads still work correctly for end users
• ✅ No impact on form functionality
• ✅ Clean, maintainable solution using Alpine.js

Test Results

After implementing these changes:

PASS  Tests\Browser\CreateIdeaTest
✓ it creates a new idea (1.95s)

Tests:    1 passed (9 assertions)
Duration: 2.42s

---

Hope this helps!

Just an observation regarding the content of this lesson: since the instructor is using MS Windows, commands like:

php artisan make:controller Api\V1\TicketController --resource --model=Ticket --requests

will work fine and yield the intended result.

However, anyone using macOS or Linux will find out that this will NOT create a TicketController inside the Api -> v1 directory, but will instead create a ApiV1TicketController in the default Controllers directory.

This is because of the use of the backslash character: that works for Windows, but not in the other cases.

The correct syntax for macOS and Linux would use forward slashes, such as:

php artisan make:controller Api/V1/TicketController --resource --model=Ticket --requests

Not a big deal, but this is something that could bring confusion to beginners, so I thought I should mention it. Great course, thou!

@mhmdahmd2422 Not trivial at all if it saves time.

This may be trivial but --api flag when creating controller using artisan command will ditch the create and edit methods in the created controller instead of manually erasing them.

One can make the argument that it truly doesn't matter how complicated the code is, since the AI will fix whatever may be wrong with it. Personally, I'm a control freak like you and I want to know everything that's happening in "my" code. But philosophically speaking, this need for control is a relic of the pre-AI age. Beautiful, elegant, efficient code will all eventually be sacrificed at the altar of the AI's effectiveness and efficiency, which is a pity, because these are the strengths of Laravel

Please, turn this repo public or at least, acessible by us!

@kumarayush Paste the test itself (code you wrote) not only error msg

@nosthas

<?php

declare(strict_types=1);

use Rector\Config\RectorConfig;
use Rector\TypeDeclaration\Rector\ArrowFunction\AddArrowFunctionReturnTypeRector;
use Rector\TypeDeclaration\Rector\ClassMethod\ReturnTypeFromStrictTypedCallRector;
use Rector\TypeDeclaration\Rector\ClassMethod\ReturnUnionTypeRector;
use Rector\TypeDeclaration\Rector\Closure\AddClosureVoidReturnTypeWhereNoReturnRector;
use Rector\TypeDeclaration\Rector\StmtsAwareInterface\DeclareStrictTypesRector;
use RectorLaravel\Set\LaravelSetProvider;

return RectorConfig::configure()
    ->withPaths([
        __DIR__.'/app',
        __DIR__.'/bootstrap',
        __DIR__.'/config',
        __DIR__.'/public',
        __DIR__.'/resources',
        __DIR__.'/routes',
        __DIR__.'/tests',
    ])
    ->withSkip([
        __DIR__.'/bootstrap/cache',
        __DIR__.'/storage',
        __DIR__.'/vendor',
        AddClosureVoidReturnTypeWhereNoReturnRector::class,
        ReturnTypeFromStrictTypedCallRector::class,
        ReturnUnionTypeRector::class,
        DeclareStrictTypesRector::class => [
            __DIR__.'/resources/views',
        ],
        AddArrowFunctionReturnTypeRector::class,
    ])
    ->withPhpSets()
    ->withSetProviders(LaravelSetProvider::class)
    ->withImportNames()
    ->withComposerBased(laravel: true)
    ->withPreparedSets(
        deadCode: true,
        codeQuality: true,
        typeDeclarations: true,
        privatization: true,
        earlyReturn: true,
    )
    ->withRules([
        DeclareStrictTypesRector::class,
    ]);

thanks for the trick about pushing a button and fire a different form. I didn't remeber that. :-)

@jeffreyway in every video, there's a moment cracks me up. This time, the super explanation for the 419 page expired.. typing fast enough ahahah.

🚀 woooo_hoooo !

and what a fancy new comment window 🤖

I didn't understand the homework, can clarify more?

🔥

@nrthbound I continue to get confused on these two but the way I like to think about it is:

You use an Interface when you want to define a purely behavioral contract without any shared code or state.

You use an Abstract Class when you have shared code or state that need to be inherited by child classes, or when you want to provide a base implementation alongside method definitions.

To expand a little bit more:

When to Use an Interface:

Contract Definition: Use interfaces when you want to define a contract that multiple classes can implement. An interface specifies what methods a class must have, without any implementation.

Dynamic Behavior: When designing a system where components might need to be swapped out at runtime, interfaces provide a flexible way to ensure that those components adhere to a specific API.

No State: If you don't need to hold state (properties), and you're purely defining methods, interfaces should be preferred.

When to Use an Abstract Class:

Common Functionality: If you need to provide some default behavior or shared functionality among several classes, an abstract class allows you to implement methods that can be reused.

State Management: When you need to maintain state (properties), abstract classes can hold member variables and provide constructors to initialize them.

Base Class for Other Classes: If you’re creating a base class that may need to be extended by subclasses with additional features or functionality, use an abstract class to provide that base implementation.

Enhanced Control: Abstract classes allow you to define both abstract methods (which must be implemented by child classes) and concrete methods (with implementation), giving you more control over the inherited methods.

Hopefully that makes sense

This is the first time I figured out this abstract logic. The key point here is that the parent class is never used by itself, thus it's abstract. But it inherits to the children classes.

I will rewatch. Thanks Jeffrey!