Mastering machine names inside your views

Drupal views providers an advanced UI, but sometimes the auto-generated machine names within your views are not ideal. There are ways to improve this.

This site is under development and this article is not complete.

I have been creating some content for the new website and thinking about random tips that I have never found time to share.

When you create a view there are a few areas where I like to control generated "machine name" values that will lead to cleaner output in the long run.

I wouldn't do this after a site is built, it's too risky to overlook other things that depend on these machine names. I would only use these techniques when I initially create the view.

The view itself

It's common to find that your view wasn't named well, and you're unhappy with the name of the twig file to override.

The easiest way to fix this is to clone the view and customise the machine as you do it, then delete the old view. This is completely safe as views YAML is usually self-contained.

As said above, you usually do this when you are building the view and you realise you gave it a bad name. After a while there are other parts of your site which will be couple to this name, and easy to miss. If you clone a view and change the machine name you will break the following and plenty of other things:

  • Entity reference fields (when you configure the options list) can use a View.
  • Your layouts builder page, where you have embedded a Views block.
  • Your block layout, where you have added a Views block.
  • Twig templates reference the Views machine name
  • Custom code can programmatically load and render a view.
  • Probably a dozen more if you count your contrib module. 

Display names

Below we have a view with multiple displays and they have been neatly named. If you want to control the twig for this view, you can add a template views-view--VIEWNAME--DISPLAYNAME.html.twig. After a site has been built it's common to see templates like this:

[PICTURE]

views-view--mycontentview--page-1.html.twig
views-view--mycontentview--page-2.html.twig
views-view--mycontentview--page-3.html.twig

For another developer looking at this code, and trawling through dozens of templates, it's not immediately clear what these views are being used for. This is a DX issue for you and your colleagues. The effort to change this later may not be worth it.

Get into the habit of setting your display machine names as soon as you create them. You will appreciate the resulting systax for creating your twig templates.

[PICTURE]

views-view--mycontentview--all.html.twig
views-view--mycontentview--articles.html.twig
views-view--mycontentview--newest-articles.html.twig

Renaming fields

When adding fields, it's common to add the same field twice, you might render a field in different ways or hide one of the fields and use it in a field rewrite later.

The views UI does not allow you to rename the field's machine name. However there is a technique I've been using for a while that works very well. It will allow you to have well named twig tokens. It invokes hacking the views yaml and reimporting it.

Let's say we want to re-use a uid (User ID) field, hide it and, reuse it in a field rewrite in another field.

  1. Create your view, and add your fields.
  2. Create a second UID field.
  3. Add a "Global: custom text" field
  4. In the rewrite of this field, you will note that to express this field you will enter {{ uid_2 }} - How can we change this.
  5. Export your site config with Drush, open the new view yaml, and find and replace the instances of uid_2 with you_say_tomatoe
  6. Reimport your site config

Now in your view you can use {{ you_say_tomatoe }} in your rewriting.

Disclaimer #1: I've been told that I hack yaml too much. I like to explore the boundaries of Drupal's config system, it's a masterpiece. However, I'm also aware that I will get no love in the issue queue if I hose my site. That said, I have been using this technique with Views since Drupal 8 and it has never failed me.

Disclaimers #2: I only do fancy twig re-writing in administration views in the backend, especially when I'm using a vanilla uncustomised backend theme. It's a great smart way to make backend tables more user-friendly. On the frontend, you should bring this complexity into the theme layer and keep your views nice and sane.

[VIDEO]