## Problem/Motivation `Campaign::baseFieldDefinitions()` declares `messages` as an unlimited-cardinality `entity_reference` to `campaign_message`, with `entity_reference_autocomplete` as its form widget. So adding a message to a campaign means leaving the campaign form, creating the message at `/admin/content/campaign-messages/add/{campaign_message_type}`, saving it, returning to the campaign, and finding it again by typing its label into an autocomplete. Editing a message's body from the campaign is the same round trip. There is no create, edit or remove affordance where the author is actually working. The ordering compounds it. The field's deltas **are** the send sequence — the entity docblock is explicit that "there is no separate weight" — so the order of those autocomplete rows is a real, meaningful decision the author is being asked to make about a list of opaque labels. ## Proposed resolution Replace the autocomplete widget with the Inline Entity Form complex widget, so messages are created, edited, reordered and removed in place on the campaign form. `inline_entity_form` 3.0.0 (released 2026-06-05) declares `^8.8 || ^9 || ^10 || ^11` and carries security coverage. Its 3.1.x branch is planned to require Drupal 11.3+ and PHP 8.3+, which is exactly this project's floor — so the dependency is not a compatibility risk in either direction. ### Four things the plan must settle, not assume **1. Dependency posture.** This would be the module's first non-dev runtime contrib dependency, and the project has an established pattern for optional integrations that this change should not quietly break: `entity_segment` is optional and its recipient plugin is removed from the definitions by `RecipientManager::alterDefinitions()` when the module is absent; every editor ships as its own submodule. The options are a hard `require`, an optional dependency with the autocomplete widget as fallback, or a `campaign_inline_messages` submodule matching the pattern already in use. Pick deliberately. **2. Nested AJAX, and whether the composition subform survives at all.** This is the central technical question. `CampaignMessageForm` is not a plain entity form — it builds a composition plugin subform and swaps it via AJAX on plugin change (`CampaignMessageForm::updateCompositionSubform()`, wrapper constant `campaign-composition-subform-wrapper`). IEF embeds the target entity type's **form display**, not an arbitrary form class, so the composition subform would not appear inside the IEF widget unless it is reimplemented for that context. An inline message form that cannot author a body is not worth shipping, so establish feasibility before planning the rest. Note also that `SUBFORM_WRAPPER` is a hard-coded constant: two message forms on one page collide on the same DOM id. **3. Backreference sync ordering.** `Campaign::postSave()` writes each referenced message's `campaign` backreference, last-writer-wins, and the `campaign_message` insert/update hooks recompute asset usage through `campaign.asset_usage`. IEF saves referenced entities as part of the parent save. Confirm the ordering still holds and that a message created inline is saved before the campaign's `postSave()` runs, or the backreference lands on nothing. **4. The sent lock.** Once a campaign's stored status is `sent`, `CampaignLockConstraint` and `CampaignMessageLockConstraint` reject modifying saves and the access handlers forbid update and delete. The IEF widget must not offer edit or remove buttons that are guaranteed to fail validation. ## Remaining tasks - [ ] Settle the dependency posture. - [ ] Prove the composition subform can be authored inside the IEF widget — this gates everything else. - [ ] Swap the widget in the base field definition and/or the shipped form display config. - [ ] Verify backreference sync and asset-usage recompute still fire correctly. - [ ] Suppress inline CRUD on a sent campaign. - [ ] Functional coverage for create/edit/reorder/remove inline. ## API changes Adds a contrib dependency (form and shape to be decided above). The `messages` field storage, cardinality and target type are unchanged; only the form widget changes, so stored data is unaffected. ## Data model changes None. ## Related - [#3615676](https://git.drupalcode.org/project/campaign/-/work_items/3615676) — the single-message campaign UX, which is where an inlined message form pays off most, and which should be sequenced against this. - [#3615680](https://git.drupalcode.org/project/campaign/-/work_items/3615680) — hiding the composition plugin select when only one plugin is available; the same form surface. AI-Generated: Yes (Used Claude Code Opus 5 to generate the text of this issue.)