Document Mautic 8.0 class-name dispatch for the Campaign builder event

[promptless-for-oss]

Open in Promptless

Mautic 8.0 dispatches the CampaignBuilderEvent by its class name (Symfony 4.3 style), so a Plugin that registers a Campaign Action, Condition, or Decision must key getSubscribedEvents() on CampaignBuilderEvent::class. A subscriber still keyed on the CampaignEvents::CAMPAIGN_ON_BUILD string constant no longer receives the event, even though that constant remains defined in Mautic's code — a silent break for out-of-tree Plugins upgrading to Mautic 8.0.

This updates the plugin extension docs to reflect that change: the "Registering Campaign Events" section now states the class-name dispatch and the silent breaking change once, followed by a single scannable table mapping the former CampaignEvents::CAMPAIGN_ON_BUILD constant to the CampaignBuilderEvent::class subscription key. The six Action/Condition/Decision examples key on CampaignBuilderEvent::class (and drop the now-unused CampaignEvents import), the CampaignBuilderEvent namespace directive is corrected to the singular Event, and the SMS batch-action cross-reference is updated to match. The Plugin's own custom events registered via batchEventName/eventName are dispatched by the Campaign engine by string name and are unchanged, so those subscription keys stay as string constants.

Addressing review feedback (@TomasVotruba)

Re: "it would great to have just one section for all events constants => event classes, with single table … Logic is always the same, no need to repeat it 👍"

• Applied: consolidated the repeated "constant → event class" explanation in campaigns.rst into one statement of the logic, followed by a single list-table that gives the replacement at a glance. The duplicate note that restated the same logic is gone.
• Scoping note: this PR is tied to a single source PR (mautic/mautic #17161) under the project's one-docs-PR-per-source-PR convention, so the consolidated section and table cover the Campaign event this PR owns. The same class-name-dispatch change lands across a series of sibling docs PRs (one per source PR / bundle), several still open. A truly cross-bundle "one table for all events" would need to pull those separate source PRs' content together — happy to coordinate a shared table on a common page (e.g. docs/plugins/event_listeners.rst) as a follow-up if you'd prefer that over per-bundle tables; flagging rather than merging the sibling PRs' content here.

Trigger Events

• mautic/mautic PR #17161: Dispatch CampaignBundle events by class name (Symfony 4.3 style)

[TomasVotruba]

Looks good!

[TomasVotruba]

In the end, it would great to have just one section for all events constants => event classes, with single table.
This would make it easier to scan through it and find the right replacement 👍 Logic is always the same, no need to repeat it

[promptless-for-oss]

Thanks @TomasVotruba! Good call — one shared section with a single constant → event-class table instead of repeating the same explanation per bundle. We're working on consolidating it now and will push an update to this PR shortly.

[promptless-for-oss]

Quick update: we've scoped the change. Within this PR (which covers campaigns.rst and sms.rst) we're collapsing the duplicated explanation into a single note + table so the logic is stated once. We're also looking at how a shared, scannable constant → event-class table could work across the whole class-name-dispatch series, and we'll follow up here with a recommendation on that.

[promptless-for-oss]

Pushed the update to this PR: campaigns.rst now states the class-name-dispatch logic once and carries a single scannable constant → event-class table (CampaignEvents::CAMPAIGN_ON_BUILD → CampaignBuilderEvent::class), with the duplicate note removed. We'll follow up shortly on the broader cross-series table idea.

[promptless-for-oss]

Thanks for the review, @TomasVotruba — good call. We've consolidated the repeated "constant → event class" explanation in the Campaign plugin docs into a single statement of the logic followed by one scannable table (CampaignEvents::CAMPAIGN_ON_BUILD → CampaignBuilderEvent::class), so the replacement is easy to find in one place and the table can grow a row per event.

One scoping note: because this PR is tied to a single source PR (mautic/mautic#17161) under the one-docs-PR-per-source-PR convention, its table covers the Campaign event this PR owns; the same change is landing across a series of sibling docs PRs (one per bundle/source PR). If you'd prefer a single cross-bundle table on a shared page (e.g. docs/plugins/event_listeners.rst) over per-bundle tables, we're glad to coordinate that as a follow-up rather than merge those separate PRs' content together here — just let us know.

[adiati98]

/aside

@TomasVotruba Promptless has made a new change based on your last comment. Can you please review it? Thank you!