Quicktips

I often work on migrations that involved dates that need to be migrated into Drupal 8. While many times the dates are for entity created and updated dates, and therefore in Unix timestamp format, sometimes (when migrating events, for example), I'll need to migrate a date in some other format into Drupal's date field.

One of the pillars of the consulting side of the work we do here at DrupalEasy is data migration into Drupal sites. Over the past few years, we've been focused on migrating data into Drupal 8 using the most excellent core migrate modules along with contrib modules like Migrate Tools, Migrate Plus, and Migrate Source CSV. 

Code flows up, data flows down.

I repeat this phrase in just about every workshop I teach - it is one of the basic principles of being a professional web developer. The idea is that we should be working locally, then pushing our changes (using Git) up to the project's dev, then QA, the live environments. As for the project's data (database and files directory for Drupal sites), the direction is opposite, we should only be moving data "down" - from live to QA, or live to dev, or live to local.

If you've adopted a Composer-based Drupal 8 workflow (hopefully using the Drupal Composer/Drupal Project template) where you're keeping dependencies in your project's repository, then you've no-doubt experienced the annoyance of a rouge .git directory ending up in one of your project's dependencies. This will always happen when you're using the -dev version of a Drupal module. 

Drupal 8's text format system provides a way for developers to manage user generated content, regardless of if the user is trusted staff member or an anonymous commenter. With intelligent configuration of various text formats for the various roles on the site, the security and usefulness of a site can be maximized.

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.