Document class-name dispatch for IntegrationsBundle events (Mautic 8) - #642
Conversation
Since Mautic 8, IntegrationsBundle dispatches many events by the event object alone (event class = event name), so subscribers must key getSubscribedEvents() on the event class rather than the retained-but-unused IntegrationEvents constants. Add a note to the Available events section warning that a stale constant-keyed subscriber fails silently, and that multi-name event families still dispatch by their constants. Source: mautic/mautic#17160
|
|
||
| .. note:: | ||
|
|
||
| Since Mautic 8, Mautic dispatches many ``Mautic\IntegrationsBundle\Event`` events by the event object alone, so the event class is the event name. This matches the Symfony 4.3 dispatch style. |
There was a problem hiding this comment.
Confirms: since Mautic 8 (branch 8.x), many Mautic\IntegrationsBundle\Event events are dispatched by the event object alone so the event class is the event name, matching Symfony 4.3+ dispatch style. Source: mautic/mautic PR #17160, UPGRADE-8.0.md added text.
Source: https://github.com/mautic/mautic/blob/efe772f301f8cf074ef145aa864b4918dc349137/UPGRADE-8.0.md#L178
|
|
||
| Since Mautic 8, Mautic dispatches many ``Mautic\IntegrationsBundle\Event`` events by the event object alone, so the event class is the event name. This matches the Symfony 4.3 dispatch style. | ||
|
|
||
| * For a converted event, key ``getSubscribedEvents()`` on the event class, for example ``InternalObjectEvent::class``, not on the matching ``Mautic\IntegrationsBundle\IntegrationEvents`` constant or its string value. |
There was a problem hiding this comment.
Confirms: getSubscribedEvents() now keys the converted InternalObjectEvent on InternalObjectEvent::class rather than on IntegrationEvents::INTEGRATION_COLLECT_INTERNAL_OBJECTS or its string value. Source: mautic/mautic PR #17160, CompanyObjectSubscriber.php.
| Since Mautic 8, Mautic dispatches many ``Mautic\IntegrationsBundle\Event`` events by the event object alone, so the event class is the event name. This matches the Symfony 4.3 dispatch style. | ||
|
|
||
| * For a converted event, key ``getSubscribedEvents()`` on the event class, for example ``InternalObjectEvent::class``, not on the matching ``Mautic\IntegrationsBundle\IntegrationEvents`` constant or its string value. | ||
| * The ``IntegrationEvents`` constants remain in the codebase but are no longer used to dispatch these events, so a subscriber still keyed on a converted constant won't fire. It fails silently: it throws no exception and logs nothing, and simply never runs. |
There was a problem hiding this comment.
Confirms: IntegrationEvents.php constants remain in the codebase (class not removed) and none are marked @deprecated at this SHA. Combined with UPGRADE-8.0.md line 190 ("constants are kept for backwards compatibility but are no longer used internally for the events below") and dispatch call sites (e.g. ObjectProvider.php#L66, ConfigController.php#L53) that dropped the constant argument, this supports that a subscriber still keyed on a converted constant will not match the new event-class dispatch name and therefore never fires, with no exception thrown or logged (standard Symfony EventDispatcher::dispatch semantics for an event with no matching listeners).
|
|
||
| * For a converted event, key ``getSubscribedEvents()`` on the event class, for example ``InternalObjectEvent::class``, not on the matching ``Mautic\IntegrationsBundle\IntegrationEvents`` constant or its string value. | ||
| * The ``IntegrationEvents`` constants remain in the codebase but are no longer used to dispatch these events, so a subscriber still keyed on a converted constant won't fire. It fails silently: it throws no exception and logs nothing, and simply never runs. | ||
| * Mautic 8 converted only events whose class maps to a single name. Families whose class serves several names, such as ``ConfigSaveEvent`` and ``InternalObjectFindEvent``, still dispatch by their ``IntegrationEvents`` constants, so keep keying on the constant for those. |
There was a problem hiding this comment.
Confirms: ConfigSaveEvent (shared by INTEGRATION_CONFIG_BEFORE_SAVE and INTEGRATION_CONFIG_AFTER_SAVE) was deliberately left dispatched with the IntegrationEvents constant, unconverted by PR #17160 (file not in the PR's changed-file list). Likewise IntegrationEvents.php#L89 and #L96 show INTEGRATION_FIND_INTERNAL_RECORDS and INTEGRATION_FIND_OWNER_IDS both map to the shared InternalObjectFindEvent class and both remain dispatched via their constants (e.g. OwnerProvider.php, PartialObjectReportBuilder.php), consistent with "only events whose class maps to a single name were converted."
|
I noticed that some CI checks failed for this PR. I'm investigating whether the failures are caused by this suggestion. If they're unrelated or pre-existing, I'll leave this suggestion unchanged and create a separate suggestion if a standalone docs fix is needed. |
2 participants
Open in Promptless
Since Mautic 8, the IntegrationsBundle dispatches many of its events by the event object alone (Symfony 4.3 style), so the event class is the event name. A subscriber that still keys
getSubscribedEvents()on the matchingMautic\IntegrationsBundle\IntegrationEventsconstant no longer fires for a converted event — and it fails silently, throwing no exception and logging nothing.This adds a note to the "Available events" section of
docs/plugins/event_listeners.rstexplaining that plugin developers must key on the event class (for exampleInternalObjectEvent::class) instead of the retained-but-unused constants, and that event families whose class serves several names (such asConfigSaveEventandInternalObjectFindEvent) still dispatch by theirIntegrationEventsconstants.Source: mautic/mautic#17160 (follow-up to #17157, which converted CoreBundle).
Trigger Events