The views module is what always brings a smile to peoples faces when we do our Drupal training, even the most die-hard anti-CMS I-want-to-write-everything-myself-in-raw-PHP developer grudgingly offers up some praise when we do a demonstration.
We've been using views since the dark ages of Drupal 4 all the way up to it's inclusion as a core module in Drupal 8. I don't think we have ever built a site without at least a couple of custom views, and most have a few custom views handlers thrown in to handle those cheeky listing or exporting situations.
We've blogged a bunch about Drupal views over the years, you can read it all below ...
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...
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...
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...
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...
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...