## Problem/Motivation The declared core floor is `^11.2`, raised there by [#3615644](https://git.drupalcode.org/project/campaign/-/work_items/3615644) so it would finally match the `getOriginal()` the entity sync and lock code already required. That fixed a false declaration, but it left the floor two minors behind current core (11.4.5) and one minor behind the oldest minor drupal.org still gives security coverage. Two things follow from that, and the second is the reason this is a task rather than a version bump. **The floor is still untested, and `^11.3` is the one value that changes that — for now.** `.gitlab-ci.yml` sets `OPT_IN_TEST_PREVIOUS_MINOR: 1`, which is relative to *current* core, not to the declaration. #3615644 recorded the consequence plainly: "nothing installs the declared floor, and nothing will." With current core at 11.4, previous-minor **is** 11.3, so a `^11.3` floor is the first floor this project has declared that CI actually installs and runs the suite against. This is worth taking, but it is a coincidence with an expiry date: when 11.5.0 ships (December 2026, the same release that ends 11.3's security coverage) previous-minor becomes 11.4 and the floor goes unexercised again. The structural gap named in #3615644 is not closed by this issue — it is briefly, accidentally covered. **A floor of `^11.3` removes procedural code that cannot be removed at `^11.2`.** This is the substantive half. The module carries two `.module` files and four `.install` files whose entire contents are hook implementations, and one specific conversion is gated on 11.3 rather than 11.2: `hook_requirements()` has an OOP replacement, `#[Hook('runtime_requirements')]`, and core itself has moved to it (`system`, `file`, `image`, `jsonapi`, `locale`, `media`). But `Drupal\Core\Hook\Attribute\LegacyRequirementsHook` documents the transition rule exactly: > Marking requirements hooks as #LegacyRequirementsHook will prevent them from running on Drupal 11.3.0 and later. Note that Drupal 11.2 supports both legacy and new OOP requirements hooks and will invoke **both** as this attribute is not recognized there. So at a `^11.2` floor an OOP conversion has to keep the procedural function *and* carry an attribute that 11.2 ignores — meaning 11.2 sites double-report every requirement. At `^11.3` the procedural function is simply deleted. `campaign.install`, `campaign_emailbuilder.install` and `campaign_easy_email.install` contain **nothing but** `hook_requirements()`, so all three files go away entirely. Alongside that, all four `.install` files still set `'severity' => REQUIREMENT_OK` / `REQUIREMENT_WARNING`. Those constants are `@deprecated in drupal:11.2.0 and is removed from drupal:12.0.0` in favour of `RequirementSeverity` enum cases, and passing ints triggers a deprecation notice today, at the current floor. That work is not 11.3-gated — it is already overdue — but it is the same edit to the same lines, so it belongs in this issue rather than a second one. ## Proposed resolution ### 1. Raise the floor to `^11.3` Sweep every site, as #3615644 did — a partial sweep reproduces the same class of defect it fixed: | File | What changes | | --- | --- | | `campaign.info.yml` | `core_version_requirement`, and the rationale comment (the `getOriginal()` story is no longer the binding constraint; the OOP requirements hooks are) | | `modules/campaign_emailbuilder/campaign_emailbuilder.info.yml` | `core_version_requirement` | | `modules/campaign_mosaico/campaign_mosaico.info.yml` | `core_version_requirement` | | `modules/campaign_easy_email/campaign_easy_email.info.yml` | `core_version_requirement` — note this one currently reads **`^11.1`**, not `^11.2`. It landed with the easy-email plugin after #3615644 had lifted every other site, so it is a stale copy of the old floor rather than a deliberate lower bound, and it contradicts its own comment ("Match the base module … widen together with `campaign.info.yml`, never independently") while depending on a base module requiring `^11.2`. | | `tests/modules/campaign_message_test/campaign_message_test.info.yml` | `core_version_requirement` | | `README.md` (Requirements) | `^11.2` → `^11.3` | | `CLAUDE.md` | the stated core support and its rationale | | `.gitlab-ci.yml` | three comments quoting `^11.2` in the Drupal-12 opt-out rationale | | `src/AssetUploader.php` | the "verified against `^11.2`" provenance note — re-verify the constraint plugin IDs against 11.3, do not just retype the number | `.tugboat/config.yml` already pins `q0rban/tugboat-drupal:11.4` and needs no change. `OPT_IN_TEST_NEXT_MAJOR` and `RUN_JOB_UPGRADE_STATUS` stay `0`: the Drupal 12 stance is unchanged by this issue. ### 2. Convert the requirements hooks and delete three `.install` files — **11.3-gated** - `src/Hook/CampaignRequirements.php` with `#[Hook('runtime_requirements')]`; delete `campaign.install`. - `modules/campaign_emailbuilder/src/Hook/EmailBuilderRequirements.php`; delete `campaign_emailbuilder.install`. - `modules/campaign_easy_email/src/Hook/EasyEmailRequirements.php`; delete `campaign_easy_email.install`. This implementation has **no test coverage** — `EasyEmailAvailabilityTest` covers only `testMissingLibraries()` and `testManagerAvailabilityFilter()` — so unlike the other three there is no assertion to port, and adding one is optional rather than required by the conversion. - `modules/campaign_mosaico/src/Hook/MosaicoRequirements.php`; **keep** `campaign_mosaico.install` — `hook_update_N()` is on the attribute system's procedural-only list, so `campaign_mosaico_update_10001()` cannot move and the file must survive with only that function in it. - No `#[LegacyRequirementsHook]` anywhere: with the floor at 11.3 there is no procedural implementation left for it to suppress. All four existing implementations begin `if ($phase !== 'runtime') { return []; }`. `hook_runtime_requirements()` takes no `$phase` and is only ever called for runtime, so that guard is deleted rather than translated. Hook classes are autowired services, which is the real win beyond file count: these become constructor-injected rather than reaching through `\Drupal::`. ### 3. Replace `REQUIREMENT_*` with `RequirementSeverity` — not 11.3-gated, but same lines Eight constant uses across the four implementations (`campaign.install:34,44`; `campaign_emailbuilder.install:32,42`; `campaign_easy_email.install:33,43`; `campaign_mosaico.install:61,71`), plus six test assertions across **three** tests, not two: - `tests/src/Kernel/GrapesJsAvailabilityTest.php:129,138` - `modules/campaign_emailbuilder/tests/src/Kernel/EmailBuilderAvailabilityTest.php:114,121` - `modules/campaign_mosaico/tests/src/Kernel/MosaicoAvailabilityTest.php:116,124` **The Mosaico test has now been checked, and it has the same pattern.** `testRequirementsHook()` at `MosaicoAvailabilityTest.php:104` `loadInclude()`s the `.install` and calls `campaign_mosaico_requirements()` by name, exactly as the other two do. So all three call the procedural function directly and `assertSame()` against the int constants, and all three must instead invoke the hook through the module handler and assert `RequirementSeverity::Warning` / `::OK`. All three also open with an `assertSame([], campaign_*_requirements('install'))` install-phase assertion. Those are **dropped rather than ported**: `hook_runtime_requirements()` takes no `$phase` argument and is runtime-only by construction, so there is no behaviour on the other side left to assert. Preserving them would mean inventing a test for a code path this conversion deliberately removes. ### 4. Convert the remaining hooks and delete both `.module` files — **available since 11.2, not gated by this bump** Included here because it is the other half of "no procedural hook files", and doing it in a separate issue means touching `phpstan.neon` twice. - `campaign.module` — `hook_entity_type_alter()` plus four `campaign_message` lifecycle hooks (`insert`, `update`, `delete`, `revision_delete`), all four of which call `\Drupal::service('campaign.asset_usage')`. Injecting `AssetUsageTracker` is the point of the conversion; the comments on the double-run and revision-revert behaviour must survive it verbatim. - `campaign_mosaico.module` — `hook_theme()` only. - **Two** tooling configs reference `.module`, not one, and both need updating once the files are gone: - `phpstan.neon:12` lists `campaign.module` in `paths`, and `module` sits in its `fileExtensions` list. Both go. `install` **stays** in `fileExtensions` — `campaign_mosaico.install` survives part 2 and should remain analysed, so the asymmetry there is deliberate. - `phpunit.xml:58,60` carry two `<directory suffix=".module">` coverage includes (`web/modules/custom/campaign` and `web/modules/custom/campaign/modules/*`). Both go. While that file is open: `phpunit.xml:65` also excludes `<directory suffix=".api.php">`, and no `.api.php` file has ever existed in this repository — drop that phantom exclude in the same edit rather than leave a future reader to disprove it. ### 5. Evaluate, and record the outcome for These were considered and are **not** committed to. Recording why keeps the next person from re-deriving it. - **Native HTMX (`core/drupal.htmx`, 11.3).** Five `#ajax` sites exist (`CampaignMessageForm`, `QuickSendForm` ×3, `CampaignPluginReferenceWidget`). All five are Form API `#ajax` *inside forms*, which is the case HTMX is worst-placed to improve — it would mean hand-rolling what the Form API already wires, and losing form-state rebuild for nothing. The plausible candidate is the Mosaico asset gallery listing on `campaign_mosaico.upload` (GET), which is a plain list render with no form state. Investigate that one; decline the other five explicitly. - **`drupal content:export` (11.3).** Real, and useful for fixtures in principle. The suite is 17 kernel tests that build entities programmatically and 6 functional tests; there is no fixture corpus for it to generate. Low value now — revisit if fixture-based tests appear. - **PHP 8.5 (11.3).** `OPT_IN_TEST_MAX_PHP: 1` is already set, so 11.3's PHP 8.5 support means the max-PHP job's ceiling moves on its own. Confirm it runs green rather than assuming it. - **Theme OOP hooks (11.3).** Not applicable — this project ships no theme. - **Experimental MySQLi driver (11.3).** Site-level configuration, nothing for a module to adopt. - **JSON Schema generation (11.2, already available).** `CampaignPluginReferenceItem` is a custom field type with no custom normalizer, so it should be getting a generated schema already. Worth confirming once; no work expected. ## Remaining tasks - [ ] Maintainer confirmation of the `^11.3` target over `^11.4` (see below). - [ ] MR: the sweep, the requirements conversion, the enum migration, the `.module` conversion. - [ ] Update the Requirements section of `README.md` and the drupal.org project page. - [ ] Confirm the previous-minor CI job installs 11.3 and the suite passes on it — the whole point of choosing this value. - [ ] Follow-up issue for a future `^11.4` floor (see below); do not fold it in here. ### Why `^11.3` and not `^11.4` Worth stating because 11.4 is current and the 11.4 feature list is the more attractive one. `^11.3` is the oldest minor with security coverage (through December 2026, when 11.5.0 ships); `^11.4` would strand sites on a still-supported minor for features this module has no present need of. The 11.4 items are genuinely out of reach at this floor and belong in a separate, later issue: - `HttpKernelUiHelperTrait` — the largest of them. Six functional tests could plausibly drop to kernel tests and skip the installer entirely, which is the single biggest CI-time lever available to this project. - Attribute routing for the `Controller` namespace, `#[Bundle]` for bundle classes, `twig/html-extra`, the `dr` CLI. ## API changes None to module APIs. The supported core range narrows from `^11.2` to `^11.3`. `hook_requirements()` implementations are replaced by `hook_runtime_requirements()` in `src/Hook/` classes, and `campaign.module`, `campaign_mosaico.module`, `campaign.install`, `campaign_emailbuilder.install` and `campaign_easy_email.install` are deleted. These are hook implementations, not public API, and nothing outside the module may call them — but any site or test invoking `campaign_requirements()` directly will break. ## Data model changes None. No schema, configuration or entity changes; `campaign_mosaico_update_10001()` is untouched. AI-Generated: Yes (Used Claude Code Opus 5 to generate the text of this issue.)