Problem/Motivation
Drupal 10.3.0 introduced a new hook_entity_query_alter() API (see change record here).
Due to the following coincidences:
- This module's name equals the name of some other module (
domain) plus the suffix_entity, - This module implements
hook_query_alter(), - Drupal *.module files are loaded globally on all requests for all enabled modules.
The function domain_entity_query_alter() is considered by core to be an implementation of hook_entity_query_alter() for the domain module. (This is in addition to being considered an implementation of hook_query_alter() for the domain_entity module, as originally intended).
The only reason this does not throw an immediate Fatal Error (at least in my case) is because, of the following coincidences:
- hook_query_alter() is covariant in its parameter type with respect to hook_entity_query_alter(). (Entity Query instances implement the same
AlterableInterfaceas DB queries do). domain_entity_query_alter()starts with quite a general check formethod_exists($query, 'getTables')(added 8 years ago) which fails in the hook_entity_query_alter() case, skipping the function.
This is something I discovered while debugging something unrelated. In my situation it doesn't break anything, but I thought I'd bring it to the attention of the module maintainers, as surely it is not the intention for this to be so, it strikes me as quite fragile?
For example: If a getTables method were added to Entity queries, or if the Domain module added its own hook_entity_query_alter() implementation, things would break horribly.
Proposed resolution
I suppose renaming the module is out of the question, but perhaps it would be a good idea to add this kind of check to the top of the function?
// Due to various coincidences this function is incorrectly interpreted, as of Drupal 10.3.0,
// as an implementation of hook_entity_query_alter(). No thanks.
if ($query instanceof \Drupal\Core\Entity\Query\QueryInterface) {
return;
}
Issue fork domain_entity-3514467
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:
Comments
Comment #2
jamsilver commentedComment #3
jamsilver commentedComment #4
jamsilver commentedComment #5
jamsilver commentedComment #6
jamsilver commentedComment #7
jamsilver commentedComment #8
jamsilver commentedComment #9
hchonovSee https://www.drupal.org/project/drupal/issues/2842858#comment-16505513 that explains what is happening here.
Comment #12
vitaliyb98 commentedComment #14
vitaliyb98 commentedI moved domain_entity_query_alter into the OOP hook in DomainEntityHook. But this will work only from Drupal 11.1+.
But if we should have backward compatibility, we should add something like this inside .module (for Drupal 10.1+):
Comment #15
vitaliyb98 commentedComment #16
vitaliyb98 commentedI decided to add support for Drupal 10.1+ by adding a legacy hook.
Also, I added phpstan.neon file to skip notice about
#[LegacyHook]and#[Hook](as example used phpstan.neon from commerce, which solves a similar problem https://git.drupalcode.org/project/commerce/-/blob/3.x/phpstan.neon?ref_...)Tested hook with Drupal 10.1 and Drupal 11.3.5
#[LegacyHook]correctly called in Drupal 10.1 and#[Hook]is skipped.And
#[Hook]correctly called in Drupal 11.3.5 and#[LegacyHook]is skippedComment #18
bohart@vitaliyb98, thanks!
Committed to 2.0.x dev branch, and this one is marked as fixed now.