Planet Drupal

In Drupal 7, we had menu_get_object() to get the object in code for whichever node, term, or whatever entity makes up the current page. But in Drupal 8, that has been replaced, and entities can usually be operated on in a generic way. If you know the type of entity you want, it's pretty simple. But I keep running into different suggestions of how to get the entity object when you don't know its type. Given that D8 allows us to deal with entities in a unified way, I thought there must be a good way! The code of core itself is usually the best place to look for examples of how to do common things.

Define a schema for any bespoke configuration, it's not too hard. It's needed to make it translatable, but Drupal 8 will also validate your config against it so it's still handy on non-translatable sites. As a schema ensures your configuration is valid, your code, or Drupal itself, can trip up without one. Set up a schema and you avoid those problems, and get robust validation for free. Hopefully my example YAML shows how it can be quite simple to do.

This post is the first in a series about getting Drupal to run as a persistent server, responding to requests without bootstrapping each and every time. This is how many other application frameworks and languages run: nodejs, Rails etc. In those systems you start some instances of your application and then they do whatever bootstrapping they need to do and then they enter an endless loop waiting for requests. I recently upgraded our internally hosted...

I've previously written about dynamic forms in Drupal, using #states to show or hide input boxes depending on other inputs. Since then, Drupal 7 and 8 have both got the ability to combine conditions with OR and XOR operators. This makes it possible to apply changes when a form element's value does not equal something, which is not obvious at all.

In Drupal 8, there are many ways to interact with configuration from PHP. Most will allow you to write the config values, but some are read-only. Some will include 'overrides' from settings.php, or translations. There are many layers of abstraction, that each have different purposes, so it can be easy to run into subtle unintended problems (or more obvious errors!) if you pick a method that doesn't quite suit what you actually need to do. Here I'm going to outline some of them and when you might pick each one.

I have honed a selection of commands that I regularly use in the creation and application of patches. Here is a run-down of my most useful commands.

In a recent Drupal 8 project, one of the site's vocabularies had several thousand terms in it (representing airports), which caused its admin listing page to run out of memory before it could render. I wanted to solve this without affecting any other vocabularies on the site, and improve the listing itself along the way to be more useful, with filters to make searching it much easier. The original listing is not a view, and loads much more than it needs to. Here's the customised page for airports that I wanted to head towards:

I've recently been playing around on Windows 10's new Bash on Ubuntu feature, which provides a native bash linux shell for Windows. I thought I'd try and get a Drupal 8 site running, via composer, served from Apache, without any need for a virtual machine in Windows. Kristian Polso wrote a great tutorial that got me most of the way there, but I wanted to share some extra discoveries and thoughts about the experience. Skip...

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.