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
Rebranding ComputerMinds
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.