Document Mautic 8.0 class-name dispatch for Email bundle events by promptless-for-oss · Pull Request #660 · mautic/developer-documentation-new

promptless-for-oss · 2026-09-02T09:22:28Z

Mautic 8.0 dispatches the Email bundle's builder, send, display, and toggle-publish events by class name (Symfony 4.3 style), so Plugin subscribers must key getSubscribedEvents() on the event class instead of an EmailEvents string constant. This updates the Email plugin-extension guide (docs/plugin_extensions/emails.rst) so its token-registration, token-rendering, A/B-testing, and Toggle-'Active' examples key on EmailOnBuildEvent::class, EmailSendEvent::class, EmailDisplayEvent::class, and EmailOnTogglePublishEvent::class. It renames the removed EmailBuilderEvent class to EmailOnBuildEvent, clarifies that the send and display paths are now separate classes that must each be keyed, and adds two notes explaining the backward-compatibility break: referencing a removed constant throws a PHP fatal error, while a subscriber still keyed on the surviving EMAIL_ON_SEND constant silently stops firing.

The monitored-inbox example is also updated: Mautic 8.0 removed the MONITORED_EMAIL_CONFIG constant, so the subscriber now keys on MonitoredEmailEvent::class, with a note that referencing the removed constant throws a PHP fatal error. The EMAIL_PRE_FETCH and EMAIL_PARSE events remain string-dispatched and are unchanged.

Trigger Events

mautic/mautic PR #17225: Dispatch Campaign and Email bundle events by class name (Symfony 4.3 style)

Review response (@adiati98)

Thanks for the review! Addressed all requested changes in docs/plugin_extensions/emails.rst and swept the rest of the diff for the same issues so nothing's left to re-flag:

Hyphen instead of parentheses (applied verbatim): replaced the parenthetical asides at the "Rendering custom tokens" sentence and in the three "Undefined constant" notes with spaced hyphens.
Hyphen instead of em dash (applied verbatim): the em dash in the send/display note is now a hyphen.
#. instead of numbers for the ordered list (applied verbatim): the monitored-inbox list now uses #. on all three items.
Active instead of passive voice (applied): rewrote items 2 and 3 of that list — "Mautic dispatches this event during the execution of the mautic:email:fetch command. Use it to inject search criteria for the desired messages." and "This event parses the messages that the command fetched."

Code blocks, class names, constants, and the Error: Undefined constant string are unchanged. Vale passes with no new violations.

Update the Email plugin-extension examples to key getSubscribedEvents() on event class names (EmailOnBuildEvent, EmailSendEvent, EmailDisplayEvent, EmailOnTogglePublishEvent) instead of the removed EmailEvents string constants, rename EmailBuilderEvent to EmailOnBuildEvent, and add BC-break notes explaining the Mautic 8.0 migration. Source: mautic/mautic#17225

promptless-for-oss · 2026-09-02T09:22:46Z

 =====================================

-Registering tokens leverages the ``\Mautic\EmailBundle\EmailEvents::EMAIL_ON_BUILD`` event. The event is dispatched before displaying the email builder form, to allow adding of tokens.
+Registering tokens uses the ``Mautic\EmailBundle\Event\EmailOnBuildEvent`` event. Since Mautic 8.0, Mautic dispatches this event by class name, so subscribers key on ``EmailOnBuildEvent::class``. Mautic dispatches it before displaying the Email builder form, so subscribers can add tokens before the form displays.


Verified: EmailBuilderEvent renamed to EmailOnBuildEvent (git rename in PR diff); EMAIL_ON_BUILD is dispatched by class (EmailOnBuildEvent::class) as of Mautic 8.0, matching EmailEvents.php constant removal and BuilderSubscriber.php key changes.

Source: mautic/mautic#17225

promptless-for-oss · 2026-09-02T09:22:47Z

+Registering tokens uses the ``Mautic\EmailBundle\Event\EmailOnBuildEvent`` event. Since Mautic 8.0, Mautic dispatches this event by class name, so subscribers key on ``EmailOnBuildEvent::class``. Mautic dispatches it before displaying the Email builder form, so subscribers can add tokens before the form displays.

-An event listener receives the ``Mautic\EmailBundle\Event\EmailBuilderEvent``.
+An event listener receives the ``Mautic\EmailBundle\Event\EmailOnBuildEvent``.


Verified: listener receives Mautic\EmailBundle\Event\EmailOnBuildEvent (renamed from EmailBuilderEvent); addToken() is available via parent Mautic\CoreBundle\Event\BuilderEvent, confirmed in app/bundles/CoreBundle/Event/BuilderEvent.php on 8.x.

Source: mautic/mautic#17225

promptless-for-oss · 2026-09-02T09:22:48Z

 =======================

-To render custom tokens, use the ``\Mautic\EmailBundle\EmailEvents::EMAIL_ON_SEND`` event when Mautic sends the Email, or the ``\Mautic\EmailBundle\EmailEvents::EMAIL_ON_DISPLAY`` event when the Email displays in a browser such as after the Contact clicks the ``{webview_url}`` link.
+To render custom tokens, key on the ``Mautic\EmailBundle\Event\EmailSendEvent`` event (``EmailSendEvent::class``) when Mautic sends the Email, or the ``Mautic\EmailBundle\Event\EmailDisplayEvent`` event (``EmailDisplayEvent::class``) when the Email displays in a browser, for example, when the Contact clicks the ``{webview_url}`` link.


Verified: EMAIL_ON_SEND now dispatched via EmailSendEvent::class (constant kept as webhook identifier per UPGRADE-8.0.md); EMAIL_ON_DISPLAY now dispatched via new EmailDisplayEvent::class (constant removed, confirmed in EmailEvents.php diff and UPGRADE-8.0.md removed-constants table).

Source: mautic/mautic#17225

promptless-for-oss · 2026-09-02T09:22:49Z

+To render custom tokens, key on the ``Mautic\EmailBundle\Event\EmailSendEvent`` event (``EmailSendEvent::class``) when Mautic sends the Email, or the ``Mautic\EmailBundle\Event\EmailDisplayEvent`` event (``EmailDisplayEvent::class``) when the Email displays in a browser, for example, when the Contact clicks the ``{webview_url}`` link.

-An event listener receives in both cases the ``Mautic\EmailBundle\Event\EmailSendEvent``. You can replace a custom token using the events ``$event->addToken($token, $contentToReplaceToken)``.
+The send path receives a ``Mautic\EmailBundle\Event\EmailSendEvent``. The display path receives a ``Mautic\EmailBundle\Event\EmailDisplayEvent``, a subclass of ``EmailSendEvent`` that exposes the same ``addToken()``, ``getContent()``, and ``setContent()`` API. These are now separate classes, keyed separately: a listener keyed only on ``EmailSendEvent::class`` doesn't receive ``EmailDisplayEvent``, so a handler serving both paths must register under both keys. Replace a custom token using the event's ``$event->addToken($token, $contentToReplaceToken)``.


Verified: EmailDisplayEvent is final class EmailDisplayEvent extends EmailSendEvent {} (new file), inheriting addToken()/getContent()/setContent() from EmailSendEvent. Confirmed Symfony class-name dispatch means a listener keyed only on EmailSendEvent::class will not receive EmailDisplayEvent instances (get_class() based event name matching), so dual registration is required, matching the pattern in AssetBundle/EmailBundle BuilderSubscriber.php and EmailSubscriber.php.

Source: mautic/mautic#17225

promptless-for-oss · 2026-09-02T09:22:50Z

-          EmailEvents::EMAIL_ON_BUILD => ['onEmailBuild', 0],
-          EmailEvents::EMAIL_ON_SEND => ['onEmailGenerate', 0],
-          EmailEvents::EMAIL_ON_DISPLAY => ['onEmailGenerate', 0],
+          EmailOnBuildEvent::class => ['onEmailBuild', 0],


Verified: getSubscribedEvents() code sample keys (EmailOnBuildEvent::class, EmailSendEvent::class, EmailDisplayEvent::class) match the real subscriber changes in app/bundles/EmailBundle/EventListener/BuilderSubscriber.php and DateTimeTokenSubscriber.php in the PR diff.

Source: mautic/mautic#17225

promptless-for-oss · 2026-09-02T09:22:51Z

 .. vale on

-The ``\Mautic\EmailBundle\EmailEvents::EMAIL_ON_TOGGLE_PUBLISH`` event dispatches when a User toggles the **Active** status of an Email. Mautic dispatches it before persisting the status change to the database, so Plugins can run actions or validations before the User activates or deactivates the Email.
+The ``Mautic\EmailBundle\Event\EmailOnTogglePublishEvent`` event fires when a User toggles the **Active** status of an Email. Since Mautic 8.0, Mautic dispatches it by class name, before persisting the status change to the database, so Plugins can run actions or validations before the User activates or deactivates the Email.


Verified: new EmailOnTogglePublishEvent (final class extending EmailEvent) is dispatched by class name for the toggle-publish action; matches new file app/bundles/EmailBundle/Event/EmailOnTogglePublishEvent.php and its use as an array key ('on_toggle_publish' => EmailOnTogglePublishEvent::class) in the PR diff.

Source: mautic/mautic#17225

promptless-for-oss · 2026-09-02T09:22:52Z

        {
            return [
-                EmailEvents::EMAIL_ON_TOGGLE_PUBLISH => ['onEmailTogglePublish', 0],
+                EmailOnTogglePublishEvent::class => ['onEmailTogglePublish', 0],


Verified: code sample keys getSubscribedEvents() on EmailOnTogglePublishEvent::class and getEmail() returns the Email entity, matching EmailEvent::getEmail() (app/bundles/EmailBundle/Event/EmailEvent.php) and the PR's own functional test (EventSubscriberSmokeTest / testTogglePublishEventIsDispatched).

Source: mautic/mautic#17225

promptless-for-oss · 2026-09-02T09:22:53Z

-The ``\Mautic\EmailBundle\EmailEvents::EMAIL_ON_TOGGLE_PUBLISH`` event dispatches when a User toggles the **Active** status of an Email. Mautic dispatches it before persisting the status change to the database, so Plugins can run actions or validations before the User activates or deactivates the Email.
+The ``Mautic\EmailBundle\Event\EmailOnTogglePublishEvent`` event fires when a User toggles the **Active** status of an Email. Since Mautic 8.0, Mautic dispatches it by class name, before persisting the status change to the database, so Plugins can run actions or validations before the User activates or deactivates the Email.
+
+An event listener receives a ``Mautic\EmailBundle\Event\EmailOnTogglePublishEvent`` instance, a subclass of ``EmailEvent``. Call ``getEmail()`` to get the Email, then ``isPublished()`` on that Email entity to read its current **Active** status.


Verified: EmailOnTogglePublishEvent is final class EmailOnTogglePublishEvent extends EmailEvent {} (new file in PR). EmailEvent (app/bundles/EmailBundle/Event/EmailEvent.php) only exposes getEmail()/setEmail(), no isPublished(). isPublished() is defined on the Email entity's parent Mautic\CoreBundle\Entity\FormEntity, not on the event, confirming the doc's corrected instruction to call getEmail() then isPublished() on the returned Email entity. "Active" status matches the doc's own toggle-publish terminology used throughout this section (Toggle 'Active' event).

Source: mautic/mautic#17225

promptless-for-oss · 2026-09-02T09:22:54Z

+
+.. note::
+
+   Since Mautic 8.0, the build, send, and display events dispatch by class name, so key ``getSubscribedEvents()`` on ``EmailOnBuildEvent::class``, ``EmailSendEvent::class``, or ``EmailDisplayEvent::class``. Mautic renamed ``EmailBuilderEvent`` to ``EmailOnBuildEvent`` and removed the ``EMAIL_ON_BUILD`` and ``EMAIL_ON_DISPLAY`` constants, so code that still references ``EmailEvents::EMAIL_ON_BUILD`` or ``EmailEvents::EMAIL_ON_DISPLAY`` throws a PHP fatal error (``Error: Undefined constant``). The ``EMAIL_ON_SEND`` constant remains, but Mautic no longer dispatches by it, so a subscriber keyed on ``EmailEvents::EMAIL_ON_SEND`` silently stops firing — key on ``EmailSendEvent::class`` instead.


Verified against EmailEvents.php diff and UPGRADE-8.0.md removed-constants table: EMAIL_ON_BUILD and EMAIL_ON_DISPLAY constants are removed entirely (referencing them is now an undefined-class-constant fatal error). EMAIL_ON_SEND remains in EmailEvents.php (kept because it doubles as a webhook type identifier per UPGRADE-8.0.md), but MailHelper::dispatchSendEvent() now calls $this->dispatcher->dispatch($event) with no event-name argument, i.e. dispatch is keyed by class name only, so a subscriber still keyed on the string constant EmailEvents::EMAIL_ON_SEND no longer matches and silently stops receiving the event.

Source: mautic/mautic#17225

promptless-for-oss · 2026-09-02T09:22:55Z

-An event listener receives a ``Mautic\EmailBundle\Event\EmailEvent`` instance.
+.. note::
+
+   Since Mautic 8.0, this event dispatches by class name, so key ``getSubscribedEvents()`` on ``EmailOnTogglePublishEvent::class``. Mautic removed the ``EMAIL_ON_TOGGLE_PUBLISH`` constant, so code that still references ``EmailEvents::EMAIL_ON_TOGGLE_PUBLISH`` throws a PHP fatal error (``Error: Undefined constant``).


Verified: EmailEvents::EMAIL_ON_TOGGLE_PUBLISH constant is removed in the EmailEvents.php diff (also listed in the UPGRADE-8.0.md removed-constants table, mapped to the new EmailOnTogglePublishEvent class); referencing the removed constant is a PHP undefined-class-constant fatal error.

Source: mautic/mautic#17225

The Mautic 8.0 class-name event dispatch (PR mautic/mautic#17225) removed the EmailEvents::MONITORED_EMAIL_CONFIG constant. Update the monitored-inbox plugin example to key getSubscribedEvents() on MonitoredEmailEvent::class and add a note explaining the removed constant now throws a fatal error. The EMAIL_PRE_FETCH and EMAIL_PARSE events remain string-dispatched and unchanged.

promptless-for-oss · 2026-09-04T09:03:49Z

 To do this, the Plugin needs to add an event listener for three events:

-1. ``EmailEvents::MONITORED_EMAIL_CONFIG`` This event is dispatched to inject the fields into Mautic's Configuration to configure the IMAP inbox and folder that should be monitored.
+1. ``Mautic\EmailBundle\Event\MonitoredEmailEvent`` This event injects the fields into Mautic's Configuration to configure the IMAP inbox and folder to monitor. Since Mautic 8.0, Mautic dispatches it by class name, so subscribers key on ``MonitoredEmailEvent::class``.


Verified: FQCN is Mautic\EmailBundle\Event\MonitoredEmailEvent (app/bundles/EmailBundle/Event/MonitoredEmailEvent.php:10, final class extends Event). Core's own ConfigMonitoredEmailType::buildForm() calls $this->dispatcher->dispatch($event); with no event-name argument (line 29), i.e. Symfony dispatches by the event's class name. This class-name dispatch predates PR #17225 (the file is untouched by the PR diff); PR #17225 removed the now-orphaned EmailEvents::MONITORED_EMAIL_CONFIG string constant that had never matched this call site's actual dispatch.

Source: https://github.com/mautic/mautic/blob/b210263d2e6aad327b8cdf9407cbba2470dbb2b6/app/bundles/EmailBundle/Form/Type/ConfigMonitoredEmailType.php#L29

promptless-for-oss · 2026-09-04T09:03:50Z


+.. note::
+
+   Since Mautic 8.0, the monitored inbox configuration event dispatches by class name, so key ``getSubscribedEvents()`` on ``MonitoredEmailEvent::class``. Mautic removed the ``MONITORED_EMAIL_CONFIG`` constant, so code that still references ``EmailEvents::MONITORED_EMAIL_CONFIG`` throws a PHP fatal error (``Error: Undefined constant``). ``EMAIL_PRE_FETCH`` and ``EMAIL_PARSE`` remain string-dispatched constants.


Verified: UPGRADE-8.0.md "Removed code" table lists MONITORED_EMAIL_CONFIG -> MonitoredEmailEvent as a removed EmailEvents constant (line 38), and app/bundles/EmailBundle/EmailEvents.php at the PR head SHA confirms the constant is absent (referencing EmailEvents::MONITORED_EMAIL_CONFIG now throws PHP Error: Undefined constant). The same file's intro text (UPGRADE-8.0.md line 43) and EmailEvents.php (EMAIL_PARSE at line 30, EMAIL_PRE_FETCH at line 38) confirm both constants remain, and MonitoredEmail/Fetcher.php still dispatches by string via EmailEvents::EMAIL_PRE_FETCH (line 40) and EmailEvents::EMAIL_PARSE (line 68).

Source: https://github.com/mautic/mautic/blob/b210263d2e6aad327b8cdf9407cbba2470dbb2b6/UPGRADE-8.0.md#L38

promptless-for-oss · 2026-09-04T09:03:51Z

-                EmailEvents::MONITORED_EMAIL_CONFIG => ['onConfig', 0],
-                EmailEvents::EMAIL_PRE_FETCH        => ['onPreFetch', 0],
-                EmailEvents::EMAIL_PARSE            => ['onParse', 0],
+                MonitoredEmailEvent::class   => ['onConfig', 0],


Verified: the code sample's MonitoredEmailEvent::class => ['onConfig', 0] subscriber key matches the real pattern used by Mautic's own monitored-inbox subscribers (ProcessBounceSubscriber.php:20, and identically in ProcessReplySubscriber.php and ProcessUnsubscribeSubscriber.php), all of which key getSubscribedEvents() on MonitoredEmailEvent::class rather than a string constant.

Source: https://github.com/mautic/mautic/blob/b210263d2e6aad327b8cdf9407cbba2470dbb2b6/app/bundles/EmailBundle/EventListener/ProcessBounceSubscriber.php#L20

adiati98

@promptless-for-oss please address the suggestions.

adiati98 · 2026-09-07T13:01:04Z

 =======================

-To render custom tokens, use the ``\Mautic\EmailBundle\EmailEvents::EMAIL_ON_SEND`` event when Mautic sends the Email, or the ``\Mautic\EmailBundle\EmailEvents::EMAIL_ON_DISPLAY`` event when the Email displays in a browser such as after the Contact clicks the ``{webview_url}`` link.
+To render custom tokens, key on the ``Mautic\EmailBundle\Event\EmailSendEvent`` event (``EmailSendEvent::class``) when Mautic sends the Email, or the ``Mautic\EmailBundle\Event\EmailDisplayEvent`` event (``EmailDisplayEvent::class``) when the Email displays in a browser, for example, when the Contact clicks the ``{webview_url}`` link.


We use hyphen instead of parentheses.

adiati98 · 2026-09-07T13:01:38Z

+
+.. note::
+
+   Since Mautic 8.0, the build, send, and display events dispatch by class name, so key ``getSubscribedEvents()`` on ``EmailOnBuildEvent::class``, ``EmailSendEvent::class``, or ``EmailDisplayEvent::class``. Mautic renamed ``EmailBuilderEvent`` to ``EmailOnBuildEvent`` and removed the ``EMAIL_ON_BUILD`` and ``EMAIL_ON_DISPLAY`` constants, so code that still references ``EmailEvents::EMAIL_ON_BUILD`` or ``EmailEvents::EMAIL_ON_DISPLAY`` throws a PHP fatal error (``Error: Undefined constant``). The ``EMAIL_ON_SEND`` constant remains, but Mautic no longer dispatches by it, so a subscriber keyed on ``EmailEvents::EMAIL_ON_SEND`` silently stops firing — key on ``EmailSendEvent::class`` instead.


We use hyphen instead of parentheses and em dash.

adiati98 · 2026-09-07T13:02:57Z

+1. ``Mautic\EmailBundle\Event\MonitoredEmailEvent`` This event injects the fields into Mautic's Configuration to configure the IMAP inbox and folder to monitor. Since Mautic 8.0, Mautic dispatches it by class name, so subscribers key on ``MonitoredEmailEvent::class``.
 2. ``EmailEvents::EMAIL_PRE_FETCH`` This event is dispatched during the execution of the ``mautic:email:fetch`` command. It's used to inject search criteria for the messages desired.
 3. ``EmailEvents::EMAIL_PARSE`` This event parses the messages fetched by the command.


Follow our guide to use #. instead of number for ordered list.

Use active instead of passive voice.

adiati98 · 2026-09-07T13:04:40Z


+.. note::
+
+   Since Mautic 8.0, the monitored inbox configuration event dispatches by class name, so key ``getSubscribedEvents()`` on ``MonitoredEmailEvent::class``. Mautic removed the ``MONITORED_EMAIL_CONFIG`` constant, so code that still references ``EmailEvents::MONITORED_EMAIL_CONFIG`` throws a PHP fatal error (``Error: Undefined constant``). ``EMAIL_PRE_FETCH`` and ``EMAIL_PARSE`` remain string-dispatched constants.


We use hyphen instead of parentheses.

adiati98 · 2026-09-07T13:05:12Z

+
+.. note::
+
+   Since Mautic 8.0, this event dispatches by class name, so key ``getSubscribedEvents()`` on ``EmailOnTogglePublishEvent::class``. Mautic removed the ``EMAIL_ON_TOGGLE_PUBLISH`` constant, so code that still references ``EmailEvents::EMAIL_ON_TOGGLE_PUBLISH`` throws a PHP fatal error (``Error: Undefined constant``).


We use hyphen instead of parentheses.

promptless-for-oss · 2026-09-07T13:06:42Z

Thanks @adiati98 — on it. We'll apply your style fixes (hyphens instead of parentheses and em dashes, #. for the ordered list, and active voice) and push an update to this PR shortly.

…tive voice Address CHANGES_REQUESTED on PR mautic#660 for docs/plugin_extensions/emails.rst: - Replace parenthetical asides with spaced hyphens (rendering-tokens sentence and the removed-constant notes) - Replace the em dash in the send/display note with a hyphen - Convert the monitored-inbox ordered list from 1./2./3. to #. - Rewrite items 2 and 3 of that list in active voice

promptless-for-oss · 2026-09-07T13:29:25Z

Thanks for the review, @adiati98! I've addressed all the requested changes in docs/plugin_extensions/emails.rst and swept the rest of the diff for the same issues so nothing's left to re-flag:

Hyphen instead of parentheses: replaced the parenthetical asides in the "Rendering custom tokens" sentence and in the three "Undefined constant" notes with spaced hyphens.
Hyphen instead of em dash: the em dash in the send/display note is now a hyphen.
#. instead of numbers: the monitored-inbox ordered list now uses #. on all three items.
Active instead of passive voice: rewrote items 2 and 3 of that list - "Mautic dispatches this event during the execution of the mautic:email:fetch command. Use it to inject search criteria for the desired messages." and "This event parses the messages that the command fetched."

Code blocks, class names, constants, and the Error: Undefined constant string are unchanged, and Vale passes with no new violations.

promptless-for-oss commented Sep 2, 2026

View reviewed changes

promptless-for-oss mentioned this pull request Sep 2, 2026

[events] Dispatch Campaign and Email bundle events by class name (Symfony 4.3 style) mautic/mautic#17225

Merged

adiati98 added this to the 8.0 milestone Sep 3, 2026

adiati98 added the needs-rebase label Sep 3, 2026

promptless-for-oss commented Sep 4, 2026

View reviewed changes

adiati98 requested changes Sep 7, 2026

View reviewed changes

adiati98 and others added 2 commits September 7, 2026 15:07

Merge branch '7.2' into promptless/pr-17225-email-events-by-class

63c104d


		.. note::

		Since Mautic 8.0, the build, send, and display events dispatch by class name, so key ``getSubscribedEvents()`` on ``EmailOnBuildEvent::class``, ``EmailSendEvent::class``, or ``EmailDisplayEvent::class``. Mautic renamed ``EmailBuilderEvent`` to ``EmailOnBuildEvent`` and removed the ``EMAIL_ON_BUILD`` and ``EMAIL_ON_DISPLAY`` constants, so code that still references ``EmailEvents::EMAIL_ON_BUILD`` or ``EmailEvents::EMAIL_ON_DISPLAY`` throws a PHP fatal error (``Error: Undefined constant``). The ``EMAIL_ON_SEND`` constant remains, but Mautic no longer dispatches by it, so a subscriber keyed on ``EmailEvents::EMAIL_ON_SEND`` silently stops firing — key on ``EmailSendEvent::class`` instead.


		.. note::

		Since Mautic 8.0, the monitored inbox configuration event dispatches by class name, so key ``getSubscribedEvents()`` on ``MonitoredEmailEvent::class``. Mautic removed the ``MONITORED_EMAIL_CONFIG`` constant, so code that still references ``EmailEvents::MONITORED_EMAIL_CONFIG`` throws a PHP fatal error (``Error: Undefined constant``). ``EMAIL_PRE_FETCH`` and ``EMAIL_PARSE`` remain string-dispatched constants.


		.. note::

		Since Mautic 8.0, this event dispatches by class name, so key ``getSubscribedEvents()`` on ``EmailOnTogglePublishEvent::class``. Mautic removed the ``EMAIL_ON_TOGGLE_PUBLISH`` constant, so code that still references ``EmailEvents::EMAIL_ON_TOGGLE_PUBLISH`` throws a PHP fatal error (``Error: Undefined constant``).

Uh oh!

Conversation

promptless-for-oss commented Sep 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

adiati98 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

promptless-for-oss commented Sep 7, 2026

Uh oh!

promptless-for-oss commented Sep 7, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

promptless-for-oss commented Sep 2, 2026 •

edited

Loading