🇫🇮Finland @aleksip

Happy to add you as a maintainer as I have only had time for minimal maintenance. Feel free to commit merge requests and create new releases as you see fit.

This can happen when the user has no access privileges to the record entity. In such a case the provided patch fixes the error, but the record will not contain any metadata. So I believe the access privileges check should happen earlier and if it fails the record should be left out altogether.

+1 for default config always being in English.

Another request for an official D10 release, please. Preferably a stable release covered by the Drupal Security Team. Right now a casual look on the module page can give the impression that there is only a 7.x version.

Is there a roadmap for such a release? Anything I can do to help?

Have tested #29 on Drupal 10.2.2 and can confirm that it seems to work.

I have changed the check to be based on a stored handle. In addition to being used for the check, stored handles are useful for access from other scripts.

aleksip → created an issue.

The patch works.

After some more testing it seems that the constraint validator does work with the complex IEF widget if the core patch is applied and the IEF widget's Update button is clicked before saving the parent form.

If the parent form is saved with an opened and modified complex IEF form, the validator does not get an entity with the modified values. But since modifications to the referenced entity are saved even without clicking Update, this seems to be a bug in the complex widget.

Something that is probably good to mention here as well is that the core bug is replicated in Entity Reference Revisions, so if that module is used for the reference field a similar patch should be used from https://www.drupal.org/project/entity_reference_revisions/issues/3098924 🐛 referencedEntities() causes data loss Needs review .

I came across this as well, and am able to reproduce it, and it does seem like a bug:

1. Vanilla Drupal 10.1.x install with Inline Entity Form 1.0-rc15.
2. Add field_articles entity reference field to page.
3. Add a constraint validator checking that field_tags is not empty in referenced articles.
4. Verify that validator works with core widget.
5. Set simple IEF widget and remove an existing tag in the inline form, validator does not work on save.
6. Add core patch from https://www.drupal.org/project/drupal/issues/2826717 🐛 EntityReferenceFieldItemList::referencedEntities might not return up-to-date entity objects Needs work .
7. Now simple IEF widget works.
8. Change to compex IEF widget, does not work with or without the core patch.

Other possibly related IEF issues:

• https://www.drupal.org/project/inline_entity_form/issues/2858803 ✨ Include Entity Object When Updating The Existing Entity Postponed: needs info
• https://www.drupal.org/project/inline_entity_form/issues/2830829 🐛 Entities are not updated during buildEntity() phase Needs work

Five years later I come across this again, on Drupal 10.1.4. This time it happens if I set a translated error message in my form validation code. And does not happen with an untranslated error message. And the fix in #15 does seem to work.

Considering the nature of the exception and reading all the comments it seems likely that there are different causes for the exception, probably requiring different fixes.

I also wonder about the fix in #15, since the exception message states that DependencySerializationTrait should be looked as a temporary solution.

I too would very much appreciate a stable release and notes on the differences between the major versions. The current situation makes it very hard to decide which version to use for new extensive and critical functionality.

Also came across this problem and can confirm that the merge request fixes it.

@Katarzyna_Starzynska Menu links should be displayed if you tick the 'Display non-entities' checkbox in block settings. You can also create an entity-submenu-item.html.twig template in your theme to customize the HTML.

@Mschudders committed, thanks!

Came up with the same problem and the same fix. Tested the patch in #4 and can confirm that the error no longer occurs.

I have opened a related issue for discussion: #2916453: Decide on committing to and adopting W3C Web Components standards →

We are aware of and share some of the expressed concerns about Facebook, but this is a tradeoff we are comfortable with now that React has been relicensed as MIT. Drupal have also depended on other technologies backed by enterprises, such as MySQL which is backed by Oracle. We should also remember that this doesn’t only come with downsides.

@lauriii Is this the answer to the concerns about React not adhering to Drupal's values? Or if not, do you know if there will be a more detailed answer later?