How-Tos Archives - Four Kitchens

Welcome to the first episode in our new video series for Emulsify. Emulsify 2.x is a new release that embodies our commitment to component-driven design within Drupal. We’ve added Composer and Drush support, as well as open-source Twig functions and many other changes to increase ease-of-use.

In this video, we’re going to get you up and running with Emulsify. This blog post accompanies a tutorial video, which you can find embedded at the end.

Emulsify is, at it’s core, a prototyping tool. At Four Kitchens we also use it as a Drupal 8 theme starter kit. Depending on how you want to use it, the installation steps will vary. I’ll quickly go over how to install and use Emulsify as a stand alone prototyping tool, then I’ll show you how we use it to theme Drupal 8 sites.

Emulsify Standalone

Installing Emulsify core as a stand alone tool is a simple process with Composer and NPM (or Yarn).

composer create-project fourkitchens/emulsify --stability dev --no-interaction emulsify
cd emulsify
yarn install (or npm install, if you don’t have yarn installed)

Once the installation process is complete, you can start it with either npm start or yarn start:

yarn start

Once it’s up, you can use the either the Local or External links to view the Pattern Lab instance in the browser. (The External link is useful for physical device testing, like on your phone or tablet, but can vary per-machine. So, if you’re using hosted fonts, you might have to add a bunch of IPs to your account to accommodate all of your developers.)

The start process runs all of the build and watch commands. So once it’s up, all of your changes are instantly reflected in the browser.

I can add additional colors to the _color-vars.scss file, Edit the card.yml example data, or even update the 01-card.twig file to modify the structure of the card component.

That’s really all there is to using Emulsify as a prototyping tool. You can quickly build out your components using component-driven design without having to have a full web server, and site, up and running.

Emulsify in a Composer-Based Drupal 8 Installation

It’s general best practice to install Drupal 8 via Composer, and that’s what we do at Four Kitchens. So, we’ve built Emulsify 2 to work great in that environment. I won’t cover the details of installing Drupal via Composer since that’s out of scope for this video, and there are videos that cover that already. Instead, I’ll quickly run through that process, and then come back and walk through the details of how to install Emulsify in a Composer-based Drupal 8 site.

Okay, I’ve got a fresh Drupal 8 site installed. Let’s install Emulsify alongside it.

From the project root, we’ll run the composer require command:

composer require fourkitchens/emulsify

Next, we’ll enable Emulsify and its dependencies:

cd web
drush en emulsify components unified_twig_ext -y

At this point, we highly recommend you use the Drush script that comes with Emulsify to create a custom clone of Emulsify for your actual production site. The reason is that any change you make to Emulsify core will be overwritten when you update Emulsify, and there’s currently no real good way to create a child theme of a component-based, Pattern Lab -powered, Drupal theme. So, the Drush script simply creates a clone of Emulsify and makes the file renaming process into a simple script.

We have another video covering the Drush script, so definitely watch that for all of the details. For this video though, I’ll just use emulsify core, since I’m not going to make any customizations.

cd web/themes/contrib/emulsify/ (If you do create a clone with the drush script, you’ll cd web/themes/custom/THEME_NAME/)
yarn install
yarn start

Now we have our Pattern Lab instance up and running, accessible at the links provided.

We can also head over to the “Appearance” page on our site, and set our theme as the default. When we do that, and go back to the homepage, it looks all boring and gray, but that’s just because we haven’t started doing any actual theming yet.

At this point, the theme is installed, and you’re ready to create your components and make your site look beautiful!

Thanks for following our Emulsify 2.x tutorials. Miss a post? Read the full series is here.

Pt 1: Installing Emulsify | Pt 2: Creating your Emulsify 2.0 Starter Kit with Drush | Pt 3: BEM Twig Function | Pt 4: DRY Twig Approach | Pt 5: Building a Full Site Header in Drupal

Just need the videos? Watch them all on our channel.

Download Emulsify

Four Kitchens is diving into web-based VR application development. We whipped up a demo VR experience for DrupalCon Baltimore in April of this year, and we have a few more projects we’re putting together. In the spirit of sharing knowledge, I’m going to walk you through the basics of setting up a browser-based WebVR project using A-Frame, React, and aframe-react in this post. Let’s get started!

The Toolchain

Setting up tooling and a build system is probably the hardest part in getting started with WebVR. Thankfully, since building WebVR applications is a lot like building standard web applications, we can re-purpose well documented, industry standard tools. I’ve put together a boilerplate with a simple Node.js application, which contains Webpack build/dev config, linting, Babel config, etc. It’s a great place to get started:

Clone the boilerplate repository onto your local machine.
Make sure Node.js, NPM, and Yarn are installed.
1. recommend using NVM to install Node.js
2. to install Yarn, run: npm install -g yarn
In the root of the boilerplate repository, run yarn. This will install all project dependencies.
In the root of the boilerplate repository, run yarn start.
Yarn will output Project is running at https://ip:port. Navigate to that ip/port in your browser, and allow the project to load despite the SSL certs being nonexistent.
You should see a simple scene with a sphere, cube, cylinder, and plane.

WebVR Local Development Server?

When you’re writing an standard web application, you typically end up running a local development server, which serves your application on a port on localhost. This works fine for standard applications, but when you’re creating a WebVR application, you need to be able to develop and test everything in a VR headset. If you’re developing using a Google Cardboard or Daydream, this means you’ll need to access your development server on your mobile phone. This can easily be accomplished, and if you’ll take a look at the Webpack Dev server config in our boilerplate, you’ll see that your machine’s local IP is fetched and the development server is set to run on that IP. Once you have the server running, you should be able to load it up on a mobile device connected the same network as your computer.

Make a WebVR Application

In your favourite code editor or IDE, open up src/index.jsx from your cloned boilerplate repo, and let’s get to work! In the boilerplate and in this article, we’re going to be using A-Frame, React, and aframe-react, which allows us to create A-Frame components as React components.

You might ask… why use React? That’s a great question. React is a great tool for building WebVR applications for the same reason it’s a great tool for building standard web applications. React components are declarative, extend-able objects that provide simple tools around state and property management. These things make React very useful, especially in a 3D space. So let’s import a few things and create a basic React component.

In src/index.jsx:

// Import react, react-dom, and a few things from aframe-react. If you look in your package.json file, you’ll see that these have been installed via yarn.
import React from 'react';
import ReactDOM from 'react-dom';
import { Scene, Entity } from 'aframe-react';

// Import the aframe library.
require('aframe');

/**
 * Awesome A-Frame VR app.
 * {@inheritdoc}
 */
const AwesomeVR = () => (
  // Not doing anything in here just yet.
);

// Render our React component on a div with the class “application-container”
ReactDOM.render(<AwesomeVR />, document.querySelector('.application-container'));

// Import react, react-dom, and a few things from aframe-react. If you look in your package.json file, you’ll see that these have been installed via yarn.

import React from 'react';

import ReactDOM from 'react-dom';

import { Scene, Entity } from 'aframe-react';

// Import the aframe library.

require('aframe');

/**

* Awesome A-Frame VR app.

* {@inheritdoc}

const AwesomeVR = () => (

// Not doing anything in here just yet.

);

// Render our React component on a div with the class “application-container”

ReactDOM.render(<AwesomeVR />, document.querySelector('.application-container'));

In src/index.html:

<html>
  <head>
    <title>Awesome VR</title>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <meta name="apple-mobile-web-app-capable" content="yes" />
    <meta name="apple-mobile-web-app-status-bar-style" content="black" />
  </head>
  <body>
    <main>
      <noscript>This application is not accessible to users with JavaScript turned off.</noscript>
    </main>
     <div class="application-container"></div>
  </body>
</html>

<html>

<head>

<title>Awesome VR</title>

</head>

<body>

<main>

</main>

</body>

</html>

Scenes and Skies

When building a WebVR application, you need to define a “scene”, which is a global object that defines the 3D space in which entities will be placed. Let’s define a scene in our AwesomeVR component:

…
const AwesomeVR = () => (
  <Scene>
    // No A-Frame entities in here yet.
  </Scene>
);
…

…

const AwesomeVR = () => (

<Scene>

// No A-Frame entities in here yet.

</Scene>

);

…

The next thing we need to do is add what’s called a “sky”. A sky is a background color or 360° image that will become the background sphere that surrounds users in our VR app. To add a sky, we need to add an entity of the “sky” primitive, and give it either a color, or a 360° equirectangular image:

…
const AwesomeVR = () => (
  <Scene>
    // Add one of the following skies:
    // Background color sky...
    <Entity primitive="a-sky" color="#4286f4" />

    // … or an equirectangular image sky:
    <Entity primitive=”a-sky” src=”https://c1.staticflickr.com/3/2287/2513415428_d14745b420_o.jpg” />
    // This sky image is a photo of The Long Center, in Austin TX.
  </Scene>
);
…

…

const AwesomeVR = () => (

<Scene>

// Add one of the following skies:

// Background color sky...

// … or an equirectangular image sky:

// This sky image is a photo of The Long Center, in Austin TX.

</Scene>

);

…

At this point, if you run npm run start or yarn start in the root of this repository, you should be able to load the page served by your dev server, and see a 360° environment with the sky you defined. Cool!

Entities

Now that we have a scene and a sky, let’s create some geometric components, or entities. We’re going to be creating this simple application. I’ll walk you through it in the code comments below:

…
const AwesomeVR = () => (
  <Scene>
    // This is our sky...
    <Entity primitive="a-sky" color="#4286f4" />

    // Let’s make a plane, and put some things on it.
    <Entity
      // You should always specify an “id” property and give your entities a unique name. This will
      // make sure you can inspect your application and identify your components later on.
      id="entity--plane"
      // Tell aframe-react you’re creating a plane.
      // {@link https://aframe.io/docs/0.5.0/primitives/a-plane.html}
      primitive="a-plane"
      // Most entities in A-Frame need to be positioned. Aframe-react allows us to specify a nice,
      // clean object with x, y, and z properties that describe this entity’s position.
      position={{ x: 0, y: 0, z: -4 }}
      // Like position, most entities in A-Frame must have a rotation property as well.
      rotation={{ x: -90, y: 0, z: 0 }}
      // The width and height properties allow us to define the size of the entity.
      width={4}
      height={4}
      // This is self-explanatory, we specify a color. We could alternatively specify a “src” property
      // and set the material of this entity to an image.
      color="#7BC8A4"
    />

// We defined a plane, now let’s put a few things on it!
<Entity
      id="entity--box"
      // This entity is a box, so it’s primitive is “a-box”
      // {@link https://aframe.io/docs/0.5.0/primitives/a-box.html}
      primitive="a-box"
      position={{ x: -1, y: 0.5, z: -3 }}
      rotation={{ x: 0, y: 45, z: 0 }}
      color="#4CC3D9"
    />
    <Entity
      id="entity--sphere"
      // This entity is a sphere, so it’s primitive is “a-sphere”.
      // {@link https://aframe.io/docs/0.5.0/primitives/a-sphere.html}
      primitive="a-sphere"
      position={{ x: 0, y: 1.25, z: -5 }}
      // We set the radius of the sphere here...
      radius={1.25}
      color="#EF2D5E"
    />
    <Entity
      id="entity--cylinder"
      // This entity is a cylinder, so it’s primitive is “a-cylinder”.
      {@link https://aframe.io/docs/0.5.0/primitives/a-cylinder.html}
      primitive="a-cylinder"
      position={{ x: 1, y: 0.75, z: -3 }}
      radius={0.5}
      width={4}
      height={1.5}
      color="#FFC65D"
    />

  </Scene>
);
…

…

const AwesomeVR = () => (

<Scene>

// This is our sky...

// Let’s make a plane, and put some things on it.

<Entity

// You should always specify an “id” property and give your entities a unique name. This will

// make sure you can inspect your application and identify your components later on.

id="entity--plane"

// Tell aframe-react you’re creating a plane.

// {@link https://aframe.io/docs/0.5.0/primitives/a-plane.html}

primitive="a-plane"

// Most entities in A-Frame need to be positioned. Aframe-react allows us to specify a nice,

// clean object with x, y, and z properties that describe this entity’s position.

position={{ x: 0, y: 0, z: -4 }}

// Like position, most entities in A-Frame must have a rotation property as well.

rotation={{ x: -90, y: 0, z: 0 }}

// The width and height properties allow us to define the size of the entity.

width={4}

height={4}

// This is self-explanatory, we specify a color. We could alternatively specify a “src” property

// and set the material of this entity to an image.

color="#7BC8A4"

// We defined a plane, now let’s put a few things on it!

<Entity

id="entity--box"

// This entity is a box, so it’s primitive is “a-box”

// {@link https://aframe.io/docs/0.5.0/primitives/a-box.html}

primitive="a-box"

position={{ x: -1, y: 0.5, z: -3 }}

rotation={{ x: 0, y: 45, z: 0 }}

color="#4CC3D9"

<Entity

id="entity--sphere"

// This entity is a sphere, so it’s primitive is “a-sphere”.

// {@link https://aframe.io/docs/0.5.0/primitives/a-sphere.html}

primitive="a-sphere"

position={{ x: 0, y: 1.25, z: -5 }}

// We set the radius of the sphere here...

radius={1.25}

color="#EF2D5E"

<Entity

id="entity--cylinder"

// This entity is a cylinder, so it’s primitive is “a-cylinder”.

{@link https://aframe.io/docs/0.5.0/primitives/a-cylinder.html}

primitive="a-cylinder"

position={{ x: 1, y: 0.75, z: -3 }}

radius={0.5}

width={4}

height={1.5}

color="#FFC65D"

</Scene>

);

…

Create your entities, save the file, and then re-visit your app in the browser. You should see something like this:

Testing in Daydream or Cardboard

Yes, you can see your WebVR application on your desktop browser, but seeing your app in a VR headset is very different, and as you’re developing, you’ll need to frequently test your changes in your actual headset. So pull out your mobile phone!

Connect your phone to the same network that your computer is connected to (WiFi router).
Open up a WebVR-compatible browser (Google Chrome or Safari).
Type in the IP address and port number that points to your dev server running on your computer, and then load up the application.
Click the VR mode toggle button in the lower right hand corner of the app.
Slide your phone into your Cardboard or Daydream.
If you’re using a Daydream, initialize your controller, after the initialization has been completed you’ll be taken to your app.

And violà! You’ve made a very simple WebVR application with A-Frame, React, and aframe-react. From here, you’ll want to take a look at the A-Frame documentation and read about all the different primitives and components at your fingertips.

This is the first of many posts about WebVR. In our next installation, we’ll be covering ReactVR, another WebVR framework. Until then, have fun playing with A-Frame!

So you got hit with an iCal invite for $19.99 RayBans? Here is how to get rid of it the right way without notifying the spammers you have a valid email:

Open iCal
Create a new calendar called Trash
Double click the spam calendar invites

– NOTE: Do not accept or decline, it notifies the spammers you have a valid email and you will receive even more invites in the future

Change the spam calendar invites to be associated with the new Trash calendar
Delete the new calendar to completely remove the invites
Select the delete and do not notify option

nyu-wagner-migrate.md

Speed Up Migration Development

One of the things that Drupal developers do for clients is content migration. This process uses hours of development time and often has one developer dedicated to it for the first half of the project. In the end, the completeness of the migration depends partly on how much time your client is willing to spend on building out migration for each piece of their content and settings. If you’ve come here, you probably want to learn how to speed up your migration development so you can move on to more fun aspects of a project.

The Challenge

Our client, the NYU Wagner Graduate School of Public Service was no exception when they decided to move to Drupal 8. Since our client had 65 content types and 84 vocabularies to weed through, our challenge was to build all those migrations into their budget and schedule.

The Proposed Solution

Since this was one of our first Drupal 8 sites, I was the first to dig my hands into the migration system. I was particularly stoked in the fact that everything in Drupal 8 is considered to be an entity. This opened up a bunch of possibilities. Also, the new automated migration system—Migrate Drupal—that came with core was particularly intriguing. In fact, our client had started down the path of using Migrate Drupal to upgrade their site to D8. Given they had field collections, entity references, and the fact that the Migrate Drupal module was still very much experimental for Drupal 7 upgrades, this didn’t pan out with a complete migration of their data.

The proposed solution was to use the --configure-only method on the drush tool migrate-upgrade. Doing so would build out templated upgrade configurations that would move all data from Drupal 7 or Drupal 6 to Drupal 8. The added bonus is that you can use that as a starting point and modify them from there.

Migration in Drupal 7 vs Drupal 8

Since we have the 100 mile high view of what the end game is, lets talk a little about why and how this works. In Drupal 7 Migrations are strictly class-based. You can see an example of a Drupal 7 migration in the Migrate Example module. The structure of the migration tends to be one big blob of logic (broken up by class functions of course) around a single migration. Here are the parts:

Class Constructor: where you define your source, destination, and field mapping
Prepare: a function where you do all your data processing

In Drupal 8, the concept of a migration has been abstracted out into the various parts that makes them reusable and feel more like “building with blocks” approach. You can find an example inside the Migrate Plus module. Here are the parts:

Source Plugins: a class defining the query, initial data alteration, keys, and fields provided by the source
Destination Plugins: a class defining how to store the data received in Drupal 8
Process Plugins: a class defining how to transform data from the source to something that can be used by the destination or other process plugins; you can find a full list of what comes with core in Migrate’s documenation
Migration Configuration: a configuration file that brings the configuration of all the source, destination, and process plugins to make a migration

Now yall might have noticed I left out hook_prepare_row. Granted, this is still available. It was also a key way many people used to manipulate data across several source fields that behaved the same. With the ideal of process plugins, you can now abstract out that functionality and use it in your field mapping.

How “Migrate Drupal” Makes the Process Better

There are tons of reasons to use Migrate Drupal to start your migration.

It builds a migration from your Drupal site

You might have seen above that I mentioned that Migrate Drupal provides a templated set of configurations. This is a product of some very elaborate migration detection classes. This means you will get all the configurations for:

content types
field setup
field configuration
various site settings
taxonomy vocabularies
custom blocks
content and their revisions
etc…

These will be built specifically for the site you are migrating from. This results in tons of configuration files—my first attempt created over 140 migration YAML files.

It’s hookable

Hookable means that it’s not just a part of core thing and that it’s expandable. That means that contributed modules can provide their own templates for their entities and field types, allowing Migrate Drupal to move over that data too. For example, it is completely possible (and in progress) for the Field Collection module to build in migration templates so that the migration will know how to import a field collection field. Not only that, the plugins provided by the contributed modules can be used in your custom migrations as well.

No initial need for redirection of content

Here’s an interesting one, everything comes over pretty much verbatim. Node IDs, term IDs, etc. are exactly the same. URL aliases come over, too, by default. Theoretically, you could have the same exact site from D7 on D8 if you ported over the theme.

More time to do the alterations the client wants

Since you aren’t spending your time building all the initial source plugins, process plugins, destination plugins, and configurations, you now have more time to alter the migrations to fit the new content model, or work with the new spiffy module like paragraphs.

How-To: Start a Migration with “Migrate Drupal”

Ok so here is the technical part. From here on is a quick How-To that gets you up and going. Things you will need are:

a Drupal 6 or 7 site
your brand new Drupal 8 site
a text editor
drush

1. Do a little research and install contrib modules.

We first need to find out if our contrib modules that are installed on our Drupal 6/7 site are available and have a migration component to them in Drupal 8. Once we identify the ones that we can use, go ahead and install them in Drupal 8 so they can help you do the migration. Here are a couple of thoughts:

Is the field structure the same as in Drupal 6/7? The entity destination plugin is a glorified way to say $entity->create($data); $entity->save();. Given this, if you know that on Drupal 6/7 that the field value was, for example…

[
  'value' => 'This is my value.',
  'format' => 'this is my format'
]

[

'value' => 'This is my value.',

'format' => 'this is my format'

]

…and that it’s the same on Drupal 8, then you can rest easy. The custom field will be migrated over perfectly.

Is there a cckfield process plugin in the Drupal 8 Module for the custom field type? When porting fields, there is an automated process of detecting field types. If the field type you are pulling from equates to a known set of field types by the cckfield migration plugin, it will be used. You can find these in src/Plugin/migrate/cckfield of any given module. The Text core module has an example.

Is there a migration template for your entity or field in the Drupal 8 module? A migration template tells the Drupal Migrate module that there are other migrations that need to be created. In the case of the Text module. you will see one for the teaser length configuration. There can be multiple and look like migrations themselves, but are appended to in such a way to make them special for your site. You can find these in
migration_templates in the module.

Are there source, process, or destination plugins in the Drupal 8 module? These all help you (or the Migrate Drupal module) move content from your old site to your new one. It’s very possible that there are plugins not wired up to be used in an automated way yet, but that doesn’t keep you from using them! Look for them in src/plugin/migrate.

2. Install the contrib migrate modules.

First you must install all the various contributed modules that help you build these configurations and test your migrations. Using your favorite build method, add the following modules to your project:

NOTE: Keep in mind that you will need to be mindful of the version that goes with what version of Drupal Core. Example 8.x-1.x goes with Drupal 8.0.*, 8.x-2.x goes with Drupal 8.1.*, and 8.x-3.x goes with Drupal 8.2.*.

3. Set up the upgrade/migrate databases.

Be sure to give your database an key. The default is ‘upgrade’ for drush migrate-upgrade and ‘migrate’ for drush migrate-import. I personally stick with ‘migrate’ and just be sure to give the custom settings to migrate-upgrade. I use drush migrate-import a ton more than drush migrate-upgrade.

$databases = [
  'default' => [
    'default' => [
      'database' => 'drupal',
      'username' => 'user',
      'password' => 'pass',
      'host' => 'localhost',
      'port' => '',
      'driver' => 'mysql',
      'prefix' => '',
    ],
  ],
  'migrate' => [
    'default' => [
      'database' => 'migrate',
      'username' => 'user',
      'password' => 'pass',
      'host' => 'localhost',
      'port' => '',
      'driver' => 'mysql',
      'prefix' => '',
    ],
  ],
];

$databases = [

'default' => [

'database' => 'drupal',

'username' => 'user',

'password' => 'pass',

'host' => 'localhost',

'port' => '',

'driver' => 'mysql',

'prefix' => '',

'migrate' => [

'default' => [

'database' => 'migrate',

'username' => 'user',

'password' => 'pass',

'host' => 'localhost',

'port' => '',

'driver' => 'mysql',

'prefix' => '',

];

4. Export the migration configuration.

First I want to give credit to Mike Ryan for originally documenting this process. Without it, or his help in IRC, you wouldn’t have gotten this article today.

Go ahead and import your Drupal 6/7 database if you aren’t connecting to a live instance in your database settings with your preferred method. Take your pick:

drush sql-sync
drush sql-drop --database=migrate; gunzip -c /path/to/migrate.sql.gz | drush sqlc --database=migrate

Next run Migrate Upgrade to get your configuration built and stored in the Drupal 8 site.

drush migrate-upgrade --legacy-db-key=migrate --configure-only

Finally store your configuration. I prefer just to stick it in the sync directory created by Drupal 8 (or in my case configure for checking into Git).

drush config-export sync -y

I’m verbose about the directory because we usually have one for local development stored in the local key also. You can leave off the word sync if you only have a single sync directory.

5. Update your migration group with the info for the migration.

This is a quick and simple step. Find migrate_plus.migration_group.migrate_drupal_7.yml or migrate_plus.migration_group.migrate_drupal_6.yml and set the shared configuration. I usually make mine look like this:

langcode: en
status: true
dependencies: {  }
id: migrate_drupal_7
label: 'Import from Drupal 7'
description: 'Migrations originally generated from drush migrate-upgrade --configure-only'
source_type: 'Drupal 7'
module: null
shared_configuration:
  source:
    key: migrate

langcode: en

status: true

dependencies: { }

id: migrate_drupal_7

label: 'Import from Drupal 7'

description: 'Migrations originally generated from drush migrate-upgrade --configure-only'

source_type: 'Drupal 7'

module: null

shared_configuration:

source:

key: migrate

5. Alter the configuration.

Ok here comes the fun part. You should now have all the configurations to import everything. You could in fact now run drush mi --all and in theory get a complete migration of your old site to your new site in the data sense.

With that said, you will most likely need to make alterations. For example, in my migration we didn’t want all of the filters migrated over. Instead, we wanted to define the filters first, and then use a map to map filters from one type to another. So I did a global find across all the migration files for:

    plugin: migration
    migration: upgrade_d7_filter_format
    source: format

plugin: migration

migration: upgrade_d7_filter_format

source: format

And replaced it with the following:

    plugin: static_map
    source: format
    map:
      php_code: filter_null
      filtered_html: basic_html

plugin: static_map

source: format

map:

php_code: filter_null

filtered_html: basic_html

Another example of a change you can make is the change of the source plugin. This allows you to change the data you wanted. For example, I extended the node source plugin to add a where-clause so that I could only get data created after a certain time.

namespace Drupalwg_drupal7_migratePluginmigratesource;

use DrupalnodePluginmigratesourced7Node as MigrateD7Node;
use DrupalmigrateRow;

/**
 * Drupal 7 nodes source from database.
 *
 * @MigrateSource(
 *   id = "wg_d7_node",
 *   source_provider = "node"
 * )
 */
class Node extends MigrateD7Node {

  /**
   * {@inheritdoc}
   */
  public function query() {
    $query = parent::query();
    // If we pass in a timestamp... only get things created since then.
    if (isset($this->configuration['highwater'])) {
      $query->condition('n.created', $this->configuration['highwater'], '>=');
    }
    return $query;
  }

}

namespace Drupalwg_drupal7_migratePluginmigratesource;

use DrupalnodePluginmigratesourced7Node as MigrateD7Node;

use DrupalmigrateRow;

/**

* Drupal 7 nodes source from database.

* @MigrateSource(

* id = "wg_d7_node",

* source_provider = "node"

* )

class Node extends MigrateD7Node {

/**

* {@inheritdoc}

public function query() {

$query = parent::query();

// If we pass in a timestamp... only get things created since then.

if (isset($this->configuration['highwater'])) {

$query->condition('n.created', $this->configuration['highwater'], '>=');

}

return $query;

}

Lastly, you may want to change the destination configuration. By default, the configuration of the migration will go to a content type with the same name. It may be possible that you changed the name of the content type or are merging several content types together. Simply altering…

destination:
  plugin: 'entity:node'
  default_bundle: page

destination:

plugin: 'entity:node'

default_bundle: page

…to be…

destination:
  plugin: 'entity:node'
  default_bundle: landing_page

destination:

plugin: 'entity:node'

default_bundle: landing_page

…may be something you need to do.

Once you are done altering the migration save the configuration files. You can use the sync directory or if you plan on distributing it in a module, you can use the
config/install folder of you module.

Rebuild your site with the new configuration via your preferred method, or simply run drush config-import sync -y.

6. Migrate the data.

This is the last step. When you are ready, migrate the data either by running each of the migrations individually using --force, run the migration even though other pieces haven’t, use the --execute-dependencies, or just go ahead and go for the gold drush migrate-import --all

Caveats

So finally after you go through all the good news, there are a few valid points that need to be made about the limitations of this method.

IDs are verbatim due to the complexity of dependencies

So this means that the migrations are currently expecting all the nids, tids, fids, and other IDs, to be exactly what they were on Drupal 6 or 7. This causes issues when your client is building new staged data. You have three options in this case:

Alter the node, node_revision, file_managed, taxonomy_term_data, users, and probably some others I’m missing here that house the main entities that entity reference fields will need, so that their keys are something your client will not reach on their current production site while you are developing.
Do not start adding or altering content on Drupal 8 until all migrations are done.
Go through all the migrations and add migration process plugins where an entity is referenced, and then remove the main id from the migration of that entity.

In my case, I went with the first solution because this realization hit me kinda late. Our plan was to migrate now for data so our client would have something to show their stakeholders, and then migrate again later to get the latest data before going live.

There are superfluous migrations

You will always find out that you don’t want to keep the settings verbatim to the Drupal 6 or 7 site. This means you will have to remove that migration and remove it’s dependency from all the other migrations that depend on it. Afterwords, you will need to make sure that that case is covered. I shared an example in this article where we decided to go ahead and configure new filter formats. Another example may be that you don’t even give a crap about the dblog settings from your old Drupal site.

Final Thoughts

For NYU Wagner, we were able to save a ton of time having the migrations built out for us to start with. Just the hours spent on building the field configurations for the majority of the content types that were to stay the same was worth it. It was also a great bridge into “How Do Migrations Work?” We now have a more complete custom migration for our client in a fraction of the time once our feature set was nailed down, than if we were to go build out the migrations one at a time. Happy migrating.

Aquifer on Pantheon isn’t a feature that works out of the box, but it does work. In this tutorial I will teach you how in four steps:

Installing Aquifer
Creating a new Aquifer project
Preparing your project for Pantheon
Next steps

Node

If you don’t have nvm (node version manager) installed, it is highly recommended.

Installing Aquifer

The Aquifer documentation is officially hosted at http://aquifer.io/.

If you are looking to just get Aquifer working the Quick Start Guide will run you through the steps of getting Aquifer set up on your local environment.

WARNING: Until Aquifer releases a new version, the version installed when following the quick start guide will not work with the rest of this tutorial.

So, which version of Aquifer does work with this tutorial?

We will be using the Aquifer branch 1.0.0. This is the latest development branch until we get a full 1.0.0 release.

Setting up a development version of Aquifer:

This page contains a section called “Installing for development;” this will be the set of instructions we follow.

It basically says:

Run node --version to check that you are running node v6.3.1 or later. If not, use nvm to install a more recent version.
If you had a version of Aquifer already installed, delete the node_modules directory within the Aquifer directory.
If not, navigate to a directory you wish to install Aquifer in and clone the repository:
a. git clone git@github.com:aquifer/aquifer.git # SSH version – or –
b. git clone https://github.com/aquifer/aquifer.git # HTTPS if no github keys
IMPORTANT: Checkout the 1.0.0 branch git checkout 1.0.0
Run npm install to get the latest packages.
Then run npm link to tell node that you have a command line package outside of the normal node install directory. This will also create a symlink in your /usr/local/bin directory and your /usr/local/lib/node_modules directory for your new Aquifer command.
Verify your Aquifer version by running aquifer --version (this will return 1.0.0-beta1; that is correct as of 7-Sept-2016).

If you made it this far without errors, congratulations, you are doing good! You can now use this directory as a normal Git repository and can switch branches and update Aquifer as the latest updates come out.

Creating a New Aquifer Project

Now we’ll setup a new Aquifer project. You can use an existing Aquifer project but for purposes of this demo we will use a new project.

Navigate to a directory you want to install your Aquifer project in.
Create a new project named “test”: aquifer create test
Navigate into the project that was generated: cd test
Then, run aquifer build (This should complete without errors. If it doesn’t, your environment should be fixed at this stage before continuing).

Preparing Your Project for Pantheon

Editing drupal.make.yml

BIG PICTURE: We are replacing the standard Drupal core with Pantheon’s Drupal core based on Pressflow. Without this step your site won’t run on Pantheon. You can feel free to replace the reference to Pantheon’s core with Acquia’s core, Pressflow, another hosting provider’s core, or a distribution, depending upon your exact needs. This flexibility is one of the many benefits of using Aquifer.

Using your normal text, editor open the drupal.make.yml file
It should say core 7.x

This:


projects:
  drupal:
    version: ~
  admin_menu:
    version: ~

projects:

drupal:

version: ~

admin_menu:

version: ~

Should read:


projects:
  # Core version 7.50.
  drops_7:
    type: "core"
    download:
      type: "git"
      url: "git@github.com:pantheon-systems/drops-7.git"
      branch: "master"
      revision: "2f1c945d01cd03250e2b6668ad77bf24f54a5a56"
  # Contrib
  admin_menu:
    version: ~

projects:

# Core version 7.50.

drops_7:

type: "core"

download:

type: "git"

url: "git@github.com:pantheon-systems/drops-7.git"

branch: "master"

revision: "2f1c945d01cd03250e2b6668ad77bf24f54a5a56"

# Contrib

admin_menu:

version: ~

For your convenience, this is Acquia’s configuration (UNTESTED):


projects:
  # Core version 7.50.
  drupal:
    type: "core"
    download:
      type: "git"
      url: "git://git.acquia.com/drupal/branches/7.x.git"
      branch: "master"
      revision: "837b8d22cd084b5c15f93ef6b65a98d9d20ee80f"
  # Contrib
  admin_menu:
    version: ~

projects:

# Core version 7.50.

drupal:

type: "core"

download:

type: "git"

url: "git://git.acquia.com/drupal/branches/7.x.git"

branch: "master"

revision: "837b8d22cd084b5c15f93ef6b65a98d9d20ee80f"

# Contrib

admin_menu:

version: ~

For your convenience, this is Pressflow’s configuration (UNTESTED):


projects:
  # Core version 7.44.
  drupal:
    type: "core"
    download:
      type: "git"
      url: "git@github.com:pressflow/7.git"
      branch: "master"
      revision: "c3d3e3b7c07ff19bdbf8eddbafb9340c489ee23c"
  # Contrib
  admin_menu:
    version: ~

projects:

# Core version 7.44.

drupal:

type: "core"

download:

type: "git"

url: "git@github.com:pressflow/7.git"

branch: "master"

revision: "c3d3e3b7c07ff19bdbf8eddbafb9340c489ee23c"

# Contrib

admin_menu:

version: ~

Note: Change the revision to the commit SHA of any version. Then run:


aquifer build

aquifer build

If this succeeded and in your terminal output you see:


drops_7 cloned from git@github.com:pantheon-systems/drops-7.git.     [ok]
Checked out revision 2f1c945d01cd03250e2b6668ad77bf24f54a5a56.       [ok]

drops_7 cloned from git@github.com:pantheon-systems/drops-7.git. [ok]

Checked out revision 2f1c945d01cd03250e2b6668ad77bf24f54a5a56. [ok]

You now have a Pantheon ready project. Congratulations you just leveled up!!!

You could build this to a separate directory and use this as an artifact repo, but why don’t we upgrade you project one more time and make deployments easier?

Setting up Pantheon

If you have not already done so, this would be a good time to create a FREE developer’s account on Pantheon. Also, setup a new project and give it a name (we will need that shortly). Don’t worry too much about setup here, we are going to change things soon.

Editing aquifer.json

BIG PICTURE: We are going to build the project and have it overwrite and commit on the destination remote. Conceptually, a normal workflow for this ends up creating two repositories: (1) Your aquifer repository (where all the source code lives) and (2) your artifact repository (the built site with core, contrib, files, etc, ready to run).

Using your normal text editor open the aquifer.json file
The part we want to focus on here is the extensions.

In a new project, this reads:


  "extensions": {},

"extensions": {},

We need to update this to add the aquifer-git extension:


"extensions": {
  "aquifer-git": {
    "source": "aquifer/aquifer-git#1.0.0",
    "remote": "{copy and paste your git connection info from pantheon here}",
    "branch": "master"
  }
},

"extensions": {

"aquifer-git": {

"source": "aquifer/aquifer-git#1.0.0",

"remote": "{copy and paste your git connection info from pantheon here}",

"branch": "master"

}

The code block above will deploy directly to Pantheon. If you would like to deploy to GitHub first instead change the remote info to point to your GitHub repository.

Additional details about the aquifer-git configuration:

On this line:


"source": "aquifer/aquifer-git#1.0.0",

"source": "aquifer/aquifer-git#1.0.0",

We are specifically telling aquifer we want to use the 1.0.0 branch of the aquifer-git extension which is the latest development version as of the writing of this article.

On this line:


"remote": "{copy and paste your git connection info from Pantheon here}",

"remote": "{copy and paste your git connection info from Pantheon here}",

By doing this, you add the ability to deploy your Aquifer project to the specified Pantheon remote. A Pantheon remote string should look something like this:


ssh://codeserver.dev.hash@codeserver.dev.hash.drush.in:2222/~/repository.git

ssh://codeserver.dev.hash@codeserver.dev.hash.drush.in:2222/~/repository.git

But don’t limit your imagination. The remote can be another directory on your local machine, a GitHub repository, or another remote host.

On this line:


"branch": "master"

"branch": "master"

We specify that aquifer-git will default to using the master branch.

NOTE: On Acquia you may need to set (SUPER UNTESTED – YOU SHOULD RESEARCH):


"folder": "docroot",

"folder": "docroot",

For additional information on configuring aquifer-git, see the README.

You now need to run aquifer extensions-load to download and install the new extension.

Once the extensions have loaded, you are ready to start deploying. Make sure your ssh keys are setup and type:


aquifer deploy-git

aquifer deploy-git

If this command succeeds then you now have a working Aquifer project on Pantheon. If you didn’t deploy straight to Pantheon you will have some additional configuration here.

Next Steps

Setup your database

If you haven’t already this would be a good time to setup your database.

Transfer your files

If you haven’t already this would be a good time to transfer your files.

Editing settings.php

OPTIONAL – EVERYTHING BELOW IS UNTESTED CODE IN DEMO

You may wish to separate out your Pantheon configuration in a separate settings.php file named pantheon.settings.php. If so, you will need to add the following to your aquifer.json file:


"settings/pantheon.settings.php": {
  "destination": "sites/default/pantheon.settings.php",
  "method": "symlink",
  "conflict": "overwrite"
},

"settings/pantheon.settings.php": {

"destination": "sites/default/pantheon.settings.php",

"method": "symlink",

"conflict": "overwrite"

If you choose to implement a new file for Pantheon settings then you will need to alter your settings.php file to include the following right before your normal last code block implementing local.settings.php:


// All Pantheon Environments.
if (defined('PANTHEON_ENVIRONMENT')) {
  include DRUPAL_ROOT . '/sites/default/pantheon.settings.php';
}
else {
  // We are not on a pantheon environment. This is for local.
}

// All Pantheon Environments.

if (defined('PANTHEON_ENVIRONMENT')) {

include DRUPAL_ROOT . '/sites/default/pantheon.settings.php';

}

else {

// We are not on a pantheon environment. This is for local.

}

In your master module configuration you may wish to include pantheon specific modules like pantheon_apachesolr for dev, test, and live.

Congratulations

If you made it here, you rock!

Additional tech review by Jeff Tomlinson.

Howdy, perfers! Last week I went through the process of generating critical CSS using Gulp and an npm module called critical. The big caveat is that Critical doesn’t currently offer out-of-the-box support for remote URLs, which is the most convenient option for dynamic sites (including the one you’re reading). However, there are tools available for this. I’ll walk you through the complete process of generating and inlining critical CSS, then further modifying your Drupal 7 site to remove all render-blocking assets from the head of your theme.

Generate critical CSS with grunt-criticalcss

This time we’ll use grunt-criticalcss, a different npm module that does the same task as Critical. The feature we’re interested in is the ability to analyze a remote URL. Since pages of a dynamic CMS such as Drupal or WordPress are accessible only via URL, critical requires an extra step involving saving the HTML to disk if you wish to analyze your live site. Not so with grunt-criticalcss.

Read grunt-criticalcss docs

Our blog has been using Grunt for a couple years so it’s a great example for this walkthrough. Here’s the configuration of our Gruntfile.js which is inside our primary theme. If you are new to Grunt, go ahead and consult the getting started guide before continuing with this article.

grunt.initConfig({
  criticalcss: {
    home: {
      options: {
        url: 'http://fourword.dev',
        width: 1400,
        height: 900,
        filename: 'css/style.css',
        outputfile: 'css/critical-home.css'
      }
    },
    article: {
      options: {
        url: 'http://fourword.dev/article/fix-scrolling-performance-css-will-change-property',
        width: 1400,
        height: 900,
        filename: 'css/style.css',
        outputfile: 'css/critical-article.css'
      }
    }
  }
});

grunt.initConfig({

criticalcss: {

home: {

options: {

url: 'http://fourword.dev',

width: 1400,

height: 900,

filename: 'css/style.css',

outputfile: 'css/critical-home.css'

}

article: {

options: {

url: 'http://fourword.dev/article/fix-scrolling-performance-css-will-change-property',

width: 1400,

height: 900,

filename: 'css/style.css',

outputfile: 'css/critical-article.css'

}

});

We can define as many implementations of the task as we want. In this case I’m creating unique versions of the critical CSS for our homepage and an article. Since this optimization is primarily for first-time visitors, check your analytics to determine your site’s most common entry points. A brief explanation of each option:

home/article define each subtask. You can run them all in sequence by calling grunt criticalcss, or specifying a particular subtask by including its name prefixed with a colon: grunt criticalcss:home. When running the task, you will see them in the console output as criticalcss:home or criticalcss:article.
url is the URL that will be fetched. You could use your live site, but I have specified a local environment so I can run this against my current branch while developing. Whatever URL you choose, the HTML will be paired with the CSS specified in filename options and then rendered using PhantomJS.
width and height define the viewport size that should be considered “critical” — that is, only styles which apply to elements visible within this window will be output in our final file. Although this optimization makes a bigger difference on mobile devices, setting a larger viewport normally works out just fine, producing a small enough file.
filename points Grunt to a local copy of your CSS which serves as the original CSS to work off of. The docs don’t mention file globbing and a bit of experimentation indicated that this must be a single, pre-existing file.
outputfile defines where Grunt should place the critical CSS. Since this is task is run inside a Drupal theme, a relative path of css/critical-TYPE is all that is needed to put it in a convenient place for inclusion.

As mentioned in the previous article, there are issues you need to watch out for within your inline CSS, or it might actually have a negative impact on page load performance. Read the caveats about critical CSS filesize and render-blocking styles if you’re not familiar already.

Use a Drupal hook to inline your styles

There’s no single method for adding this code to Drupal. It depends on how your site is set up so I leave it to your discretion. Our example will use THEME_preprocess_page():

function fourword_theme_preprocess_page(&$vars) {
  //
  // Inline critical CSS
  // First, define the options for drupal_add_css();
  //
  $critical_css_options = array(
    'type' => 'inline',
    'scope' => 'header',
    'group' => CSS_SYSTEM,
    'weight' => -1000,
    'preprocess' => FALSE,
  );

  // Determine which file to inline.
  if ($vars['is_front'] == TRUE) {
    $critical_css_file = 'critical-home.css';
  }
  else {
    $critical_css_file = 'critical-article.css';
  }

  // Inline the CSS
  drupal_add_css(file_get_contents(drupal_get_path('theme', 'fourword_theme') . '/css/' . $critical_css_file), $critical_css_options);
}

function fourword_theme_preprocess_page(&$vars) {

// Inline critical CSS

// First, define the options for drupal_add_css();

$critical_css_options = array(

'type' => 'inline',

'scope' => 'header',

'group' => CSS_SYSTEM,

'weight' => -1000,

'preprocess' => FALSE,

);

// Determine which file to inline.

if ($vars['is_front'] == TRUE) {

$critical_css_file = 'critical-home.css';

}

else {

$critical_css_file = 'critical-article.css';

}

// Inline the CSS

drupal_add_css(file_get_contents(drupal_get_path('theme', 'fourword_theme') . '/css/' . $critical_css_file), $critical_css_options);

}

There is great documentation for drupal_add_css() but let me explain the reason for this specific configuration:

type should be 'inline' — that is the goal after all!
scope determines whether the CSS will appear within the <head> or near the bottom of the closing </body> tag.
group is the next sorting mechanism. For all assets with a particular scope, Drupal then looks at their group, which are output from lowest to highest number. CSS_SYSTEM is a Drupal constant for defining CSS aggregates. This constant tells Drupal that you want this CSS to be in the first group, typically reserved for CSS that comes from Drupal core.
weight is the next number considered when ordering the CSS aggregates. Within each group, the weight of each file is sorted from lowest to highest. A weight of -1000 is extreme, but normally means you’ll see your inline CSS showing up first above anything else.
preprocess instructs Drupal to skip the step where it would check if it should combine this file with any other CSS files within the site. It’s less likely to happen with inline files, but setting this to FALSE ensures that it won’t ever happen.

From there, we do a quick conditional within PHP to see if we’re loading the homepage or not by checking the is_front variable within $vars. The homepage has its own set of inline styles that we defined in the Gruntfile, remember? Finally, the drupal_add_css() command informs Drupal about our CSS.

Be sure to use that file_get_contents() command! If you omit that function, the inline styles will simply be the path to your file. Read more about this technique in the context of one-off JavaScript within Drupal. It lets you manage separate CSS/JS files but still gain the benefits of inlining.

Configure AdvAgg module to optimize CSS/JS

Ok, we’re getting there! These steps are crucial: removing render-blocking assets from the <head> and allowing CSS to be loaded in an asynchronous manner. If you stopped before making these changes, the <link> and <script> tags would remain in the head of your document, and they would block rendering until their contents were fetched.

Luckily the process is straightforward if you use the Advanced CSS/JS Aggregation Drupal module, the go-to solution for serious frontend performance problems on a Drupal 7 site.

Note: we’re using AdvAgg 7.x-2.14 for these instructions and screenshots. Past or future releases might present different configuration options.

Enable AdvAgg modules

AdvAgg, as it’s nicknamed, contains almost all the options you could ever ask for in terms of frontend performance for Drupal 7. It even includes configuration to use Filament Group’s loadCSS script in a safe, automated fashion. It will work with your aggregates, so you can still let Drupal combine your theme’s CSS with other modules’ styles.

First, enable advagg, advagg_bundler, and advagg_mod. These are, respectively, the main module, a submodule to alter how CSS/JS is bundled together, and a submodule to modify how these bundles are positioned within the HTML and loaded.

Log in as a user with appropriate admin permissions and navigate to /admin/config/development/performance/advagg. On the Configure tab, uncheck the following option under Global Options:

Ensure that Enable advanced aggregation is checked
Ensure that Use cores grouping logic is NOT checked

Reduce CSS bundles

Your next stop will be the Bundler tab. Although this step is optional, I find it’s very effective at eliminating the numerous aggregates that Drupal creates in a common site that uses ctools, Views, and so forth. Configure as follows:

Ensure the Bundler is Active setting is enabled.
Set the Target Number Of CSS Bundles Per Page setting to 1.

Restricting bundles can be complicated, so be sure to check a few different types of pages and ensure that the same aggregate appears on each page for anonymous users. If the aggregates aren’t consistent across pages, your visitors cannot reuse cached styles. When this happens, increase the CSS bundles until you observe some aggregates which are common to your pages, or simply skip this step and disable the Bundler.

If you really want to troubleshoot it, consider using the Information tab to identify which styles are being added within a given aggregate, and write some rules to suppress them for anonymous users. I’ve written a separate article dedicated to troubleshooting your aggregates using the Detailed Information tool, using this tutorial as context for the process.

Move all JavaScript to the bottom of the page

Moving on to the Modifications tab, we will make a few changes here. Since our goal is to remove all render-blocking assets from the <head> of our HTML, moving JavaScript to the bottom of the page is a necessary step in the process.

Just a heads-up, this is not always a safe operation. If you have written JS within your markup, and that JS expects jQuery to exist, this will break your JavaScript. Hopefully though, you have written your JS so that it can be safely moved to the footer. If you haven’t, it would be a whole different post to describe the reasons behind and process of fixing the JS.

If all of your custom JS is written using IIFEs that accept Drupal and jQuery as parameters, you’re most likely ok. Just make sure it isn’t being added directly into your HTML, and is only being included using drupal_add_js(). Furthermore, check that you aren’t relying on any modules which write JavaScript to the page with the implicit expectation that jQuery exists.

Find the Adjust JavaScript location and execution section and adjust the following setting:

Set Move JS to the footer to All (might break things).

Load CSS asynchronously

Stay on the Modifications tab; we’ve got a bit more work to do. Scroll down until you see the Adjust CSS location and execution section. This is where we enable the built-in copy of Filament Group’s loadCSS library and ask AdvAgg to use it to load all aggregates. Adjust the following settings:

Set Deferred CSS Execution: Use JS to load CSS to All in footer except for JS loading code (If enabled this is recommended).
Set How to include the JS loading code to Inline javascript loader library (If enabled this is recommended).

After saving the settings you’ll probably need a cache clear, but if all goes well, you’ll be left with two things in your <head>: the inline CSS generated by Grunt, and a small block of inline JS which will be used to load the remaining assets. Since neither of these make external requests, the browser doesn’t have to wait to render anything when it first consumes the page’s HTML.

Test your fine work

Whew! We made it. Try running PageSpeed Insights or WebPageTest.org on your new configuration to see how it performs. That PageSpeed link is for this site, which went from 79 to 97 based on the optimizations described in this article! o/

Additionally, WebPageTest reported a First Paint time that was 3.5 seconds sooner. That’s 3.5s less time spent staring at a blank, white screen. In the data below you might notice that we actually increased our total payload by a couple KB, but we loaded everything in a manner that lets the browser show content more quickly. That approach is very beneficial to our visitors, so WebPageTest factors that into its scores.

Check out the following data for yourself. I ran the test twice because because Test 1 was not an identical test. I accidentally used a lower-powered device, but despite that it still showed a massive improvement. I ran Test 2 using the exact same device/connection to get a true delta. Luckily, the three tests have a strikingly similar TTFB within 0.03 seconds of each other, so these numbers are indeed a fair comparison across the board.

Conditions	Total KB	TTFB	Speed Index	First paint	Test data
Moto G – 3G, render-blocking	489 KB	0.592s	4614	4.511s	📊
Moto E – 3G, inline + async	491 KB	0.599s	1902	1.090s	📊
Moto G – 3G, inline + async	491 KB	0.619s	1442	0.973s	📊

Remember, it’s important to test using a remote server. In our case it was a snap because we use Pantheon’s CI workflow to test our code against the live database before deploying. Since the test environment is identical to production, it allows us to easily see how our changes will perform once they’re deployed.

Making further improvements

I’ll be the first to say our implementation isn’t perfect, but it gives you a good idea of how dramatically the initial page load can be improved. Since the majority of our blog’s traffic comes from folks arriving at individual articles, it’s a step in the right direction. Further improvements could be made by eliminating our brief FOIT using a font observer.

Additionally, we could set and check a cookie, so that the asynchronous loading only happens on a fresh session. If a user continues to browse around the site, it can intelligently switch back to regular <link> tags since the CSS files will be cached after the initial page load. For the typical Drupal site this involves tweaking Varnish and a few other Drupal settings, so that will have to wait for another day.

Tell me the trade-offs

You knew it was coming… here are some side-effects. I leave it to the reader to decide whether they are negative or not.

The most obvious is the FOUC which is manifest most commonly when fonts take a moment to load. If you’re in the camp that gets really irked by the FOUT before fonts load in, then I would say just undo all your work and go back to render-blocking fonts. However, be aware that sync fonts can cause many problems. This past Monday, TypeKit had downtime which left text invisible on many sites. Progressively enhancing text by async-loading fonts should be considered a core feature of the web platform, not a visual problem that needs to be avoided.

This is a Drupal-specific one, but when you’re logged in as an admin, this technique will sometimes cause the UI styles to load in a noticeably fragmented manner. Again, it’s just a consequence of all the CSS being loaded asynchronously bit by bit. I’m not aware of a configuration option in AdvAgg to restrict optimizations to a specific theme. So if it bothers your editors then perhaps setting up loadCSS manually to affect your public styles only is your best option.

Hopefully this walkthrough was useful to you. If you got a huge boost from following this tutorial drop a link to your site in the comments so we can see your implementation.

Hello again, RESTful friends. Welcome to episode II, The RESTful strikes back, the great RESTful caper, RESTful II SUBPROPERTY BOOGALOO.

In this series we are exploring the RESTful module (7.x-1.x), a wonderful project that will help you turn your Drupal 7 site into an API-serving headless machine. Last week we did the hard work of creating a basic endpoint with the RESTful module. We created a content type and added several fields and through a very small amount of code we were able to output content from Drupal into beautiful JSON. I will assume that you have completed the first tutorial and have a working code base.

In this week’s tutorial we are going to look at adding fields (multi-line text fields like “body” and the link field) with sub properties to our RESTful endpoint.

A `body` at REST

While we were able to output several different types of fields in our endpoint we skipped the body field. This week we’ll take care of that. The body field is one of a number of fields that need a little bit more care when utilized in a RESTful endpoint because it has a complex implementation.

Recall from last week’s tutorial that we created a custom module with a ctools plugin that defined our endpoint. We had a content type with the following fields:


field_artist_year_formed
field_artist_country_of_origin
field_artist_rnr_hall_of_fame
body
name

field_artist_year_formed

field_artist_country_of_origin

field_artist_rnr_hall_of_fame

body

name

In our endpoint we expressed each field in the following format (allowing for different field names and properties):

$public_fields['yearFormed'] = array(
  'property' => 'field_artist_year_formed',
);

$public_fields['yearFormed'] = array(

'property' => 'field_artist_year_formed',

);

Fields like the body field, and really all multi-line text fields (you might refer to them as wysiwyg fields), have several values: the raw value of the field before any text formatting happens, the formatted version with text processing, the format being used and perhaps even a summary value. This is a lot more complex than many of the other fields we dealt with last week.

Let’s try to add the body field to our endpoint in the same way that we added simpler fields and see what happens in our endpoint.

// Example only, don't use this.
$public_fields['description'] = array(
  'property' => 'body',
);

// Example only, don't use this.

$public_fields['description'] = array(

'property' => 'body',

);

That produces some pretty interesting results:

{
  "data":[
    {
      "id":"4",
      "label":"My Bloody Valentine",
      "self":"http://resteasy.local.dev/api/v0.1/artists/4",
      "yearFormed":"1983",
      "countryOfOrigin":"Ireland",
      "rockAndRollHallOfFameInductee":false,
      "description": {
        "value":"My Bloody Valentine are an alternative rock band formed in Dublin, Ireland in 1983. Since 1987, the bandu0027s lineup has consisted of founding members Kevin Shields (vocals, guitar) and Colm u00d3 Cu00edosu00f3ig (drums), with Bilinda Butcher (vocals, guitar) and Debbie Googe (bass). The group is known for their integration of distorted noise and ethereal melody, and for their innovative utilization of unorthodox guitar and production techniques. Their work in the late 1980s and early 1990s resulted in their pioneering a musical style known as shoegazing.rnrn(from https://en.wikipedia.org/wiki/My_Bloody_Valentine_%28band%29)",
        "summary":"My Bloody Valentine are an alternative rock band formed in Dublin, Ireland in 1983",
        "format":"filtered_html",
        "safe_value":"u003Cpu003EMy Bloody Valentine are an alternative rock band formed in Dublin, Ireland in 1983. Since 1987, the bandu0027s lineup has consisted of founding members Kevin Shields (vocals, guitar) and Colm u00d3 Cu00edosu00f3ig (drums), with Bilinda Butcher (vocals, guitar) and Debbie Googe (bass). The group is known for their integration of distorted noise and ethereal melody, and for their innovative utilization of unorthodox guitar and production techniques. Their work in the late 1980s and early 1990s resulted in their pioneering a musical style known as shoegazing.u003C/pu003Enu003Cpu003E(from u003Ca href=u0022https://en.wikipedia.org/wiki/My_Bloody_Valentine_%28band%29u0022u003Ehttps://en.wikipedia.org/wiki/My_Bloody_Valentine_%28band%29u003C/au003E)u003C/pu003En",
        "safe_summary":"u003Cpu003EMy Bloody Valentine are an alternative rock band formed in Dublin, Ireland in 1983u003C/pu003En"
      }
    }
  ],
  "self":{
    "title":"Self",
    "href":"http://resteasy.local.dev/api/v0.1/artists/4"
  }
}

{

"data":[

{

"id":"4",

"label":"My Bloody Valentine",

"self":"http://resteasy.local.dev/api/v0.1/artists/4",

"yearFormed":"1983",

"countryOfOrigin":"Ireland",

"rockAndRollHallOfFameInductee":false,

"description": {

"value":"My Bloody Valentine are an alternative rock band formed in Dublin, Ireland in 1983. Since 1987, the bandu0027s lineup has consisted of founding members Kevin Shields (vocals, guitar) and Colm u00d3 Cu00edosu00f3ig (drums), with Bilinda Butcher (vocals, guitar) and Debbie Googe (bass). The group is known for their integration of distorted noise and ethereal melody, and for their innovative utilization of unorthodox guitar and production techniques. Their work in the late 1980s and early 1990s resulted in their pioneering a musical style known as shoegazing.rnrn(from https://en.wikipedia.org/wiki/My_Bloody_Valentine_%28band%29)",

"summary":"My Bloody Valentine are an alternative rock band formed in Dublin, Ireland in 1983",

"format":"filtered_html",

"safe_value":"u003Cpu003EMy Bloody Valentine are an alternative rock band formed in Dublin, Ireland in 1983. Since 1987, the bandu0027s lineup has consisted of founding members Kevin Shields (vocals, guitar) and Colm u00d3 Cu00edosu00f3ig (drums), with Bilinda Butcher (vocals, guitar) and Debbie Googe (bass). The group is known for their integration of distorted noise and ethereal melody, and for their innovative utilization of unorthodox guitar and production techniques. Their work in the late 1980s and early 1990s resulted in their pioneering a musical style known as shoegazing.u003C/pu003Enu003Cpu003E(from u003Ca href=u0022https://en.wikipedia.org/wiki/My_Bloody_Valentine_%28band%29u0022u003Ehttps://en.wikipedia.org/wiki/My_Bloody_Valentine_%28band%29u003C/au003E)u003C/pu003En",

"safe_summary":"u003Cpu003EMy Bloody Valentine are an alternative rock band formed in Dublin, Ireland in 1983u003C/pu003En"

}

"self":{

"title":"Self",

"href":"http://resteasy.local.dev/api/v0.1/artists/4"

}

That’s quite a difference. We have many different pieces of information as part of the description. What does this information look like to you? If you said Drupal implementation details you’d be right.

In REST Easy part 1 we talked about some of the dangers of exposing implementation details to your API consumers. API consuming applications and developers are going to make assumptions and use all of the parts of your API that you expose. Let’s say (and we know it will) that implementations change between major Drupal versions or even minor ones, the types of items that are included in this wide and generic body field might change as well and that could lead to a broken API or more work when we upgrade our back-end and that’s not a very good thing.

So how can we target some of this information without getting the implementation details of this field? Well, for fields with sub-properties like these, we need to specify which “sub-property” of the field we want in our endpoint. We do that with code like this:

$public_fields['description'] = array(
  'property' => 'body',
  'sub_property' => 'value',
);

$public_fields['description'] = array(

'property' => 'body',

'sub_property' => 'value',

);

And that will give us this less implementation details based response:

{
  "data": [
    {
      "id":"4",
      "label":"My Bloody Valentine",
      "self":"http://resteasy.local.dev/api/v0.1/artists/4",
      "yearFormed":"1983",
      "countryOfOrigin":"Ireland",
      "rockAndRollHallOfFameInductee":false,
      "description":"u003Cpu003EMy Bloody Valentine are an alternative rock band formed in Dublin, Ireland in 1983. Since 1987, the bandu0027s lineup has consisted of founding members Kevin Shields (vocals, guitar) and Colm u00d3 Cu00edosu00f3ig (drums), with Bilinda Butcher (vocals, guitar) and Debbie Googe (bass). The group is known for their integration of distorted noise and ethereal melody, and for their innovative utilization of unorthodox guitar and production techniques. Their work in the late 1980s and early 1990s resulted in their pioneering a musical style known as shoegazing.u003C/pu003Enu003Cpu003E(from u003Ca href=u0022https://en.wikipedia.org/wiki/My_Bloody_Valentine_%28band%29u0022u003Ehttps://en.wikipedia.org/wiki/My_Bloody_Valentine_%28band%29u003C/au003E)u003C/pu003En"
    }
  ],
  "self": {
    "title":"Self",
    "href":"http://resteasy.local.dev/api/v0.1/artists/4"
  }
}

{

"data": [

{

"id":"4",

"label":"My Bloody Valentine",

"self":"http://resteasy.local.dev/api/v0.1/artists/4",

"yearFormed":"1983",

"countryOfOrigin":"Ireland",

"rockAndRollHallOfFameInductee":false,

"description":"u003Cpu003EMy Bloody Valentine are an alternative rock band formed in Dublin, Ireland in 1983. Since 1987, the bandu0027s lineup has consisted of founding members Kevin Shields (vocals, guitar) and Colm u00d3 Cu00edosu00f3ig (drums), with Bilinda Butcher (vocals, guitar) and Debbie Googe (bass). The group is known for their integration of distorted noise and ethereal melody, and for their innovative utilization of unorthodox guitar and production techniques. Their work in the late 1980s and early 1990s resulted in their pioneering a musical style known as shoegazing.u003C/pu003Enu003Cpu003E(from u003Ca href=u0022https://en.wikipedia.org/wiki/My_Bloody_Valentine_%28band%29u0022u003Ehttps://en.wikipedia.org/wiki/My_Bloody_Valentine_%28band%29u003C/au003E)u003C/pu003En"

}

"self": {

"title":"Self",

"href":"http://resteasy.local.dev/api/v0.1/artists/4"

}

1) First, ensure that your body fields in your example content are filled out in Drupal (so there will be something to see in the API).
2) After that, let’s add the body field to our endpoint, but let’s do this in the right way, by adding a new sub version of our endpoint. Last week we created v0.1, so this week let’s create v0.2.

Add the folders and files for `v0.2`

(edit: Please note that because this is a tutorial series, endpoint versions are not uniform as you’d expect them to be with an official version release read the following comments for more info: http://fourword.fourkitchens.com/article/rest-easy-part-4-taxonomy-man#comment-2230720908)

OK – we’ll be starting off with the folder structure we created last week:

Create the following folder and files inside of

plugins/restful/node/artist/

1	plugins/restful/node/artist/

plugins/restful/node/artists/0.2/

1

plugins/restful/node/artists/0.2/
plugins/restful/node/artists/0.2/artists__0_2.inc

1

plugins/restful/node/artists/0.2/artists__0_2.inc
- This will hold our plug-in definitions
plugins/restful/node/artists//0.2/ResteasyRestfulEntityArtistsResource__0_2.class.php

1

plugins/restful/node/artists//0.2/ResteasyRestfulEntityArtistsResource__0_2.class.php
- This is our new 0.2 class file for all of our new additions this week.

Your folder structure should look like this now:

3) Now we can modify our plugin definition file at

plugins/restful/node/artists/0.2/artists__0_2.inc

1	plugins/restful/node/artists/0.2/artists__0_2.inc

and it will look like this:

<?php

/**
 * @file
 * Artists plugin definition.
 */

$plugin = array(
  'label' => t('Artists'),
  'resource' => 'artists',
  'name' => 'artists__0_2',
  'entity_type' => 'node',
  'bundle' => 'artist',
  'description' => t('This resource presents artists from REST easy.'),
  'class' => 'ResteasyRestfulEntityArtistsResource__0_2',
  'major_version' => 0,
  'minor_version' => 2,
);

<?php

/**

* @file

* Artists plugin definition.

$plugin = array(

'label' => t('Artists'),

'resource' => 'artists',

'name' => 'artists__0_2',

'entity_type' => 'node',

'bundle' => 'artist',

'description' => t('This resource presents artists from REST easy.'),

'class' => 'ResteasyRestfulEntityArtistsResource__0_2',

'major_version' => 0,

'minor_version' => 2,

);

4) Our new class file at

plugins/restful/node/artists/0.2/ResteasyRestfulEntityArtistsResource__0_2.class.php

1	plugins/restful/node/artists/0.2/ResteasyRestfulEntityArtistsResource__0_2.class.php

will look like this:

<?php

/**
 * @file
 * Contains ResteasyRestfulEntityArtistsResource__0_2.
 */


/**
 * Implements RestfulEntityBaseNode class for the "artist" content type.
 */
class ResteasyRestfulEntityArtistsResource__0_2 extends RestfulEntityBaseNode {

  /**
   * Overrides RestfulEntityBaseNode::publicFieldsInfo().
   */
  public function publicFieldsInfo() {
    $public_fields = parent::publicFieldsInfo();

    $public_fields['yearFormed'] = array(
      'property' => 'field_artist_year_formed',
    );

    $public_fields['countryOfOrigin'] = array(
      'property' => 'field_artist_country_of_origin',
    );

    $public_fields['rockAndRollHallOfFameInductee'] = array(
      'property' => 'field_artist_rnr_hall_of_fame',
    );

    $public_fields['description'] = array(
      'property' => 'body',
      'sub_property' => 'value',
    );

    return $public_fields;
  }
}

<?php

/**

* @file

* Contains ResteasyRestfulEntityArtistsResource__0_2.

/**

* Implements RestfulEntityBaseNode class for the "artist" content type.

class ResteasyRestfulEntityArtistsResource__0_2 extends RestfulEntityBaseNode {

/**

* Overrides RestfulEntityBaseNode::publicFieldsInfo().

public function publicFieldsInfo() {

$public_fields = parent::publicFieldsInfo();

$public_fields['yearFormed'] = array(

'property' => 'field_artist_year_formed',

);

$public_fields['countryOfOrigin'] = array(

'property' => 'field_artist_country_of_origin',

);

$public_fields['rockAndRollHallOfFameInductee'] = array(

'property' => 'field_artist_rnr_hall_of_fame',

);

$public_fields['description'] = array(

'property' => 'body',

'sub_property' => 'value',

);

return $public_fields;

}

By adding this folder and these files with the new version information we have created a new sub version of our previous endpoint. Now visit your endpoint /api/v0.2/artists and you should see results very similar to mine above.

`body` parts

You have access to some of the sub-properties of the body field. So you can print out the various elements of the body field simply by targetting a different sub property. Here is a list of each of the sub-properties you can access of the multi-line text field, body:

// Don't implement this as a matter of course, always consider good endpoint design. Examples only.

$public_fields['description'] = array(
  'property' => 'body',
  'sub_property' => 'value',
);

$public_fields['shortDescription'] = array(
  'property' => 'body',
  'sub_property' => 'summary',
);

$public_fields['descriptionFormat'] = array(
  'property' => 'body',
  'sub_property' => 'format',
);

// Don't implement this as a matter of course, always consider good endpoint design. Examples only.

$public_fields['description'] = array(

'property' => 'body',

'sub_property' => 'value',

);

$public_fields['shortDescription'] = array(

'property' => 'body',

'sub_property' => 'summary',

);

$public_fields['descriptionFormat'] = array(

'property' => 'body',

'sub_property' => 'format',

);

Sub-properties are part of the implementation of a field in code so you may need to get into the code nitty-gritty to figure out the what’s what and whathaveyous. Notice that safe_value and safe_summary are not available to you. That doesn’t mean you can’t get those values, but that’s yet another tutorial down the road. If you are curious about a field that has subproperties – you can also simply code the field as a simple field in your API and see what’s there and attempt to access it via sub-property, or investigate through dpm or devel. It may or may not work but it won’t take very much time to figure that out.

Let’s take one more look at sub-property use in RESTful with another fairly frequent occurrence, the link field. Let’s add one of those to our content type and put it into our endpoint.

5) Let’s add the link module to our website so we can use a link field.

drush dl link

1	drush dl link

drush pm-enable link

1	drush pm-enable link

6) Save and add the following field to the artist content type (or download the newest release of our helper code base:

https://github.com/fourkitchens/resteasy/releases/tag/resteasy-part-2

1	https://github.com/fourkitchens/resteasy/releases/tag/resteasy-part-2

):
* Artist website
* machine name: field_artist_website
* type – link
* Absolute URL, Validate URL – checked
* Link Title: Required title
* 1 value

Let’s add this new element to our 0.2 endpoint and really value-pack our new end point sub version. Just as we did with the body field let’s see what happens if we output this field just like a normal field. Here is the php to make that happen:

// Example only, don't use this.
$public_fields['artistWebsite'] = array(
  'property' => 'field_artist_website',
);

// Example only, don't use this.

$public_fields['artistWebsite'] = array(

'property' => 'field_artist_website',

);

Here’s what the output will look like:

{
  "data": [
    {
      "id":"3",
      "label":"The Jimi Hendrix Experience",
      "self":"http://resteasy.local.dev/api/v0.2/artists/3",
      "yearFormed":"1966",
      "countryOfOrigin":"USA",
      "rockAndRollHallOfFameInductee":true,
      "description":null,
      "artistWebsite":{
        "url":"http://jimihendrix.com",
        "title":"The Jimi Hendrix Experience",
        "attributes": []
      }
    }
  ],
  "self": {
    "title":"Self",
    "href":"http://resteasy.local.dev/api/v0.2/artists/3"
  }
}

{

"data": [

{

"id":"3",

"label":"The Jimi Hendrix Experience",

"self":"http://resteasy.local.dev/api/v0.2/artists/3",

"yearFormed":"1966",

"countryOfOrigin":"USA",

"rockAndRollHallOfFameInductee":true,

"description":null,

"artistWebsite":{

"url":"http://jimihendrix.com",

"title":"The Jimi Hendrix Experience",

"attributes": []

}

"self": {

"title":"Self",

"href":"http://resteasy.local.dev/api/v0.2/artists/3"

}

Wow, again, pretty cool, but also attached to implementation details or perhaps not the right thing we want to expose. Let’s use sub-properties to expose on the url from the link field.

Yo Dawg, I heard you like subproperties…

Using the sub-property format for this field we can expose only the portions of the field that are relevant or wanted.

Let’s give it a try, by targeting the sub_property of url.

6) Here is the final version of the 0.2 endpoint class file

plugins/restful/node/artists/0.2/ResteasyRestfulEntityArtistsResource__0_2.class.php

1	plugins/restful/node/artists/0.2/ResteasyRestfulEntityArtistsResource__0_2.class.php

with the link url sub property:

<?php

/**
 * @file
 * Contains ResteasyRestfulEntityArtistsResource__0_2.
 */


/**
 * Implements RestfulEntityBaseNode class for the "artist" content type.
 */
class ResteasyRestfulEntityArtistsResource__0_2 extends RestfulEntityBaseNode {

  /**
   * Overrides RestfulEntityBaseNode::publicFieldsInfo().
   */
  public function publicFieldsInfo() {
    $public_fields = parent::publicFieldsInfo();

    $public_fields['yearFormed'] = array(
      'property' => 'field_artist_year_formed',
    );

    $public_fields['countryOfOrigin'] = array(
      'property' => 'field_artist_country_of_origin',
    );

    $public_fields['rockAndRollHallOfFameInductee'] = array(
      'property' => 'field_artist_rnr_hall_of_fame',
    );

    $public_fields['description'] = array(
      'property' => 'body',
      'sub_property' => 'value',
    );

    $public_fields['artistWebsite'] = array(
      'property' => 'field_artist_website',
      'sub_property' => 'url',
    );

    return $public_fields;
  }
}

<?php

/**

* @file

* Contains ResteasyRestfulEntityArtistsResource__0_2.

/**

* Implements RestfulEntityBaseNode class for the "artist" content type.

class ResteasyRestfulEntityArtistsResource__0_2 extends RestfulEntityBaseNode {

/**

* Overrides RestfulEntityBaseNode::publicFieldsInfo().

public function publicFieldsInfo() {

$public_fields = parent::publicFieldsInfo();

$public_fields['yearFormed'] = array(

'property' => 'field_artist_year_formed',

);

$public_fields['countryOfOrigin'] = array(

'property' => 'field_artist_country_of_origin',

);

$public_fields['rockAndRollHallOfFameInductee'] = array(

'property' => 'field_artist_rnr_hall_of_fame',

);

$public_fields['description'] = array(

'property' => 'body',

'sub_property' => 'value',

);

$public_fields['artistWebsite'] = array(

'property' => 'field_artist_website',

'sub_property' => 'url',

);

return $public_fields;

}

Now our endpoint output looks a bit like this:

{
  "data": [
    {
      "id":"3",
      "label":"The Jimi Hendrix Experience",
      "self":"http://resteasy.local.dev/api/v0.2/artists/3",
      "yearFormed":"1966",
      "countryOfOrigin":"USA",
      "rockAndRollHallOfFameInductee":true,
      "description":null,
      "artistWebsite":"http://jimihendrix.com"
    }
  ],
  "self":{
    "title":"Self",
    "href":"http://resteasy.local.dev/api/v0.2/artists/3"
  }
}

{

"data": [

{

"id":"3",

"label":"The Jimi Hendrix Experience",

"self":"http://resteasy.local.dev/api/v0.2/artists/3",

"yearFormed":"1966",

"countryOfOrigin":"USA",

"rockAndRollHallOfFameInductee":true,

"description":null,

"artistWebsite":"http://jimihendrix.com"

}

"self":{

"title":"Self",

"href":"http://resteasy.local.dev/api/v0.2/artists/3"

}

Things are looking pretty good: we’ve got a body field in our endpoint. Because the body field is simply an implementation of a multi-line text field, we can use this exact same formula for any other multi-line text field. We also used sub-properties to target only a portion of the implementation revealed for a link field. Using sub-properties will help you build better targetted and less coupled attributes. There still is a ton of ground to cover, so stick with it and we’ll see you next week for another tutorial and more RESTful!

Over the past few years I’ve had the pleasure of working on some pretty neat decoupled web architectures – notably The Tonight Show with Jimmy Fallon and more recently the launch of the headless Drupal 7 API for TWiT.tv powered by the RESTful module.

I’ve had the opportunity to share some high level thoughts on decoupled architectures at DrupalCon Austin, (See my talk with Andrew Berry of Lullabot on our emmy award winning collaboration with NBC) and my take on API design best practices at DrupalCon LA (API Design: The musical). It was an honor to have those opportunities and I wanted to follow up on both of those talks with some tutorials so that you too could use Drupal to quickly and powerfully serve an API of your own.

An API endpoint Tutorial with Drupal and the RESTful module.

So that brings us to this series: “REST Easy.” In this series I will take you through developing a REST API with Drupal 7 and the RESTful module. We’ll make sure you have a solid foundation and build up the API one step at a time. In this first session I’d like to cover creating an API endpoint for a simple content type in Drupal.

But first, what is the RESTful module?

RESTful is a wonderful little module that provides a solid object oriented base for implementing a REST API in Drupal. I have used both RESTful and services to create APIs and at the moment I prefer to work in RESTful – though the class based PHPoop approach is really vital to both. The maintainers are conscientious, in-tune with API best practices and write quality code. I encourage you to contribute to their project by reporting issues, contributing code in pull requests in GitHub, and most importantly using this great module.

A few assumptions:

You have a working Drupal website. If not, go get yourself one.
You are able to create and deploy custom code to that website.
You have a basic understanding of APIs.

We have a multi-step process that we are going to follow that looks like this:

Get Drupal set-up and the RESTful module installed
Choose or create a content type to use with your API (or use your own)
Add content and ensure your permissions are correct
Create a custom RESTful API module with a plugin exposing the content type from step 2 as an endpoint.
Enable your module and visit your new API!

In our first step we need to download and install the RESTful module from Drupal.org or directly from their github project:

Step 1: Getting Drupal set up with the RESTful module

Download the RESTful module into your Drupal installation (/sites/all/modules/contrib) or install via drush:

drush dl restful ctools entity

1	drush dl restful ctools entity

Now enable the RESTful module via the Drupal admin UI, or use drush:

drush en restful

1	drush en restful

Drush will prompt you with the following question:

The following extensions will be enabled: restful, entity, ctools
Do you really want to continue? (y/n):

1 2	The following extensions will be enabled: restful, entity, ctools Do you really want to continue? (y/n):

Answer “yes”!

Now that we have enabled the RESTful module let’s configure it for use, starting with permissions: (/admin/people/permissions#module-restful). Please note: Just ensure that only your admin roles can administer the RESTful module.

Now let’s take a look at the RESTful configuration page. We aren’t going to touch anything today (don’t worry we’ll take a look in the weeks to come) – just showing you where it is and the options you have available (/admin/config/services/restful).

Take a look around, open up the advanced options tab, but like I said, let’s just leave this as it is for now.

Now let’s create a simple content type to use with the API. For the purposes of this series I am going to construct content types, taxonomies and other entities around a fictitious music site. However, your API could serve your existing blog posts, or classes, books, recipes or really whatever you like.

Note, you can:

Create these content types by hand OR
Download a module containing a feature with this content type from my github repo Rest Easy for this series OR
Use your own content type (ignore step 2 – but obviously you’ll have to have your wits about you and rename things as we go.)

Step 2: Create a simple content type

Start by navigating to admin/structure/types/add within your Drupal admin UI. Let’s create a content type called: ** Artist**

Turn off commenting
Rename the title field to: “name”
Save and add the following fields:
Year formed
machine name: field_artist_year_formed
type – integer
1 value
Country of Origin
machine name: field_artist_country_of_origin
type: text
plain text
1 value
Rock and Roll Hall of Fame
machine name: field_artist_rnr_hall_of_fame
type: boolean
1 value

At this point you should have the following fields (the body field came a long for free):

We now need to make sure that we have good permissions and that we have some content to serve from the API.

Step 3 – Ensure permissions and add content

Now is a good point to do the following:

Set the edit permissions for your new content type at /admin/people/permissions.
Check that anonymous site visitors can see published content.

RESTful anonymous viewers can view content

If you are following along with the Artist content type here is some data to help you add four artists to our site at /node/add/artist:

Name	Body	Year Formed	Country of Origin	Rock and Roll Hall of Fame
The Beatles	{left blank}	1960	England	Yes
Chuck Berry	{left blank}	1955	USA	Yes
The Jimi Hendrix Experience	{left blank}	1966	USA	Yes
My Bloody Valentine	{left blank}	1983	Ireland	No

OK, all of that hopefully looked pretty much like all the Drupal you’ve done before. Now it’s time to get RESTful. In this next step we are going to create a custom module for our API.

Step 4 Creating a Custom RESTful module.

Create a folder inside of /sites/all/modules/custom called myresteasy_api
Create several files inside of myresteasy_api. These first two belong in any custom module.
myresteasy_api.info
myresteasy_api.module
Now lets create some restful/ctools folder structures. Create the following folders:
plugins – used to organize ctools plugins
plugins/restful – used to organize plugins as belonging to the restful module
plugins/restful/node – further organization to group entities by entity type – in this case nodes.
plugins/restful/node/artists – the name of our first restful plugin. Notice I went with the plural form of the word artist, for endpoints, that is a best practice.
Now we will create a folder and two files inside of the artists folder which will help us define our first RESTful plugin.
plugins/restful/node/artists/0.1/
plugins/restful/node/artists/0.1/artists__0_1.inc – This will hold our plug in definitions
plugins/restful/node/artists/0.1/ResteasyRestfulEntityArtistsResource.class.php

1

plugins/restful/node/artists/0.1/ResteasyRestfulEntityArtistsResource.class.php

– This will hold an implementation of the Restful Entity Resource class specific to our endpoint. Sure it’s a bit long winded, but the verbosity might pay off in the the debugging stack.

It should look something like this when you are done:

RESTful artists folder structure

Now let’s add the code we need to serve out our endpoint. Let’s start with the .info file, a good place to start for any Drupal module:

name = My REST Easy API
description = The REST Easy API
core = 7.x
dependencies[] = restful

name = My REST Easy API

description = The REST Easy API

core = 7.x

dependencies[] = restful

Now let’s add in the necessary code for the .module file. This file won’t have much in it (YET) – but we do need to let ctools know where to find our plugins.

<?php
/**
 * @file
 * Module file for Rest EASY API.
 */

/**
 * Implements hook_ctools_plugin_directory().
 */
function myresteasy_api_ctools_plugin_directory($module, $plugin) {
  if ($module == 'restful') {
    return 'plugins/' . $plugin;
  }
}

<?php

/**

* @file

* Module file for Rest EASY API.

/**

* Implements hook_ctools_plugin_directory().

function myresteasy_api_ctools_plugin_directory($module, $plugin) {

if ($module == 'restful') {

return 'plugins/' . $plugin;

}

Easy enough. How about we get on to the real heart of it then. The plugin itself. We have two files here, our plugin definition: artists__0_1.inc and our class file:

ResteasyRestfulEntityArtistsResource.class.php.

1	ResteasyRestfulEntityArtistsResource.class.php.

Let’s start with our plugin definition file. This is where we tell Restful through a ctools plugin definition how we want our RESTful endpoint to behave and what properties it will possess. You can find a full rundown of all of the array elements in the plugin definition in the comments of the restful module at: includes/RestfulManager.php. Be assured, however, that we will be digging back into plugin definitions over the course of our tutorials.

For now we only need concern ourselves with the following:

<?php

/**
 * @file
 * Artists plugin definition.
 */

$plugin = array(
  'label' => t('Artists'),
  'resource' => 'artists',
  'name' => 'artists__0_1',
  'entity_type' => 'node',
  'bundle' => 'artist',
  'description' => t('This resource presents artists from REST easy.'),
  'class' => 'ResteasyRestfulEntityArtistsResource',
  'major_version' => 0,
  'minor_version' => 1,
);

<?php

/**

* @file

* Artists plugin definition.

$plugin = array(

'label' => t('Artists'),

'resource' => 'artists',

'name' => 'artists__0_1',

'entity_type' => 'node',

'bundle' => 'artist',

'description' => t('This resource presents artists from REST easy.'),

'class' => 'ResteasyRestfulEntityArtistsResource',

'major_version' => 0,

'minor_version' => 1,

);

In our plugin we have these attributes:

label – This is a plain text common language label for the endpoint.
resource – this is the name of our endpoint, we’re using artists for this example. It is best practice for endpoints to be nouns and for them to be plural. Purists will argue that these can actually be named anything at all if your API is truly RESTful with good HATEOAS. The resource name relates to your endpoint URL directly – thus our endpoint will be at: /api/v0.1/artists
name – this is the name of your plugin definition.
entity_type – For us, right now, we are making a node endpoint, and thus – node.
bundle – the machine name of our our content type.
description – A textual description of our API endpoint that will be visible to API consumers that visit the API discovery resource (per best practice)
class – The name of our implementing class. This should correspond to the name of our class file (everything pre .class.php and thus –

ResteasyRestfulEntityArtistsResource.class.php

1

ResteasyRestfulEntityArtistsResource.class.php

becomes

ResteasyRestfulEntityArtistsResource

1

ResteasyRestfulEntityArtistsResource
major_version – This field and the minor_version work together to help version your API. This attribute determines the first number (x) in this pattern {x}.{y} i.e. the number 1 in 1.0.
minor_version – This field and the major_version work together to help version your API. This attribute determines the second number (y) in this pattern {x}.{y} i.e. the number 2 in 1.2.
A note on API versioning:* This is quite important, in fact, it works in step with your over all plan for API versioning. Your approach to this process (something for a future post) is your contract with your user base, be careful here and try to get it right the very first time. From the perspective of your API consumers, they are going to build software to consume your API at a specfic version and are going to depend on attributes and features. As an API implementer that means you need to work out your endpoints ahead of time and not alter them adhoc. Now, you could have some play, depending on your community and your hateoas approach – perhaps you can offer additional relationships or attributes but no changes to existing attributes within versions or perhaps that would be intolerable, regardless, definitely avoid removing established attributes once a version has been released.

Almost there everybody, let’s take a look at the class file. This can be quite a rich space for local implementation differences, but for now we really only need to define one function in our class, the publicFieldsInfo() function.

<?php

/**
 * @file
 * Contains ResteasyRestfulEntityArtistsResource__0_1.
 */


/**
 * Implements RestfulEntityBaseNode class for the "artist" content type.
 */
class ResteasyRestfulEntityArtistsResource extends RestfulEntityBaseNode {

  /**
   * Overrides RestfulEntityBaseNode::publicFieldsInfo().
   */
  public function publicFieldsInfo() {
    $public_fields = parent::publicFieldsInfo();

    $public_fields['yearFormed'] = array(
      'property' => 'field_artist_year_formed',
    );

    $public_fields['countryOfOrigin'] = array(
      'property' => 'field_artist_country_of_origin',
    );

    $public_fields['rockAndRollHallOfFameInductee'] = array(
      'property' => 'field_artist_rnr_hall_of_fame',
    );

    return $public_fields;
  }
}

<?php

/**

* @file

* Contains ResteasyRestfulEntityArtistsResource__0_1.

/**

* Implements RestfulEntityBaseNode class for the "artist" content type.

class ResteasyRestfulEntityArtistsResource extends RestfulEntityBaseNode {

/**

* Overrides RestfulEntityBaseNode::publicFieldsInfo().

public function publicFieldsInfo() {

$public_fields = parent::publicFieldsInfo();

$public_fields['yearFormed'] = array(

'property' => 'field_artist_year_formed',

);

$public_fields['countryOfOrigin'] = array(

'property' => 'field_artist_country_of_origin',

);

$public_fields['rockAndRollHallOfFameInductee'] = array(

'property' => 'field_artist_rnr_hall_of_fame',

);

return $public_fields;

}

The publicFieldsInfo property is where we define the attributes we would like to in our custom endpoint. Here we can do things like name the attributes of our endpoint with custom names. Why not just expose the field names and be done with it? Well, that would exposing an implementation detail and which is not good API design. That would tend to couple our API with this specific implementation. Things may change in the backend out of necessity but developers who are using your API don’t care about that; they care about the applications they built and that those applications continue to work. If you choose and keep the same semantic well-named attributes you can change implementation details all you want and those apps will keep on running.

We add the fields to the public fields array by defining a new array item with our desired name with a ‘property’ attribute set to the machine name of the field. Since my intent is to output as JSON I have chosen camelCase:

    $public_fields['yearFormed'] = array(
        'property' => 'field_artist_year_formed',
    );

$public_fields['yearFormed'] = array(

'property' => 'field_artist_year_formed',

);

With all that in place your API is ready to go. Notice that i’ve only chosen text and boolean fields to add to the endpoint. That’s not a comment on the RESTful modules capability more on the format of this blog series (everything in its due time). Also notice that I have not defined a title field. Actually the restful module gives us a couple things for free – like the title and id.

Step 5 – enable the module and visit the API

Now… enable the myresteasy_api module!

Oh, and one more thing: you may need to clear some caches, so if you don’t have drush up and running, maybe now is a good time to start, or head on over to (/admin/config/development/performance).

Clear the cache.
Visit: /api/v0.1/artists

Here you will see the four artists you entered before:

{
    "data": [
        {
            "id":1,
            "label":"The Beatles",
            "self":"http://resteasy.local.dev/api/v0.1/artists/1",
            "yearFormed":"1960",
            "countryOfOrigin":"England",
            "rockAndRollHallOfFameInductee":true
        },
        {
            "id":2,
            "label":"Chuck Berry",
            "self":"http://resteasy.local.dev/api/v0.1/artists/2",
            "yearFormed":"1955",
            "countryOfOrigin":"USA",
            "rockAndRollHallOfFameInductee":true
        },
        {
            "id":3,
            "label":"The Jimi Hendrix Experience",
            "self":"http://resteasy.local.dev/api/v0.1/artists/3",
            "yearFormed":"1966",
            "countryOfOrigin":"USA",
            "rockAndRollHallOfFameInductee":true
        },
        {
            "id":4,
            "label":"My Bloody Valentine",
            "self":"http://resteasy.local.dev/api/v0.1/artists/4",
            "yearFormed":"1983",
            "countryOfOrigin":"Ireland",
            "rockAndRollHallOfFameInductee":false
        }
    ],
    "count":4,
    "self":{
        "title":"Self",
        "href":"http://resteasy.local.dev/api/v0.1/artists"
    }
}

{

"data": [

{

"id":1,

"label":"The Beatles",

"self":"http://resteasy.local.dev/api/v0.1/artists/1",

"yearFormed":"1960",

"countryOfOrigin":"England",

"rockAndRollHallOfFameInductee":true

{

"id":2,

"label":"Chuck Berry",

"self":"http://resteasy.local.dev/api/v0.1/artists/2",

"yearFormed":"1955",

"countryOfOrigin":"USA",

"rockAndRollHallOfFameInductee":true

{

"id":3,

"label":"The Jimi Hendrix Experience",

"self":"http://resteasy.local.dev/api/v0.1/artists/3",

"yearFormed":"1966",

"countryOfOrigin":"USA",

"rockAndRollHallOfFameInductee":true

{

"id":4,

"label":"My Bloody Valentine",

"self":"http://resteasy.local.dev/api/v0.1/artists/4",

"yearFormed":"1983",

"countryOfOrigin":"Ireland",

"rockAndRollHallOfFameInductee":false

}

"count":4,

"self":{

"title":"Self",

"href":"http://resteasy.local.dev/api/v0.1/artists"

}

This is what we call an API listing endpoint.

RESTful gives you both a listing endpoint and individual endpoint as well, such as:

/api/v0.1/artists/1

1	/api/v0.1/artists/1

, which is in the pattern

/api/v0.1/artists/{id}

1	/api/v0.1/artists/{id}

{
    "data": [
        {
            "id":"1",
            "label":"The Beatles",
            "self":"http://resteasy.local.dev/api/v0.1/artists/1",
            "yearFormed":"1960",
            "countryOfOrigin":"England",
            "rockAndRollHallOfFameInductee":true
        }
    ],
    "self":{
        "title":"Self",
        "href":"http://resteasy.local.dev/api/v0.1/artists/1"
    }
}

{

"data": [

{

"id":"1",

"label":"The Beatles",

"self":"http://resteasy.local.dev/api/v0.1/artists/1",

"yearFormed":"1960",

"countryOfOrigin":"England",

"rockAndRollHallOfFameInductee":true

}

"self":{

"title":"Self",

"href":"http://resteasy.local.dev/api/v0.1/artists/1"

}

Hey look at that — an API endpoint that will spit out listings of all of your content as well as individual items. It’s really just barely scratching the surface of RESTful and APIs but you gotta start somewhere and with less than 75 lines of custom code you have the a basic version of your future API.

Phew, we made it to the end. Did anybody notice anything missing? Yeah, sure you did. You have an exceptionally good eye. I excluded the body field. Why? Well, because that’s what we’ll be taking a look at next time: fields and subproperties!

At Four Kitchens, we love our computers. We use them all day, making the best websites on the web, and into the wee hours, trying our hands at native apps and tools to help with our artistic pursuits.

The only thing we don’t love is the drudgery of computer use – hunting for applications or files hidden inside folders inside of folders, manually creating video chats for impromptu meetings, or even remembering to clean up our desktop before presentations.

That’s why many of us have enlisted the services of our personal robot butler, who goes by the name of Alfred. While there are several applications that are similar, including Quicksilver, Launchbar, and the latest version of Spotlight that is slated to launch this fall, we find Alfred to be the most flexible. Some of us Chefs wanted to share our favorite recipes (or Workflows in Alfred parlance) for success.

To get started, our resident Alfred pro Flip has a complete rundown on setting up Alfred and installing a few developer friendly Workflows on his blog.

Dustin Younse, Support Engineer

I tend to use Alfred as a glorified application launcher, but have added a few just-for-fun workflows I really like.

The perfect GIF at your fingertips

This is the workflow that tore me away from a long time relationship with Quicksilver and made me an Alfred user in the first place. This lets me keep a personal repository of reaction gifs, search for the perfect one, and then link them easily in chat rooms.

Download the Workflow on Destroy Today

Emoji like a pro

Similar to the GIF workflow, this Workflow allows me to search the full emoji set for the perfect emoji, without using OSX’s super slow emoji picker. It also allows you to choose OSX style emoji (the literal character) or the Github style text emoji (:poodle:).

Download the Workflow on GitHub

Quickly grok timestamps

An actually useful workflow, this allows me to paste a Unix timestamp from a database table or the command line and get a human-readable date. This is easy enough to accomplish through a search engine, but being able to popup Alfred and get the answer without having to switch from my work context is super useful, and really that’s the power of Alfred workflows.

Download the Workflow on GitHub

Mike Minecki, Director of Technology

Creating a quick application for adding frequently used things to the clipboard using Applescript

Open the Apple Script Editor
Put in a line like: set the clipboard to "https://yourcompany.zoom.us/j/5551234567"
Save it as an application named Zoom Link

Now you can add a Zoom link to to your clipboard from Alfred!

An alternative, specifically for Google Hangouts, is available here.

Aaron Stanush, Creative Director

Hide/show desktop icons

Several years ago I conceded that I would never keep my “Desktop” folder empty. I also hate seeing all those random folders, images, and text snippets on my desktop. This Alfred workflow allows you to hide or show those pesky items for a truly minimal desktop. Works great for screen sharing too!

Download the Workflow on Github

Generate an XKCD-style password

You might remember this XKCD webcomic that recommended creating secure, memorable passwords by combining four common words like “correct horse batter staple”. With this workflow, you can easily generate passwords like this and have them copied to your clipboard.

Download the Workflow on Github

We hope you find Alfred as helpful as we do!

Meteor is a JavaScript framework that enables developers to quickly create reactive, highly accessible applications. It can be an incredibly powerful tool, especially when paired with Drupal, which is a great content management system that makes it really easy to create well-structured content models and interact with data.

Why not combine the two and let Drupal provide Meteor with semantic data with Meteor rendering that data in a reactive way?

I’ve been playing around with this idea for some time now and have created a few tools that allow Drupal and Meteor to do just that. I recently presented on this topic at NYC Camp, and wanted to take a deeper dive into the ideas. Let’s take a look!

Toolset

There are a few modules I use to send data from Drupal to Meteor:

Mongosync

Mongosync allows one to define Drupal entities of a specific bundle to be synced to a given collection in Meteor. It listens to entity events such as insert, update, and delete, and syncs those actions against Meteor’s datastore. It is compatible with Drupal 7 and has been working with Drupal 8 beta.

Distill

Distill enables other modules to extract and format data from Drupal entities by providing a simple class structure for defining formatting schemas.

Mongosync/Distill marriage module

Mongosync invokes hooks before it tries to push data to MongoDB, and allows any hook implementations to return a processed version of the entity that should be inserted into MongoDB. Drupal entities are… complicated. And kind of weird. They contain a lot of data that’s only useful to Drupal, and there’s no need to send that data to MongoDB. Getting data out of a Drupal object can also be hard; to get a simple field value, you might have to do something like this:

// Drupal 8.
$my_field = $entity->my_field->getValue();
$my_field_value = $my_field['value'];

// Drupal 7.
$value = $entity->my_field[LANGUAGE_NONE][$a_delta]['value'];
// Or:
$wrapper = entity_metadata_wrapper('node', $entity);
$value = $object->my_field->value();

// Drupal 8.

$my_field = $entity->my_field->getValue();

$my_field_value = $my_field['value'];

// Drupal 7.

$value = $entity->my_field[LANGUAGE_NONE][$a_delta]['value'];

// Or:

$wrapper = entity_metadata_wrapper('node', $entity);

$value = $object->my_field->value();

This is kind of gross, especially if you have to do this for a bunch of fields, and have a lot of different types of entities that need different fields to be formatted. Distill solves this problem by abstracting the extraction and formatting process into a class system.

A Mongosync/Distill marriage module could consist of something like this:

/**
 * mongosync_meteor module for Drupal 8.
 * (Distill works on Drupal 7 too)
 */
use DrupaldistillDistill;
use DrupaldistillDistillProcessor;
use Drupaldistill_exampleDistillTestEntityProcessor;

/**
 * Implements hook_mongosync_entity_insert().
 */
function mongosync_meteor_mongosync_entity_insert_preprocess($entity, $type, $bundle) {
  // Create instance of processor.
  $processor = new DistillProcessor();

  // Create instance of Distill.
  $distiller = new Distill($entity, $processor);
  $distiller->setField('field_user', 'user');
  $distiller->setField('field_pizza', 'pizza_id');
  $distiller->setField('field_address', 'address');

  return $distiller->getFieldValues() + array('entity_id' => $entity->id());
}

/**

* mongosync_meteor module for Drupal 8.

* (Distill works on Drupal 7 too)

use DrupaldistillDistill;

use DrupaldistillDistillProcessor;

use Drupaldistill_exampleDistillTestEntityProcessor;

/**

* Implements hook_mongosync_entity_insert().

function mongosync_meteor_mongosync_entity_insert_preprocess($entity, $type, $bundle) {

// Create instance of processor.

$processor = new DistillProcessor();

// Create instance of Distill.

$distiller = new Distill($entity, $processor);

$distiller->setField('field_user', 'user');

$distiller->setField('field_pizza', 'pizza_id');

$distiller->setField('field_address', 'address');

return $distiller->getFieldValues() + array('entity_id' => $entity->id());

}

This just invokes a Mongosync hook, and cleans up the entity being pushed to MongoDB. The data as processed by Distill in this function, when inserted into MongoDB would look something like this:

{
  user: "Patrick Coffey",
  pizza_id: "1234",
  address: "3456 44th street Middle Earth TX, 78759"
}

{

user: "Patrick Coffey",

pizza_id: "1234",

address: "3456 44th street Middle Earth TX, 78759"

}

Putting it all together

Once you have Mongosync installed and connected to Meteor, and set to sync a specific entity type, crank up Meteor and the mongo server you’ll be talking to, and save an entity. That entity should now exist in your MongoDB database, and should be available to Meteor. When you use that data in Meteor to build an interface, when the dataset changes (based on a Drupal action), the interface will react to that change, and update within the browser session accordingly.

Why?

The big question: Why do any of this? Just because you can do something doesn’t mean it’s a good idea. So why would anyone want to use Meteor to build reactive interfaces from Drupal data? Well, reactive interfaces are extremely useful as they add a lot of value to sites, especially if those sites are presenting rapidly changing datasets. Meteor makes it easy to make great reactive interfaces, Drupal is a great content management system. Together, they make a pretty formidable team.

The Humble Perceptron

by Peter Sieg on June 30, 2020

DIY UX Research Part 3: Top 10 Metrics to Implement in Google Analytics

by Donna Habersaat on June 25, 2020

Building with Emulsify Part 2: Callout Component

by Evan Willhite on June 22, 2020

The Big Relaunch Is No More

by Todd Ross Nienkerk on June 19, 2020

The Future of Content Episode 11: Content from Community, Trust, and Intimacy

by Todd Ross Nienkerk on June 8, 2020

Notes from the Web Chefs

Starting your own design system can understandably seem overwhelming. But I’m here to tell you that a small design system is not only achievable … in many ways it might be the preferable way for plucky teams to start.

Dean Oest

Design Manager

Read the Article:

Design Systems: Start Small, Grow Later

Four Kitchens clients have big websites that include many pages, images, PDFs, videos, and other files. These sites have so much content, in fact, that many of our clients are overwhelmed just thinking about going through it prior to a CMS migration.

Donna Habersaat

User Experience Strategist

Read the Article:

From a Mountain to a Molehill: What to Do When You Have Too Much Content

Installing Emulsify

Emulsify Standalone

Emulsify in a Composer-Based Drupal 8 Installation

The Toolchain

WebVR Local Development Server?

Make a WebVR Application

Scenes and Skies

Entities

Testing in Daydream or Cardboard

Speed Up Migration Development

The Challenge

The Proposed Solution

Migration in Drupal 7 vs Drupal 8

How “Migrate Drupal” Makes the Process Better

It builds a migration from your Drupal site

It’s hookable

No initial need for redirection of content

More time to do the alterations the client wants

How-To: Start a Migration with “Migrate Drupal”

1. Do a little research and install contrib modules.

2. Install the contrib migrate modules.

3. Set up the upgrade/migrate databases.

4. Export the migration configuration.

5. Update your migration group with the info for the migration.

5. Alter the configuration.

6. Migrate the data.

Caveats

IDs are verbatim due to the complexity of dependencies

There are superfluous migrations

Final Thoughts

Node

Installing Aquifer

Setting up a development version of Aquifer:

Creating a New Aquifer Project

Preparing Your Project for Pantheon

Editing drupal.make.yml

Setting up Pantheon

Editing aquifer.json

Additional details about the aquifer-git configuration:

Next Steps

Setup your database

Transfer your files

Editing settings.php

OPTIONAL – EVERYTHING BELOW IS UNTESTED CODE IN DEMO

Congratulations

Generate critical CSS with grunt-criticalcss

Use a Drupal hook to inline your styles

Configure AdvAgg module to optimize CSS/JS

Enable AdvAgg modules

Reduce CSS bundles

Move all JavaScript to the bottom of the page

Load CSS asynchronously

Test your fine work

Making further improvements

Tell me the trade-offs

A body at REST

Add the folders and files for v0.2

body parts

Yo Dawg, I heard you like subproperties…

An API endpoint Tutorial with Drupal and the RESTful module.

Step 1: Getting Drupal set up with the RESTful module

Step 2: Create a simple content type

Step 3 – Ensure permissions and add content

Step 4 Creating a Custom RESTful module.

Step 5 – enable the module and visit the API

The perfect GIF at your fingertips

Emoji like a pro

Quickly grok timestamps

Creating a quick application for adding frequently used things to the clipboard using Applescript

Hide/show desktop icons

Generate an XKCD-style password

We hope you find Alfred as helpful as we do!

Toolset

Putting it all together

Why?

Notes from the Web Chefs

A `body` at REST

Add the folders and files for `v0.2`

`body` parts