Working with Drupal views

As a Drupal site administrator, you may notice in the website logs that there might be a large number of repeated log messages along the lines of "An illegal choice has been detected. Please contact the site administrator." We recently had this problem on a Drupal site that was upgraded from Drupal 7 to Drupal 9 which featured a product search that was built using Views.

Due to slight differences in the way in which the view and facets were built in the Drupal 9 site, this resulted in slightly different URLs being used when the user would filter the...

I'm a fan of configuring things for display through Drupal's admin UI. It gives site builders confidence and power. What if you want to place blocks or views listings in amongst fields on pages of content? For example, to display:

• A listing (view) of related content, such as accessories for a product
• A standard contact block, advert, or some other calls to action in the middle of the content, exactly where the user is best 'caught' in their journey, rather than having to stick those in sidebars or after all the content fields.
• Some specific value(s) pulled from fields on some indirectly related entity, through a token, such as details from a taxonomy term representing the 'section' that a page is in.
• Consistent relevant links on user profiles to take people to common destinations

This is where the Entity Extra Field module (entity_extra_field) comes in. It supports embedding blocks, views or values to be replaced via tokens. So a site builder can set these up to be managed just like ordinary fields on the page (whether it's a node, term, paragraph, or any other type of content).

We ran into an obscure error recently, when saving a view that used a custom views plugin. It was supposed to be a very simple extension to core's bundle (content type) filter:

InvalidArgumentException: The configuration property display.default.display_options.filters.bundle.value.article doesn't exist. in Drupal\Core\Config\Schema\ArrayElement->get() (line 76 of [...]/core/lib/Drupal/Core/Config/Schema/ArrayElement.php).

Several contrib projects ran into this issue too: Drupal Commerce, Search API and Webform Views integration. There's even a core issue that looked relevant... but it turned out to be a simple, if perhaps surprising fix. If you ever run into it, it will have a different property (i.e. due to whichever plugin or default...

Extra quick tip for developers working with Drupal 8 or 9: Adding views to your page content is now incredibly straightforward:

$content['editor_tools']['view'] = [
  '#type' => 'view',
  '#name' => 'editor_tools',
  '#display_id' => 'embed',
  '#arguments' => [
    123,
  ],
];

And that's it! $content is my render array which I'll return and let Drupal render. I suspect most of the bits there are self-explanatory, but in case they aren't:

• '#type' => 'view' is the magic that lets Drupal's rendering system know that this array represents a view to render.
• '#name' is the machine name of the view you want...

In many cases, uniting routing with admin path definition makes things easier, but not when it comes to Views because their routes are generated dynamically. The solution I have come up with is to use a RouteSubscriber.

This article will explain how to formulate the route name for a view because there are very few sources for the information online.

Languages make everything so complicated! I just discovered the autocomplete bit on my reference fields wasn't working - until I tried searching by another language, and then the results gave me a surprise:

My homepage, originally in French, has had an English translation added, but whilst editing in English, I had to search with the French title in order for the page to come up... with the English title! Here's how to solve this...

My site uses Entity translation and the Title module (which I usually recommend as the best way of making your site translatable), and this...

I was asked at Drupalcamp London how to identify where parts of a panel come from. Whether you need to change something on a site you inherited, are looking to trace your steps back on something you created long ago, or need to understand how to fix a colleague's mistake, it can be helpful to have a toolkit of methods to find out what produces all sorts of mystery content - not just for panels, but also views, blocks, fields, and the like.

Views is the king in Drupal land when it comes to making lists of your data, rightly so, it does a wonderful job of making it easy to choose the data you want to list. It also allows you to render your list in various forms, lists, tables. RSS feeds or even jump menus. So if you want to make a list and render it as CSV or XML, then you naturally turn to views, and find that currently you really have two options:

• The export module in Views Bonus Pack
• Views Datasource

Let me talk about Views Datasource before...

Facebook is rapidly taking over the planet, and Drupal is arguably trying to do the same. Facebook added the concept of 'liking' a webpage to their array of social tools a while ago. Drupal modules quickly added the ability to 'like' content on your site.

This is all well and good, but what about getting some of that data back into Drupal?

Suppose that you have an image gallery, and you want people to be able to rate the images, by 'liking' them using Facebook like. What you'd really like to be able to do then is build a 'top...