The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.Problem/Motivation
Error: Call to a member function addCacheableDependencies() on null in Drupal\registration\Form\RegisterForm->addCacheableDependencies() (line 598 of /code/web/modules/composer/registration/src/Form/RegisterForm.php)
Displayed when viewing a Node with registrations enabled from a view displayed in a layout_builder layout. Context is lost, and so the addCacheableDependencies() gets an error.
Steps to reproduce
1. Create a node type and enable registration. Then create a node with the registration.
2. Create a Teaser display mode for that node type, where the registration form is set as disabled from view.
3. Create a view that displays that node type rendered with that teaser display.
4. On another entity/node type (in my case a Taxonomy term), enable layout builder for the default display and place the view on it as a block.
5. View the Taxonomy term page.
Proposed resolution
Update the addCacheableDependencies to check to make sure that host_entity is available, prior to trying to add a cacheable dependency to it.
Remaining tasks
- Create patch, and submit it to this issue.
- Community review or alternative suggestions.
User interface changes
API changes
Data model changes
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | 3401297-addCacheableDependency.patch | 670 bytes | cmcintosh |
Issue fork registration-3401297
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:
changes
Comments
Comment #2
cmcintosh commentedAttaching patch for now.
Comment #3
john.oltman commentedThanks for the post @cmcintosh! Patch looks good, I want to reproduce this locally, will get back later this week. Would like to include a test with the fix, so may open an MR eventually, tbd.
Comment #4
john.oltman commentedThe problem is deeper - but I could only reproduce it by having the Registration field enabled for the teaser display. If you disable it, it will never call RegisterForm, because it never needs to render. So I think you probably meant to say that the field was enabled, with Registration form being the chosen Format for the field in that view mode.
I'll have a MR posted soon.
Comment #5
john.oltman commentedComment #8
cmcintosh commentedI have seen it in both cases, additionally this is just a part of a bigger issue I think with how the form is working.
in setHostEntity(FormStateInterface $form_state), we are first checking if $form_state already has a host entity, if not we fall back to using routeMatch paramaters, which will fail in this situation: $this->getRouteMatch()->getParameters().
I think the more/better solution would be to add a third parameter onto the form method, that takes a \Drupal\Core\Entity\ContentEntityInterface object. Then in the Field Formatter, pass in the host entity when calling the form to be rendered. This would ensure that the host entity is always present.
Comment #9
john.oltman commentedThanks - you may have missed that I had already committed a fix roughly along the lines of what you are proposing. A third argument is not needed since the form state can be initialized with the host entity. I kept the setHostEntity function but only as a fallback for other callers. This is committed to the dev branch and will be in the next release.
Comment #10
cmcintosh commentedHey John, yes I saw that the patch was accepted. Thanks for that. I overlooked that function was accessible, so that should handle other cases. Thanks again.
Comment #11
john.oltman commentedNo problem. To clarify, although it was much appreciated, I did not use the patch since it was covering up the root cause. This is what I ended up doing which is basically your proposal to add the host entity to the form via the field formatter. https://git.drupalcode.org/project/registration/-/commit/147b90a39279e67...
Comment #12
john.oltman commented