Hooking into Symfony with an Event Subscriber

Hey Mepcuk

So what's the issue? is anything work bad or unexpected?

PS BTW to fix it will be enough to add : array to the App\EventListener\UserAgentSubscriber::getSubscribedEvents()

Cheers!

Yo Kevin B. !

Ah, that laziness is a really good point to bring up! Ok, so let's look at this:

A) You're correct that event subscribers (and listeners) are lazy in the "prod" environment, meaning that your listener/subscriber service won't be instantiated unless the event is actually dispatched. I haven't tested this, but if I'm wrong, it would be a big ol' bug in Symfony :).

B) What about the dev environment? I had assumed it worked the same... though that was just a guess. I just did a quick and dirty test on my side and it seems like my event subscriber IS indeed still lazy in the dev mode (tested by putting a die() in the constructor of an event subscriber for a security-related event and then refreshed the page). You're seeing something different? It doesn't really matter, of course, but I'm curious.

So... you're correct that you "shouldn't" need to convert your event subscriber/listener into a "service subscriber" (to help others, the term "service subscriber" here has nothing to do with an event subscriber - we're talking about this concept https://symfonycasts.com/sc... ). That's because, as you already know, your listener/subscriber service isn't instantiated unless it's necessary.

However, if you have an event subscriber/listener that is called very often (most importantly the "kernel" events)... but that only does its real work SOME of the time, then you might still want a subscriber so that your subscriber/listener can be instantiated, executed, but then "exit early" ("no work to do on this request!") before instantiating any services. So, your conversion to service subscribers might still have been a good idea :).

Cheers!

Thanks for the confirmation!

What about the dev environment?

I did the same dd in constructor thing but I should note that the testing I did was in 4.4 so maybe some things have changed. Regardless, in prod, they are lazy.

So, your conversion to service subscribers might still have been a good idea

Indeed, the request subscribers I converted were definitely a good call. It's the non-standard event subscribers (3rd party) where I made the unnecessary conversion.

Hey Mepcuk!

Try running composer require symfony/monolog-bundle - that's my guess.

By default, Symfony ships with a barebones logger service. One thing it does (which is kind of annoying) is that it dumps out to the terminal. But when you install Monolog, the default logger is replaced with the real one. I don't remember for sure, but my guess is that you only see the logs in the profiler once you have the "real" logger installed.

Cheers!

Hey Peter!

Hmm. So this is a different event system than the one we talk about here, but both work using the same fundamental principle of dependency injection tags. So, I don't see anything obviously wrong with your code: you've attached the tag correctly. So, it's time to debug! There are 2 things I can think of:

1) Run php bin/console debug:container App\EventListener\CreatedUpdatedListener and verify that the "tags" are listed on it. Alternatively, you can run php bin/console debug:container --tags to see which services have the doctrine.event_listener tag.

2) Internally, the class (compiler pass) that handles finding the services with the tag is here: https://github.com/symfony/symfony/blob/c71c8727cc665c9e9b56e299fcfcc0adfbf02bac/src/Symfony/Bridge/Doctrine/DependencyInjection/CompilerPass/RegisterEventListenersAndSubscribersPass.php#L75 - I would debug that $taggedServices variable to verify your service is there).

Let me know if this helps!

Cheers!

nevermind. I had to enable them in php.ini. Was using 7.4, switched to 7.3, but not sure if that had to do with it.
If I went back to the first video conversation I would've seen someone solved this already.

No worries Will T. sorry you hit the issue! Most operating systems come with some standard PHP extensions like this... so I sometimes forget that a few OS's / ways to install PHP do *not* and cause problems.

Good luck after this! Cheers!

I recently moved from Mac to Windows after being a long time Mac user. Macbook was 10 years old and in dire need of an upgrade. I can get so much more value for a loaded PC.
Finding it can be some what more challenging to get set up running, though, AMP on OSX is not without it's own frustrations.

I think even though it's irritating, it becomes more like working on a job; it gives me valuable troubleshooting skills that give me more experience.

Hey Will T.!

Switching between *anything* will definitely involve a few bumps on the road - probably you're already through the worst - and I love that attitude! Plus, with the Unix subsystem, Windows has come a long way to being a good dev environment :).

Cheers!

Hey Gaetano,

It would be good to know for sure if you hit the sendMail() or no. I see you have dd() commented out, did you run the website with it uncommented? Didn't you hit that "dd()" line? Also, I don't see what namespaces you're using... could you show what namespace are used in your UserMailSubscriber? Probably you extend a wrong namespace so you listener was never called, though I see it in the output... so probably that extra check in sendMail() does not work for you? I'm talking about "if (!$user instanceof User || Request::METHOD_POST !== $method) {", could you double-check its logic? It would be good to debug why you hit that return statement. Are you sure User's namespace is correct? Do you really have POST request?

Btw, why do you want to send the email via listener? How users registered in your application? Do you FOSUserBundle?

Cheers!

Hi,

thanks for your help. I explain you the project. There is a front-end (Angular) and a back-end (ApiPlatform). When I hit the route ../api/v1/users/create, a user is registered in the database and after registration, my Mailsubscriber send an email. Finally I changed strategy and it works.
This my Subscriber:

namespace App\EventSubscriber;

use App\Event\UserCreatedEvent;
use Swift_Mailer;
use Swift_Message;
use Symfony\Component\EventDispatcher\EventSubscriberInterface;
use SymfonyCasts\Bundle\VerifyEmail\VerifyEmailHelperInterface;
use Twig\Environment;
use Twig\Error\LoaderError;
use Twig\Error\RuntimeError;
use Twig\Error\SyntaxError;

final class UserMailSubscriber implements EventSubscriberInterface
{
    /**
     * @var VerifyEmailHelperInterface
     */
    protected $verifyEmailHelper;

    /**
     * @var Swift_Mailer
     */
    protected $mailer;

    /**
     * @var Environment
     */
    protected $templating;

    /**
     * UserMailSubscriber constructor.
     * @param VerifyEmailHelperInterface $verifyEmailHelper
     * @param Swift_Mailer $mailer
* @param Environment $templating
     */

    public function __construct(VerifyEmailHelperInterface $verifyEmailHelper, Swift_Mailer $mailer, Environment $templating)
    {
        $this->verifyEmailHelper = $verifyEmailHelper;
        $this->mailer = $mailer;
        $this->templating = $templating;
    }

    /**
     * @inheritDoc
     */
    public static function getSubscribedEvents(): array
    {
        return [
            UserCreatedEvent::NAME => 'onUserCreated'
        ];
    }

    /**
     * @param UserCreatedEvent $event
     * @throws LoaderError
     * @throws RuntimeError
     * @throws SyntaxError
     */
    public function onUserCreated(UserCreatedEvent $event): void
    {
        $user = $event->getUser();
        $message = (new Swift_Message())
            ->setFrom('tmessagerie@norsys.fr', 'Topolino Test')
            ->setTo($user->getEmail())
            ->setSubject('Welcome to Paradise')
            ->setBody(
                $this->templating->render(
                    'creationUser/confirmation_email.html.twig',
                    [
                        'username' => $user->getUsername()
                    ]
                ),
                'text/html'
            );

        $this->mailer->send($message);
    }
}

It calls my event:

namespace App\Event;

use App\Entity\User;
use Symfony\Contracts\EventDispatcher\Event;

class UserCreatedEvent extends Event
{
    public const NAME = 'user.created';

    /**
     * @var User
     */
    protected $user;

    /**
     * UserCreatedEvent constructor.
     * @param User $user
     */

    public function __construct(User $user)
    {
        $this->user = $user;
    }

    /**
     * @return User
     */
    public function getUser(): User
    {
        return $this->user;
    }
}

Then in my userManager (you see only a part of code) I use the dispatcher:

/**
 * @param User $user
 * @return array
 */
public function registerAccount(User $user): array
{
    if ($this->findEmail($user->getEmail())){
        throw new BadRequestHttpException('Email already exists');
    }

    $user->setUsername($user->getEmail());
    $password = $this->passwordServices->encode($user, $user->getPassword());
    $user->setPassword($password);
    $user->setReference($this->referenceFormat());
    $this->entityManager->persist($user);
    $this->entityManager->flush();
    $event = new UserCreatedEvent($user);
    $this->dispatcher->dispatch($event, UserCreatedEvent::NAME);

    return [
        "message"   => "User creation performed",
        "user"      => $user
    ];
}

The registeraccount method is called by the __invoke($data) inside the createUser class (this is the controller called in the collectionOperations by ApiResource).
I hope this explanation is good to better understand.
Thanks again for your help.

Hey Paul Rijke

That's a good question. The thing here is that Doctrine comes with its own event-dispatching system, in other words Symfony events and Doctrine events are two different systems. Symfony has the "auto configure" feature, so you only need to implement the "EventSubscriber" interface and forget configuration but because of what I said Doctrine cannot benefit of that feature and you have to add the required configuration.

Cheers!