Debugging a Drupal 8 module can take many forms. Often, one of the first tools most developers use is the ability to output variables using the "Devel Kint" module (part of the Devel project). Much like the dsm() function from pre-Drupal 8 versions of Drupal core, the ksm() function provided by Devel Kint provides a slick way to output any variable type to the screen in a readable way.
I've been a big fan of Drupal 8's configuration system since the beta-days of Drupal 8, and even more so now as the contributed module ecosystem around it has matured. I've been using the Config Readonly module from the very beginning to "lock down" configuration on production environments in order to help enforce developer workflows.
I ran across a situation the other day that had me a bit frustrated for a few minutes until Ted Bowman nudged me in the right direction. I was working on a small custom module for a client - one that involved altering a node form using hook_form_alter() - where I needed to know the value of the node ID being edited.
With Drupal 8, the use of view modes (both default and custom) is gaining momentum. This is especially true because of their ability to be easily utilized by Views. Rather than specifying a list of fields with all the required configuration in a View configuration, many site-builders are finding it much easier to define a set of view modes for their entities, have them themed once, then re-used throughout the site - including as part of a View's output via the "Show: Content" option in a View's "Format" configuration.
Every Drupal 8 site should have a custom favicon that helps to reinforce the site's brand - of this there is really no argument. But, over the past (more than a few) years, the role of the lowly favicon has grown from just the little icon on a browser tab. These days, favicons are also used on mobile devices as the gateway to your site.
While working with one of our project coaching (see below for details) clients recently, I was asked to show their developer how to override the default user profile display page with a custom Panels layout.
Drupal 8 has lots of things that Drupal 7 doesn't have - a modern object-oriented foundation, the Twig templating system, and WYSIWYG out-of-the-box - just to name a few. There's also a good number of less flashy additions that are designed to improve the developer experience. One of these additions is the /core/rebuild.php file.
While working through a couple of Drupal 8 projects involving a custom theme, I've been curious about the themename.breakpoints.yml file. I've dutifully updated it with the proper breakpoint values, but I've been a bit mystified with its actual purpose. There's nothing in either of the base themes I've used (Neato and Bootstrap) that actually appears to utilize the data in the breakpoints.yml files.
Twig syntax is new for most Drupalists, and learning how to check for the existence of a field value is a valuble skill for anyone building a Drupal 8 theme. For example, consider the case where there is an optional text field called "Photo caption" on a content type. If the content author populates the "Photo caption" field, then it should be output as follows:
<figcaption>{{ content.field_photo_caption }}</figcaption>
Drupal 8 includes some great debugging tools built-in, but it isn't always super-obvious how to access them. Luckily, the Drupal Console "site:mode" command helps out quite a bit, but it also requires the site to be configured properly before it can be successfully used. I find that having access to the Twig template name suggestions is invaluable when theming a Drupal 8 site:
One of the common workflows we see among professional developers and students is to create a new Drupal 8 site on Pantheon, then clone the site down to a local machine and get it up-and-running in Acquia Dev Desktop (with a fresh, empty database).
By default, Drupal 8's "Basic HTML" text format WYSIWYG editor configuration allows content authors to utilize HTML heading elements "h2" through "h5".
With "Display modes" now a first-class citizen in Drupal 8, there is some lingering confusion about the various "modes" in the Drupal eco-system. In previous versions of Drupal, it could be argued that "display modes" and "view modes" were the same thing. Now that Drupal 8 is available, we should make an effort to be more precise in our definitions of these terms.
In short, both "view modes" and "form modes" are types of "display modes":
