No longer possible to programatically subscribe to events

[adamjgriffith]

Laravel Version

11.x / 12.x

PHP Version

8.3.27

Database Driver & Version

Postgres

Description

In Laravel 10 and below it was possible to programatically subscribe to events like so:

<?php

namespace App\Listeners;

use App\Events\UserCreated;
use App\Events\UserUpdated;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Support\Facades\Log;

class Subscriber implements ShouldQueue
{
    /**
     * Handle the event.
     *
     * @return void
     */
    public function handleUserCreated(UserCreated $event)
    {
        Log::info('Hello, world!');
    }

    /**
     * Handle the event.
     *
     * @return void
     */
    public function handleUserUpdated(UserUpdated $event)
    {
        Log::info('Hello, world!');
    }

    /**
     * Register the listeners for the subscriber.
     *
     * @param  \Illuminate\Events\Dispatcher  $events
     * @return void
     */
    public function subscribe($events)
    {
        if (config('app.env') === 'production') {
            $events->listen(
                'App\Events\UserCreated',
                [Subscriber::class, 'handleUserCreated']
            );

            $events->listen(
                'App\Events\UserUpdated',
                [Subscriber::class, 'handleUserUpdated']
            );
        }
    }
}

In Laravel 11 and 12 the listeners are fired regardless of the config('app.env') === 'production' check.

Steps To Reproduce

Copy example code from: https://laravel.com/docs/12.x/events#writing-event-subscribers.

Wrap the $events->listen calls in the subscribe method in any check even the if (false) {}.

Observe listeners are still fired.

[mbabker]

The root problem is that the class which handles discovering event listeners doesn't handle subscribers with the interface-less subscribe() convention; it's just going to automatically register everything it finds matching the naming patterns (methods starting with "handle" or an __invoke() method). Whether this is the intended behavior of the framework or is actually a bug is to be determined.

You have two options to work around this issue:

1. Disable event discovery and manually register all event listeners/subscribers
2. Move subscribers somewhere other than app/Listeners since that's the path it scans by default

Either way, the documentation could use some improvement in this area; as is, the subscriber example is pretty much invalidated by event discovery.

[adamjgriffith]

Hi @mbabker, thanks for your response.

Could you please point me to the documentation that covers disabling event discovery as I am unable to find it for Laravel 11.x / 12.x?

It does seem this particular documentation is no longer valid since the Laravel 11.x / 12.x changes, as the methods begin with handle... therefore the subscribe function as per the documentation is completely useless?

[mbabker]

Could you please point me to the documentation that covers disabling event discovery as I am unable to find it for Laravel 11.x / 12.x?

It's not documented from what I could find, but it looks like you should be able to call withEvents(discover: false) in the bootstrap/app.php file.

It does seem this particular documentation is no longer valid since the Laravel 11.x / 12.x changes, as the methods begin with handle... therefore the subscribe function as per the documentation is completely useless?

Exactly as documented, it isn't helpful. If the method names on the subscriber class were changed to use a prefix other than handle (i.e. onUserLogin instead of handleUserLogin is a good one), then it'd be fine.