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":
Updating modules in Drupal 8 is similar to updating modules in Drupal 7 - the drush pm-update (drush up) command still works, but there's a new "gotcha" that you need to look out for when updating modules that work with entities.
Sometimes, after updating modules that interact with entities, you'll see a "Entity/field definitions: Mismatched entity and/or field definitions" error on your site's status report (admin/reports/status).
Looking to migrate your Drupal 6 or 7 site to Drupal 8 but can't do it yet because your site it too reliant on the Webform (or Entityform) module? There's actually very elegant solution that is ready to go today. The core Drupal 8 "Contact" module is now a fully-fledged fieldable entity - meaning you can create various "contact form" types with different sets of fields. Like Entityform, you can use any field types provided by Drupal core as well as contributed modules.
While Drupal 8 has plenty of things to be excited about, there are a few "gotchas" that site-builders need to be aware of as they build out sites. I found the first thing that I had trouble with was the way that Drupal 8 isn't very consistent (yet?) with the way it handles paths. In Drupal 7 and before, anytime you needed to enter a path, it (almost?) never started with a leading "/". For example, need to add an new alias for a node? You would enter "my-new-node", not "/my-new-node".
I recently made the switch from another (several) code editors to PhpStorm based on the recommendations of several members of the Drupal community - not to mention all the postive things I've heard about it on IRC and various other places.
My main motivation for making the switch was the ability to have a integrated debugger - both when running Drupal in a web browser and via Drush. While there are plenty of resources online demonstrating how to set up the debugger, I found that I needed to do a combination of things to make it happen
I recently discovered the solution to a long-standing drush issue I have been experiencing on Mac OS X. The symptoms of the problem included several mysterious fatal errors that would crop up from time-to-time as well as the fact that I've had to use the --uri=mysite.dev parameter for every local site on my computer.
