Problem/Motivation
Commit 3a355372, the fix for #3169627: [regression] Flag form element also appearing on non-edit forms, shipped in 5.1.0. Since then, entity forms rendered with any custom form mode no longer show the flag checkboxes. That includes every site using Form Mode Manager. There is no error and no release note, so editors simply lose the ability to set flags.
Before that commit, the early-return check in the form alter never ran: getAllFlags() is keyed by flag ID, so isset($flags[0]) was always false. As a result, flags appeared on every content entity form, and they had done so since 8.x-4.x. Sites built editorial workflows on that behavior, intended or not.
The commit made the check run, and EntityFlagType::isAddEditForm() only accepts default and edit:
return in_array($operation, ['default', 'edit']);
For a custom form mode the operation is the form mode ID (e.g. news), so the flags element is never added.
The fix for #3169627: [regression] Flag form element also appearing on non-edit forms solved a narrow problem: flags showing on Scheduled Transitions forms. To do that it introduced a much broader regression that removes a core editorial feature from any site using custom form modes.
Steps to reproduce
- Install Flag 5.1.0 and Form Mode Manager 3.1.0, or define any custom node form mode.
- Create a node flag with "Display checkbox on entity edit form" enabled.
- Edit a node using the custom form mode.
- Expected (5.0.3): the Flags details element appears.
Actual (5.1.0): no flags. The coreeditform still shows them.
Proposed resolution
Revert 3a355372 in the next 5.1.x patch release to restore the behavior sites have relied on for years. Then reopen #3169627: [regression] Flag form element also appearing on non-edit forms and solve it in a way that doesn't exclude form modes. For example, treat any operation that matches a configured form mode as an edit form:
$operation = $object->getOperation();
$form_modes = $this->entityDisplayRepository->getFormModes($entity->getEntityTypeId());
if (!$flag_type->isAddEditForm($operation) && !isset($form_modes[$operation])) {
return;
}
Scheduled Transitions' operation isn't a form mode, so it would still be excluded. Alternatively, add a per-flag setting for which form modes show the checkbox.
Note: the code moved from flag.module to src/Hook/FlagHooks.php in 5.1.0, so the revert has to be done by hand. git revert of the original commit won't apply. In practice, "revert" means removing the isAddEditForm() early return from FlagHooks::formAlter().
Remaining tasks
- Revert in 5.1.x and tag a patch release
- Reopen #3169627: [regression] Flag form element also appearing on non-edit forms with a form-mode-aware approach plus tests
- Add a release note for affected 5.1.0 users
User interface changes
None.
API changes
None for the revert. The form-mode-aware follow-up would add an entity_display.repository dependency to FlagHooks. A per-flag setting would add a new option to the entity flag type plugin configuration.
Data model changes
None for the revert. A per-flag form mode setting would need a config schema addition and an update hook to set defaults for existing flags.
Issue fork flag-3628977
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #3
trackleft2I've added a merge request that could be treated as a bugfix and would not require a revert of the previous fix. Thank you for your review.
Comment #6
ivnishThanks!
I tagged a new release https://www.drupal.org/project/flag/releases/5.1.1
It includes a revert of #3169627: [regression] Flag form element also appearing on non-edit forms.
I missed your MR but now it also merged.
Comment #8
trackleft2Thank you so much!!!