[PP-1] Use hook_theme_suggestions in views

Just a quick question on this, I couldn't find a more appropriate issue. I wondered why ViewExecutable::buildThemeFunctions prefers (or even involves) the display_id as first argument over the view id.

$themes[] = $hook . '__' . $display['id'];
...
$themes[] = $hook . '__' . $id;

Is this intended? For me this looks a little bit like gambling, to even involve display_id as first argument. I stumbled on this after using a "views-view--something.html.twig" and wondered why the display of a view matched another html.twig, because its display id matched it, which I never expected...

Hi,

So @captain hindsight , do it be necessary to patch to get views template suggestions with display id or just adding code into .theme file ? Something like:
$suggestions[] = 'views_view__' . $variables['view']->id(). '__' . $display['id'];

#83 it's working fine for me. Thanks !

I am currently upgrading a project to Drupal 10 and so I have re-rolled #84 for D10.

The patch (2923634-92.patch) is identical as #84, except for removal of the changes to /core/modules/aggregator/src/Plugin/views/row/Rss.php, due to the removal of the aggregator module from core. I have not created an interdiff as the first patch no longer applies on D10.

I hope this assists if you are currently upgrading to D10. As the issue is postponed I have not created a patch against D11.

@tcrawford, thanks for the D10 patch.
#92 patch cleanly applied Drupal 10.1.1.

With the patch in #70 against 9.x I got this for example for an exposed views block:

<!-- THEME HOOK: 'form' -->
<!-- FILE NAME SUGGESTIONS:
   * form--audio-series-listing--block-1.html.twig
   * form--block-1.html.twig
   x form--audio-series-listing--block.html.twig
   * form--block.html.twig
   * form--audio-series-listing.html.twig
   * form.html.twig
   * form.html.twig
-->

With the latest patches here against 10.x I only get

<!-- THEME DEBUG -->
<!-- THEME HOOK: 'form' -->
<!-- BEGIN OUTPUT from 'themes/contrib/stable/templates/form/form.html.twig' -->

Going back to #83 against 10.x brings back the theme suggestions (form---VIEW_ID--DISPLAY_ID.html.twig,..) (though it doesn't apply cleanly due to the patch for core/modules/aggregator/src/Plugin/views/row/Rss.php)

Something went missing in #92

Re-rolled patch from #83 to apply cleanly against 10.1.x

I did not dig in to this much, but just noting that during an recent upgrade to 10.1 (from 9.5) this patch was breaking suggestions for views - existing template overrides (e.g. views-view-list--[machine_name]) were not being used. Removing the patch resolved for me.

This doesn't work quite right for Drupal 10.

Example:

1. We have one content type that is displayed in 2 views with the same view mode.
2. The views are placed on different pages.
3. Create templates for the content from these views.
4. Open page 1 and we have the expected result.
5. Open page 2 and the content that has already been displayed on page 1 is displayed with the template for the first view.

@ben.hamelin Have you tested wit the re-rolled patch from #96? I did that re-roll because previous patches were broken after upgrading to 10.1

#92 works for me (Drupal 10.1.5), thanks.

The patch applies with som difficulties against 10.2.2, but I don't get file name suggestions for Views table:

<!-- THEME DEBUG -->
<!-- THEME HOOK: 'views_view_table' -->
<!-- BEGIN OUTPUT from 'core/themes/olivero/templates/views/views-view-table.html.twig' -->
<table class="views-table cols-1">

Applying the patch:

$ patch -p1                < 4947.diff 
patching file core/modules/comment/src/Plugin/views/row/Rss.php
patching file core/modules/node/src/Plugin/views/row/Rss.php
patching file core/modules/search/src/Plugin/views/row/SearchRow.php
patching file core/modules/views/src/Form/ViewsExposedForm.php
Hunk #1 succeeded at 136 (offset -8 lines).   <<<<<< A few of these, as well as "succeeded at 63 with fuzz 1"
[...]

It seems that the status was changed by mistake so I'm putting it back to "needs work"

carlos romero → made their first commit to this issue’s fork.

Looks like the MR is out of date with upstream changes. Can the branch be rebased? Is this something I can help with? I don't seem to have commit access to the branch. Not quite sure how this works in terms of committing to someone else's branch? Happy to jump in and work on this! Also looks like the pipeline failed which needs looking in to.

@darren.fisher You can rebase an MR by giving yourself push access by clicking on the button and then clicking on "MR xyz mergeable" and adding a comment "/rebase" (the slash is important). In this case, I did it for you, just to make sure these instructions are correct. These branches are a community effort so everyone is welcome to rebase and rework code (assuming no one else is currently working on it). If you're unsure of your changes, it's totally acceptable to clone the branch and create a new branch based on it and upload that as well. Just mark any MRs as a "draft" if they are not ready, and leave a comment stating what work remains to do.

@darren.fisher, if you click the button get push access at the top you should be able to then contribute.

Drupal is generally very collaborative, rebasing an MR is almost always acceptable, if it's a particularly active issue you might want to assign it to yourself so others don't do it at the same time. Also follow the instructions here: https://www.drupal.org/docs/develop/git/using-gitlab-to-contribute-to-dr... → particularly the force with lease option to ensure you're not overriding someone elses work.

Also contributing to respond to feedback is accepted, just ensure no one else is cross posting so it's best to usually leave a comment.

If you are going to change directions from the current MR I would either comment about the approach or create a new branch on the fork to demonstrate your approach for discussion.

Also looks like someone is already updating the 10.3 branch, I don't know about the other one.

This is really helpful. Thanks. I don't know how I missed the giant green button that says "Get push access". I think I was looking in GitLab itself!! I really appreciate the pointers and now I know!