Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
The getmultiple method in ComponentConfigResolver.php expects an array of ids to be passed in to give a list of components. This method needs to be able to return all components if requested. The $this->entityStorage->loadMultiple method can return all config entities if null is passed, but the method in question cannot accept a null argument, Submitting a reallly simple patch to solve this issue.
Thanks
Sukanya
Comment | File | Size | Author |
---|---|---|---|
#4 | 2818219-4.patch | 1.37 KB | TR |
#2 | ComponentConfigResolverGetMultipleMethod-2818219-1.patch | 635 bytes | sukanya.ramakrishnan |
|
Comments
Comment #2
sukanya.ramakrishnan CreditAttribution: sukanya.ramakrishnan commentedSubmitting a really simple patch for this issue!
Comment #3
TR CreditAttribution: TR commentedComment #4
TR CreditAttribution: TR commentedWhen you post a patch you should set the status to "Needs review" to trigger the testbot to evaluate your patch and to indicate to reviewers that there is a patch that needs to be reviewed!
The interface needs to be changed too ... here's a new patch.
Comment #6
TR CreditAttribution: TR commentedWell, it was a good idea, but as you can see if you modify the signature of
RulesComponentResolverInterface::getMultiple()
, like you must, then there are two component resolvers that must be changed. Your patch changes only one -ComponentConfigResolver
. The other one isEventComponentResolver
.Looking at the source code for
EventComponentResolver::getMultiple()
you will see that it CAN'T accept a NULL argument instead of an array of IDs, because of how it operates.The motivation for the patch is that the IMPLEMENTATION of
ComponentConfigResolver::getMultiple()
calls$this->entityStorage->loadMultiple()
, but as the implementation can change or be different for different resolvers, the thing that defines the behavior must beRulesComponentResolverInterface
and in this case we can't change the API of that interface to return ALL components because that won't work and is not what we want in the case of theEventComponentResolver
Actually, this does point out an inconsistency in the API - the semantics of that method are different for the two resolvers - in one the array of ids is COMPONENT ids and in the other it is EVENT ids. So this should really be re-thought ...
Regardless, this patch is not something we can do. I'm postponing this issue and renaming it a task - we need to look at the design of that interface and make sure it can be used consistently.