how to

Overview

Drupal 8 core provides for solid REST capabilities out-of-the-box, which is great for integrating with a web service or allowing a third-party application to consume content. However, the REST output provided by Drupal core is in a certain structure that may not necessarily satisfy the requirements as per the structure the consuming application expects.

In comes normalizers that will help us alter the REST response to our liking. For this example, we will be looking at altering the JSON response for node entities.
 

There is no explicit documentation for the Drupal 8 version of the flag module, and now that the Drupal 8 version has hit alpha, it's a good time to share some information on it.

In Drupal 8, migration destinations are easy to set up for entities. Since flags are entities in Drupal 8, all you need to do is set up a standard entity migration configuration with the fields for creating a flag.
 

The fields are:

flag_id - The flag's bundle machine name in Drupal

In Drupal 7, if you wanted to reference a view display from a node field, you had to use a module such as Viewfield. In Drupal 8, this can be done with Drupal core alone by using the built in entity reference to reference a block instance created from the view.

Custom Preprocessing

In Drupal 7 there were numerous ways to preprocess data prior to migrating values. This was especially useful when inconsistencies in the data source needed to be addressed. One example I have dealt with in the past was migrating email addresses from an old system that didn’t check for properly formatted emails on its user fields. These errors would produce faulty data in the new Drupal site. I preprocessed the field data for the most common mistakes which reduced the amount of erroneous addresses brought over.

I recently had a need to allow users to create a single comment on two node types, of which only the author could access.  Part of the decision for limiting users to one comment per node was to keep the database size down.  We only wanted one comment to be made per node, and future comments made as edits to the original.

Upgrading websites off of legacy platforms and onto Drupal is a pretty common request. One of the most helpful contributor developed modules, Migrate, is now in Drupal 8 core, which really solidifies Drupal as a great choice when having to make the decision of which CMS to go with when upgrading.  

It's pretty well known that manually testing software changes is better than not testing changes at all, but it's even better to have a set of code tests that can be run automatically. In the Drupal world, this means writing tests using the Simpletest APIs, or on Drupal 8, PHPUnit. Having tests in code will mean that any time someone uploads a patch the drupal.org automated systems will kick in and, hopefully, confirm there are no regressions (i.e. bugs) from the proposed changes in the patch.

The normal Drupal instructions for applying patches are well used and reliable. However, I find them to be a little verbose, so I came up with a slightly quicker workflow.

TL;DR

The short explanation of what I do is to copy the patch's URL and run this command:

curl [patch URL] | patch -p1

Which would then become something like this:

More and more these days, we need to add custom styles to content that the user enters. This can be a challenge for front end developers as we don't know how the information will be entered and have less control over the structure. One thing we can do to help content editors is to provide them with classes and styles based on these classes that they can add in the WYSIWYG.

As this is not a how to set up a WYSIWYG tutorial, I will just state that we use CKEditor.

Once CKEditor is installed, you can begin configuring it and adding your own styles and functionality.

Using Vagrant to manage virtual machines in a development workflow has become a life-saver and standard practice in many cases.