>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3277210. --> Reported by: [charginghawk](https://www.drupal.org/user/2626341) Related to !5 >>> <h3 id="summary-problem-motivation">Problem/Motivation</h3> <p>In its middleware, shield is invoking hooks before modules have been loaded, corrupting the module_implements cache. There's at least one instance of this, but there may be others. The known instance has to do with Shield using entity_type.manager in its middleware:</p> <p><a href="https://git.drupalcode.org/project/shield/-/blob/8.x-1.x/src/ShieldMiddleware.php#L188-199">https://git.drupalcode.org/project/shield/-/blob/8.x-1.x/src/ShieldMiddleware.php#L188-199</a></p> <p>Per <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-13"><a href="https://www.drupal.org/project/drupal/issues/3207813" title="Status: Needs work">#3207813: ModuleHandler skips all hook implementations when invoked before the module files have been loaded</a></span>:</p> <blockquote><p>A more concrete example is a middleware service using the entity_type.manager. Most of the times the entity type information is retrieved from cache (stored in the discovery cache bin). When this cache however is missing, hooks like hook_entity_type_build() and hook_entity_type_alter() need to be invoked at this early stage. The modules files however haven't been loaded yet, making ModuleHanlder::verifyImplementations() skip all the hook implementations (silently!). The entity definition cache is then incomplete resulting in various hard to debug (next to impossible) exceptions like <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-5"><a href="https://www.drupal.org/project/paragraphs/issues/3031598" title="Status: Closed (won't fix)">#3031598: The "paragraph" entity type did not specify a translation handler. </a></span>.</p></blockquote> <p>"The "paragraph" entity type did not specify a translation handler." is a common error associated with this issue that can be a critical issue for some.</p> <h4 id="summary-steps-reproduce">Steps to reproduce</h4> <p>TBD</p> <p>There are steps for a <a href="https://www.drupal.org/project/paragraphs/issues/3031598#comment-13972961">similar issue with access_filter</a>. Could probably tweak them to use shield, paragraphs, key, and content_translation modules (with shield configured to use key for authentication, since that's where entity manager is used). Can't confirm right now due to simplytest.me issues.</p> <h3 id="summary-proposed-resolution">Proposed resolution</h3> <p>The most direct solution is to appropriate the <a href="https://www.drupal.org/files/issues/2022-01-20/3207813-8.patch">#3207813 patch</a> and insert <a href="https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Extension%21ModuleHandler.php/function/ModuleHandler%3A%3AloadAll/8.2.x">ModuleHandler::loadAll</a> somewhere in Shield's middleware.</p> <p>Per <a href="https://www.drupal.org/project/drupal/issues/3207813#comment-14431888">catch's comment here</a>:</p> <blockquote><p>The short answer is that middlewares shouldn't be invoking hooks, there might be a later kernel event listener that would allow you to achieve the same thing.</p></blockquote> <p>But that's probably a bigger refactor.</p> <h3 id="summary-remaining-tasks">Remaining tasks</h3> <p>Steps to reproduce, patch, test</p> <h3 id="summary-ui-changes">User interface changes</h3> <p>N/A</p> <h3 id="summary-api-changes">API changes</h3> <p>N/A</p> <h3 id="summary-data-model-changes">Data model changes</h3> <p>N/A</p> > Related issue: [Issue #3031598](https://www.drupal.org/node/3031598) > Related issue: [Issue #3207813](https://www.drupal.org/node/3207813) > Related issue: [Issue #1905334](https://www.drupal.org/node/1905334)