>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3589233. --> Reported by: [mably](https://www.drupal.org/user/3375160) Related to !35 >>> <h3 id="summary-problem-motivation">Problem/Motivation</h3> <p>The <code>domain_config_entity_ui</code> submodule's <code>DomainOverrideConfigEntityConverter</code> param converter is registered with <code>priority: 10</code> in <code>domain_config_entity_ui.services.yml</code>. It inherits <code>applies()</code> from core's <code>AdminPathConfigEntityConverter</code>, which returns TRUE for every <code>entity:*</code> parameter on an admin path, regardless of whether the entity type actually has domain-aware storage.</p> <p>That ties on priority with <code>views_ui</code>'s <code>ViewUIConverter</code> (also priority 10, <code>views_ui.services.yml</code>). When the Symfony route table is rebuilt, the param converter manager picks one of the two for the <code>{view}</code> parameter on routes such as <code>entity.view.edit_form</code>, <code>entity.view.edit_display_form</code>, etc. On sites where <code>domain_config_entity_ui</code> registers after <code>views_ui</code> in the container, the override converter wins. At runtime <code>convert()</code> sees that the View storage is plain <code>ConfigEntityStorage</code> (not <code>DomainAwareConfigEntityStorageInterface</code>) and defers to <code>parent::convert()</code>, which returns a bare <code>Drupal\views\Entity\View</code> with no <code>ViewUI</code> wrapping or tempstore lock metadata.</p> <p>The View edit form then crashes with:</p> <pre><pre>TypeError: Drupal\views_ui\Controller\ViewsUIController::edit():<br>&nbsp; Argument #1 ($view) must be of type Drupal\views_ui\ViewUI,<br>&nbsp; Drupal\views\Entity\View given<br>&nbsp; in core/modules/views_ui/src/Controller/ViewsUIController.php line 211</pre></pre><p>Affects every admin path that goes through Views UI on any site that has <code>domain_config_entity_ui</code> enabled.</p> <h4 id="summary-steps-reproduce">Steps to reproduce</h4> <ol> <li>Install <code>domain</code>, <code>domain_extras</code>, and enable <code>domain_config_entity_ui</code> on a Drupal 11 site.</li> <li>Visit any view edit page (admin/structure/views/view/{any_view}).</li> <li>Drupal returns the white-screen TypeError above.</li> </ol> <h3 id="summary-proposed-resolution">Proposed resolution</h3> <p>Narrow <code>DomainOverrideConfigEntityConverter::applies()</code> to only the routes the converter actually handles, i.e. ones whose entity type has a <code>DomainAwareConfigEntityStorageInterface</code> storage. Routes for everything else fall through to the rest of the chain (notably <code>ViewUIConverter</code> for view edit routes), unchanged.</p> <pre><pre>public function applies($definition, $name, Route $route) {<br>&nbsp; if (!parent::applies($definition, $name, $route)) {<br>&nbsp;&nbsp;&nbsp; return FALSE;<br>&nbsp; }<br>&nbsp; // Decline routes whose entity type is dynamic (entity:{entity_type})<br>&nbsp; // since we cannot resolve the storage class here.<br>&nbsp; $type_slug = substr($definition['type'], strlen('entity:'));<br>&nbsp; if (str_starts_with($type_slug, '{')) {<br>&nbsp;&nbsp;&nbsp; return FALSE;<br>&nbsp; }<br>&nbsp; if (!$this-&gt;entityTypeManager-&gt;hasDefinition($type_slug)) {<br>&nbsp;&nbsp;&nbsp; return FALSE;<br>&nbsp; }<br>&nbsp; $entity_type = $this-&gt;entityTypeManager-&gt;getDefinition($type_slug);<br>&nbsp; if (!$entity_type instanceof ConfigEntityTypeInterface) {<br>&nbsp;&nbsp;&nbsp; return FALSE;<br>&nbsp; }<br>&nbsp; return $this-&gt;entityTypeManager-&gt;getStorage($type_slug)<br>&nbsp;&nbsp;&nbsp; instanceof DomainAwareConfigEntityStorageInterface;<br>}</pre></pre><p>Verified locally: route inspection now shows <code>converter: drupal.proxy_original_service.paramconverter.views_ui</code> for <code>entity.view.edit_form</code>, and a programmatic run of the converter chain on <code>view: text_xls_export</code> returns a <code>Drupal\views_ui\ViewUI</code> as expected. View edit pages render again.</p> <h3 id="summary-remaining-tasks">Remaining tasks</h3> <ul> <li>Review the MR.</li> <li>Ship in 3.x.</li> </ul> <h3 id="summary-test-coverage">Test coverage</h3> <p>The submodule's existing kernel test (<code>DomainOverrideConfigEntityConverterTest</code>) does not exercise <code>applies()</code>. The MR can either be left as-is or extended with an <code>applies()</code> test that asserts FALSE for an entity type with non-domain-aware storage; happy to do that as a follow-up.</p>