## Summary Follow-up to: #3586589+s (reported by @tazo_vekua in the rc1 QA) Uninstalling Dynamic Entity Reference (DER) deletes the Specific Entities value of every context item, also in old revisions. Installing DER again does not bring the values back. The uninstall confirmation page shows only the generic Drupal warning. This has two effects: * **Data loss.** The values must be entered again by hand. * **Wider delivery.** An item that was limited to specific entities is no longer limited: `AiContextScopeEntityItem::matchesRequestContext()` returns NULL when the field is missing or empty, so the item matches everywhere. This is the same risk as #3586603, but that issue covers a deleted target entity, not the removal of the whole field. `docs/features/scopes.md` (Specific Entities) says that without DER "stored values are kept rather than deleted. Installing the module makes it available without re-saving items." This is not true. Cause: `entity_items` is a base field whose provider is `dynamic_entity_reference` (`DynamicEntityReferenceHooks::entityBaseFieldInfo()`), so core removes its storage when DER is uninstalled. Seen on 1.0.0-rc1 (`8a57807`), Drupal 11.4.9, DER 3.2.3. ## Steps to reproduce 1. Make sure DER is enabled and at least one content item exists, for example the article "Sample article". 2. Add a context item. Under Context Scope > Specific Entities, set Type to Content and choose "Sample article". Save. 3. Open the item. The Details panel shows "Specific entities: Sample article". 4. Uninstall DER. 5. Install DER again. 6. Open the item, its edit form and its Revisions page. ## Expected result Uninstalling DER is blocked while context items use Specific Entities, or the values are back after step 5. ## Actual result Step 4 succeeds with only the generic warning. After step 5, the Specific Entities value is empty on the item page, in the edit form and in all revisions. ## Proposed resolution 1. [x] Add a module uninstall validator that blocks the DER uninstall while a context item has Specific Entities values on its default revision or on a pending draft. A pending draft of any translation counts, even when another translation has a newer revision. The reason names up to 5 items, for example: "The Specific Entities scope of 3 context items uses Dynamic Entity Reference. Remove their values before you uninstall Dynamic Entity Reference. Affected items: Article guidance (12), Editorial rules (18), Site voice (24)." Drush and config import also run uninstall validators. 2. [x] If the values cannot be checked, block the uninstall and log the error. The guard exists to prevent data loss, so it must not let the uninstall through. 3. [x] Old revisions do not block the uninstall. In `hook_module_preuninstall()` for `dynamic_entity_reference`, capture a note for each old revision that has values: the entities it referenced (type, ID and label), and that the values were removed because Dynamic Entity Reference was uninstalled. Keep the capture in State. 4. [x] Write the notes to the revision logs only in `hook_modules_uninstalled()`, which core calls only after a successful uninstall. A failed uninstall must not leave notes that say the values were removed. The write also runs during config sync. 5. [x] Update only the revision log message, with a direct database update: saving old revisions through the entity API runs presave hooks (scope cleanup, moderation). Reset the entity storage cache and invalidate the item cache tags afterwards. Show line breaks in the log on the Revisions page. 6. [x] If the write fails after DER is gone, catch and log the error, keep the confirmed notes in State, and let the other uninstall hooks run. Cron retries confirmed notes. A later DER uninstall writes them before it captures new ones, and stops if that fails. An unconfirmed capture is never written. Uninstalling `ai_context` deletes both State keys. 7. [x] Support the legacy field name `target_entities` on sites that predate `ai_context_update_10018()`. 8. [x] Docs: correct the Specific Entities section of `docs/features/scopes.md`, and update `revisions.md`, `services.md`, `hooks.md` and `api-stability.md`. 9. [x] Kernel tests, including a real `module_installer->uninstall()` and a config sync uninstall. 10. [x] Release note. 11. [x] Return the block reasons as `TranslatableMarkup`, as core's `ContentUninstallValidator` does. A string is escaped again by `{{ reason }}` in core's uninstall template, so labels showed as `Tips & tricks`. 12. [x] If the items cannot be loaded, list their IDs in the reason instead of calling `label()` on a missing item. 13. [x] Test that uninstalling `ai_context` deletes both State keys. ## Questions 1. [x] Should old revisions with values also block the uninstall? No. Only default revisions and pending drafts block it, and old revisions get a note in their revision log message (item 3). 2. [x] Should the note include labels of entities the user cannot view? Yes. The label is needed to find the entity and enter the value again, and only users with **View all AI Context Item revisions** can read the log. This is documented in `scopes.md`. 3. [x] Should CCC restore the values when DER is installed again? No. This issue blocks the uninstall and records the values; it does not restore them. ## Release note Uninstalling Dynamic Entity Reference is now blocked while a context item uses Specific Entities on its current revision or a pending draft. Old revisions get a revision log note that lists the entities they referenced, so the values can be entered again by hand. ## Related issues * #3586589+s * #3586603+s ## Stakeholders * @kepol: maintainer (reviews and merges) * @tazo_vekua: reporter > [!note] > Check the one that best describes your usage, or leave all unchecked if AI was not significantly used. > > * [ ] AI **Assisted Issue** \ > _Mainly written by a human; AI used for partial generation under full human supervision._ > > * [x] AI **Generated Issue** \ > _Mainly generated by AI, reviewed and approved by a human before this issue was created._