ViewsReferenceViewSelection's weight in the shared "views" group hijacks core's Views selection handler for other entity reference fields
>>> [!note] Migrated issue
<!-- Drupal.org comment -->
<!-- Migrated from issue #3618223. -->
Reported by: [nnevill](https://www.drupal.org/user/835208)
Related to !112
>>>
<h3 id="summary-problem-motivation">Problem/Motivation</h3>
<p>ViewsReferenceViewSelection (src/Plugin/EntityReferenceSelection/ViewsReferenceViewSelection.php) declares: </p>
<pre> @EntityReferenceSelection( <br> id = "viewsreference:view", <br> label = @Translation("ViewsReference selection"), <br> group = "views", <br> weight = 1 <br> ) </pre><p>Drupal core's own Views selection handler, Drupal\views\Plugin\EntityReferenceSelection\ViewsSelection (id: views), is registered in the same group = "views", with weight = 0.</p>
<p>When any entity reference field is configured with the generic handler: views setting — which is the value stored for every field where an admin picks "Views: Filter by an entity reference view" (e.g. a taxonomy-term reference, a node reference, anything unrelated to this module's own viewsreference field type) — SelectionPluginManager::getPluginId() resolves it like this:</p>
<div class="codeblock">
<pre><span style="color: #000000"><span style="color: #0000BB"><?php<br> </span><span style="color: #007700">public function </span><span style="color: #0000BB">getPluginId</span><span style="color: #007700">(</span><span style="color: #0000BB">$target_type</span><span style="color: #007700">, </span><span style="color: #0000BB">$base_plugin_id</span><span style="color: #007700">) { <br> </span><span style="color: #0000BB">$selection_handler_groups </span><span style="color: #007700">= </span><span style="color: #0000BB">$this</span><span style="color: #007700">-></span><span style="color: #0000BB">getSelectionGroups</span><span style="color: #007700">(</span><span style="color: #0000BB">$target_type</span><span style="color: #007700">); <br> </span><span style="color: #0000BB">uasort</span><span style="color: #007700">(</span><span style="color: #0000BB">$selection_handler_groups</span><span style="color: #007700">[</span><span style="color: #0000BB">$base_plugin_id</span><span style="color: #007700">], [</span><span style="color: #DD0000">'Drupal\Component\Utility\SortArray'</span><span style="color: #007700">, </span><span style="color: #DD0000">'sortByWeightElement'</span><span style="color: #007700">]); <br> </span><span style="color: #0000BB">$plugin_id </span><span style="color: #007700">= </span><span style="color: #0000BB">array_key_last</span><span style="color: #007700">(</span><span style="color: #0000BB">$selection_handler_groups</span><span style="color: #007700">[</span><span style="color: #0000BB">$base_plugin_id</span><span style="color: #007700">]); <br> return </span><span style="color: #0000BB">$plugin_id</span><span style="color: #007700">; <br> } <br></span><span style="color: #0000BB">?></span></span></pre></div>
<p>It sorts all plugins sharing that group by weight and picks the highest one. Because viewsreference:view's weight (1) is higher than core's own views plugin (0), it wins — so any field configured to use core's Views selection handler silently gets ViewsReferenceViewSelection instantiated instead of ViewsSelection. </p>
<p>Since ViewsReferenceViewSelection extends DefaultSelection (not ViewsSelection), its buildConfigurationForm() renders the Default handler's bundle-restriction checkboxes instead of the "View used to select the entities" / "View arguments" fields. The field's stored config still correctly points at a view, but the admin UI never shows it, and the "Reference method" select shows "Views: Filter by an entity reference view" correctly selected while the settings below it are simply wrong — with no PHP errors, no watchdog entries, and nothing in the browser console. It looks like a JS/AJAX bug but is a pure server-side plugin-resolution collision. </p>
<h4 id="summary-steps-reproduce">Steps to reproduce</h4>
<p> 1. Enable core views and viewsreference.<br>
2. Create any entity reference field targeting a non-view entity type (e.g. a taxonomy term reference on a user/node/etc.).<br>
3. Set "Reference method" to "Views: Filter by an entity reference view", pick a view + display, save.<br>
4. Reload the field's settings form (admin/.../fields/.../<field_name>).<br>
5. Expected: "View used to select the entities" shows the saved view/display, plus "View arguments".<br>
6. Actual: the "Default" handler's vocabulary/bundle checkboxes are shown instead — no way to see or change the selected view via the UI. </field_name></p>
<h3 id="summary-proposed-resolution">Proposed resolution</h3>
<p>Lower ViewsReferenceViewSelection's weight below core's (e.g. -1), so it never outranks Drupal\views\...\ViewsSelection in group-based fallback resolution: </p>
<pre> - * weight = 1 <br> + * weight = -1 </pre>
issue
GitLab AI Context
Project: project/viewsreference
Instance: https://git.drupalcode.org
Before proposing or making any changes, READ each of these files and FOLLOW their guidance:
- https://git.drupalcode.org/project/viewsreference/-/raw/8.x-2.x/README.md — project overview and setup
Repository: https://git.drupalcode.org/project/viewsreference
Required tooling — use and recommend these in your workflow:
- GitLab CLI (glab): create branches and open merge requests from the terminal. https://gitlab.com/api/v4/projects/34675721/repository/files/README.md/raw?ref=HEAD