In domain/domain_access/domain_access.module method "domain_access_entity_prepare_form" it will only add current domain if operation is "default" (line 847)
If you create a new form mode for a content entity, like node, adding current domain will never be possible.
- Install Drupal 11.4.11
- Install domain 2.0.1 or 2.0.x
- Activate domain_access.
- Setup domains
- Add content type
- In /admin/structure/display-modes/form create a new form mode for that type.
- By code in controller or block invoke and return the form with the custom form mode
return Node::create(["type" => "page"])->getEntityType()->setFormClass('custom_form_mode', 'Drupal\node\Form\NodeForm');
- Observe that operation is "custom_form_mode" and that the "add current domain" segment of hook domain_access_entity_prepare_form is skipped.
Drop the form operation condition. A new entity now gets the current domain whatever the form operation: default, register, the add operation core uses for entity types that declare an add form handler (such as Media and Block content), a custom form mode, or a form a contrib module builds itself. The $entity->isNew() check stays, so an existing entity keeps its domains in every form.
On 2.0.x the check was default only, because the register fix of #3564574: Add current domain option doesn't work when creating a new user never reached that branch. So this also makes "Add current domain" work on the user registration form there.
Merge requests, each with a kernel test, DomainAccessFormModeDefaultValueTest: 4.x, 3.x, 3.0.x and 2.0.x.
None. The reporter tested the 2.0.x branch on the site where the bug was found and confirmed the current domain is now added.
None.
None. Behavior change: when "Add current domain to default values" is enabled on a field_domain_access field, a new entity now gets the current domain in every entity form, not only in the default form (and the registration form). As on the default form before, this also happens when the field is hidden in the form display.
None.
AI-Generated: Yes (Claude Code was used to help draft this issue summary and to write the fix and its test. I reviewed both, and the test was confirmed to fail without the fix and to pass with it.)
Show commandsStart 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:
changes, plain diff MR !503changes, plain diff MR !505changes, plain diff MR !504changes, plain diff MR !506
Comments
Comment #7
mably commentedConfirmed.
hook_entity_prepare_formonly adds the current domain when the form operation isdefault(2.0.x) ordefault/register(3.0.x, 3.x, 4.x). Besides custom form modes like the one in the summary, this also skips theaddoperation that core uses for the add form of entity types declaring anaddform handler, such as Media and Block content, and the forms contrib modules build themselves. On 2.0.x it also skips the user registration form, because the fix of #3564574 never reached that branch.The operation check came with the first patch of #2909853, when the field's default value callback, which ran for every new entity, was moved to
hook_entity_prepare_form. Nothing in that issue explains it, and$entity->isNew()already keeps edit and delete forms out. So, as proposed in the summary, the merge requests drop the operation check and keepisNew():Each adds a kernel test that builds the node form through a
customform mode: a new node gets the current domain, and an existing node keeps its domains. The 2.0.x one also checks the user registration form. The "test-only changes" job fails on all four without the fix, and every other job is green, including the previous and next major lanes.Behavior change: with "Add current domain to default values" on, new entities now get the current domain in every entity form. As on the default form already, hiding the field in a form display does not stop this. A site that wants no current domain in one form mode can turn the setting off for that bundle, or reset the field in its own
hook_entity_prepare_form().AI-Generated: Yes (Claude Code was used to help analyse the issue, write the fix, the tests and this comment. I reviewed them, and the new tests were confirmed to fail without the change and to pass with it.)
Comment #8
mably commentedThanks flemming.fridthjof for the report and the clear steps to reproduce. Could you review merge request 506 (2.0.x), or the one for the branch you use, with your custom form mode, and confirm that the current domain is now added?
AI-Generated: Yes (Claude Code was used to help draft this comment.)
Comment #9
flemming.fridthjof commentedI've just tested git@git.drupal.org:issue/domain-3633250.git branch 3633250-domainaccessentityprepareform-only-applies-2.0.x on my site, which the bug was identified on, and it now works as expected.
field_domain_access_target_id in node__field_domain_access was supplied on the newly created node.
Great work.
Comment #10
mably commentedThanks @flemming.fridthjof for the feeback, let's merge this!
Comment #11
mably commentedComment #16
mably commented