Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.In issue #3057545: ResourceTypeRepository wrongly assumes that all entity reference fields have the setting "target_type" there is a change coming that will probably affect this module. The summary as posted on the related issue:
Problem/Motivation
\Drupal\jsonapi\ResourceType\ResourceTypeRepository::getRelatableResourceTypesFromFieldDefinition() directly reads the setting target_type from the field definition, however not all reference fields have this setting. A concrete example is the dynamic_entity_reference module, which allows for referencing multiple entity types and it lacks the setting target_type. See https://git.drupalcode.org/project/dynamic_entity_reference/blob/8.x-2.x...
Proposed resolution
Define a new interface, with a method named getReferenceableBundles(FieldDefinitionInterface $definition), which is then used to retrieve the entity types and bundles being referenced by that particular item class in a single API.
This is a pathway to effectively solving #3262385: Add an API for general entity reference field types by allowing code to introspect the field item class and determine if it implements this new interface.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | 3279702-4.patch | 13.81 KB | jsacksick |
Comments
Comment #2
mglamanI think the affected repository RenamableResourceTypeRepository can be removed, actually. This capability landed in Drupal core. In 9.3.x I believe. See #3105318: Add a public API for aliasing resource type names
Comment #3
bbralaYeah it did, if that is all it does you could use the core api ^^
Comment #4
jsacksick commentedRefactored the code to no longer decorate the resource type repository, let's see if the tests are still passing :).
Comment #5
jsacksick commentedHah! What a shame, we can't actually get rid of this code for now, as we're pluralizing the resource path ("order" becomes "orders"). It seems we cannot support that with the wor that landed in core, correct?
Comment #6
jsacksick commentedSo yeah, maybe that was a poor change to make on our side, but it's too late now, we have a singular resource type name (e.g: order), and a plural resource name in the path (e.g: "orders").
Because of this, we probably have to stick with our overrides.
Comment #7
jsacksick commentedSo while we probably still need to decorage the resource type repository, we could probably still do some refactoring, and stop overridding some parent methods.