Drupal 8 saw a dramatic change from previous releases of Drupal. Amongst these changes is a big step towards using an object oriented approach built around the Symfony 3 framework instead of using hooks.
Other changes include a complete rethinking of how themes work with a change to use the TWIG theme engine rather than PHP template. Take a look at some of our Drupal 8 posts below...
Read some of our articles about Drupal 8
Rebranding ComputerMinds
Let's have a quick look through our development process on this project and pick out some of the more interesting bits. As briefly mentioned in the last article we are using a composer set up and all code is version controlled using git on github. All pretty standard stuff. Frontend In the previous article I briefly discussed how we set up Pattern Lab. Before getting stuck in to the components that would make up the...
Rebranding ComputerMinds
We didn’t see this project solely as a chance to rebrand and rebuild for ourselves, it was also an opportunity to try something new and expand our collective knowledge with the potential for using with clients in the future. We had been discussing using Pattern Lab for Front End development for some time and this was the perfect opportunity to try it out. Patten Lab allows the creation of component-driven user interfaces using atomic design...
As with every other Drupal agency on the planet, it was another fun evening of frantic patching of client sites last night due to the release of the highly critical SA-CORE-2018-004 security update for Drupal, released on 25/04/2018. Being so closely related to SA-CORE-2018-002 and knowing proven exploits for that were already affecting thousands of un-patched Drupal sites, time was of the essence for this one as a new exploit was sure to be released...
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.
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.
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:
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.