Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough
Jan 18 2018
Jan 18
January 18th, 2018

What are Spectre and Meltdown?

Have you noticed your servers or desktops are running slower than usual? Spectre and Meltdown can affect most devices we use daily. Cloud servers, desktops, laptops, and mobile devices. For more details go to: https://meltdownattack.com/

How does this affect performance?

We finally have some answers to how this is going to affect us. After Pantheon patched their servers they released an article showing the 10-30% negative performance impact that servers are going to have. For the whole article visit: https://status.pantheon.io/incidents/x9dmhz368xfz

I can say that I personally have noticed my laptop’s CPU is running at much higher percentages than before the update for similar tasks.
Security patches are still being released for many operating systems, but traditional desktop OSs appear to have been covered now. If you haven’t already, make sure your OS is up to date. Don’t forget to update the OS on your phone.

Next Steps?

So what can we do in the Drupal world? First, you should follow up with your hosting provider and verify they have patched your servers. Then you need to find ways to counteract the performance loss. If you are interested in performance recommendations, Four Kitchens offers both frontend and backend performance audits.

As a quick win, if you haven’t already, upgrade to PHP7 which should give you a performance boost around 30-50% on PHP processes. Now that you are more informed about what Spectre and Meltdown are, help with the performance effort by volunteering or sponsoring a developer on January 27, 2018 and January 28, 2018 for the Drupal Global Sprint Weekend 2018, specifically on performance related issues: https://groups.drupal.org/node/517797

Web Chef Chris Martin
Chris Martin

Chris Martin is a support engineer at Four Kitchens. When not maintaining websites he can be found building drones, computers, robots, and occasionally traveling to China.

Web Chef Dev Experts
Development

Blog posts about backend engineering, frontend code work, programming tricks and tips, systems architecture, apps, APIs, microservices, and the technical side of Four Kitchens.

Read more Development
Oct 13 2017
Oct 13
October 13th, 2017

Welcome to the second 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 teach you how to create an Emulsify 2.0 starter kit with Drush. This blog post follows the video closely, so you can skip ahead or repeat sections in the video by referring to the timestamps for each section.

PURPOSE [00:15]

This screencast will specifically cover the Emulsify Drush command. The command’s purpose is to setup a new copy of the Emulsify theme.

Note: I used the word “copy” here and not “subtheme” intentionally. This is because the subtheme of your new copy is Drupal Core’s Stable theme, NOT Emulsify.

This new copy of Emulsify will use the human-readable name that your provide, and will build the necessary structure to get you on your way to developing a custom theme.

REQUIREMENTS [00:45]

Before we dig in too deep I recommend that you have the following installed first:

  • a Drupal 8 Core installation
  • the Drush CLI command at least major version 8
  • Node.js preferably the latest stable version
  • a working copy of the Emulsify demo theme 2.X or greater

If you haven’t already watched the Emulsify 2.0 composer install presentation, please stop this video and go watch that one.

Note: If you aren’t already using Drush 9 you should consider upgrading as soon as possible because the next minor version release of Drupal Core 8.4.0 is only going to work with Drush 9 or greater.

RECOMMENDATIONS [01:33]

We recommend that you use PHP7 or greater as you get some massive performance improvements for a very little amount of work.

We also recommend that you use composer to install Drupal and Emulsify. In fact, if you didn’t use Composer to install Emulsify—or at least run Composer install inside of Emulsify—you will get errors. You will also notice errors if npm install failed on the Emulsify demo theme installation.

AGENDA [02:06]

Now that we have everything setup and ready to go, this presentation will first discuss the theory behind the Drush script. Then we will show what you should expect if the installation was successful. After that I will give you some links to additional resources.

BACKGROUND [02:25]

The general idea of the command is that it creates a new theme from Emulsify’s files but is actually based on Drupal Core’s Stable theme. Once you have run the command, the demo Emulsify theme is no longer required and you can uninstall it from your Drupal codebase.

WHEN, WHERE, and WHY? [02:44]

WHEN: You should run this command before writing any custom code but after your Drupal 8 site is working and Emulsify has been installed (via Composer).

WHERE: You should run the command from the Drupal root or use a Drush alias.

WHY: Why you should NOT edit the Emulsify theme’s files. If you installed Emulsify the recommended way (via Composer), next time you run composer update ALL of your custom code changes will be wiped out. If this happens I really hope you are using version control.

HOW TO USE THE COMMAND? [03:24]

Arguments:

Well first it requires a single argument, the human-readable name. This name can contain spaces and capital letters.

Options:

The command has defaults set for options that you can override.

This first is the theme description which will appear within Drupal and in your .info file.

The second is the machine-name; this is the option that allows you to pick the directory name and the machine name as it appears within Drupal.

The third option is the path; this is the path that your theme will be installed to, it defaults to “themes/custom” but if you don’t like that you can change it to any directory relative to your web root.

Fourth and final option is the slim option. This allows advanced users who don’t need demo content or don’t want anything but the bare minimum required to create a new theme.

Note:

Only the human_readable_name is required, options don’t have to appear in any order, don’t have to appear at all, or you can only pass one if you just want to change one of the defaults.

SUCCESS [04:52]

If your new theme was successfully created you should see the successful output message. In the example below I used the slim option because it is a bit faster to run but again this is an option and is NOT required.

The success message contains information you may find helpful, including the name of the theme that was created, the path where it was installed, and the next required step for setup.

THEME SETUP [05:25]

Setting up your custom theme. Navigate to your custom theme on the command line. Type the yarn and watch as pattern lab is downloaded and installed. If the installation was successful you should see a pattern lab successful message and your theme should now be visible within Drupal.

COMPILING YOUR STYLE GUIDE [05:51]

Now that we have pattern lab successfully installed and you committed it to you version control system, you are probably eager to use it. Emulsify uses npm scripts to setup a local pattern lab instance for display of your style guide.

The script you are interested in is yarn start. Run this command for all of your local development. You do NOT have to have a working Drupal installation at this point to do development on your components.

If you need a designer who isn’t familiar with Drupal to make some tweaks, you will only have to give them your code base, have them use yarn to install, and yarn start to see your style guide.

It is however recommended the initial setup of your components is done by someone with background knowledge of Drupal templates and themes as the variables passed to each component will be different for each Drupal template.

For more information on components and templates keep an eye out for our soon to come demo components and screencasts on building components.

VIEWING YOUR STYLE GUIDE [07:05]

Now that you have run yarn start you can open your browser and navigate to the localhost URL that appears in your console. If you get an error here you might already have something running on port 3000. If you need to cancel this script hit control + c.

ADDITIONAL RESOURCES [07:24]

Thank you for watching today’s screencast, we hope you found this presentation informative and enjoy working with Emulsify 2.0. If you would like to search for some additional resources you can go to emulsify.info or github.com/fourkitchens/emulsify.

[embedded content]

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

Web Chef Chris Martin
Chris Martin

Chris Martin is a support engineer at Four Kitchens. When not maintaining websites he can be found building drones, computers, robots, and occasionally traveling to China.

Mar 02 2017
Mar 02
March 2nd, 2017

You might have heard about high availability before but didn’t think your site was large enough to handle the extra architecture or overhead. I would like to encourage you to think again and be creative.

Background

Digital Ocean has a concept they call a floating IPs. A Floating IP is an IP address that can be instantly moved from one Droplet to another Droplet in the same data center. This idea is great, it allows you to keep your site running in the event of failure.

Credit

I have to give credit to BlackMesh for handling this process quite well. The only thing I had to do was create the tickets to change the architecture and BlackMesh implemented it.

Exact Problem

One of our support clients had the need for a complete site relaunch due to a major overhaul in the underlying architecture of their code. Specifically, they had the following changes:

  1. Change in the site docroot
  2. Migration from a single site architecture to a multisite architecture based on domain access
  3. Upgrade of PHP version that required a server replacement/upgrade in linux distribution version

Any of these individually could have benefited from this approach. We just bundled all of the changes together to delivering minimal downtime to the sites users.

Solution

So, what is the right solution for a data migration that takes well over 3 hours to run? Site downtime for hours during peak traffic is unacceptable. So, the answer we came up with was to use a floating IP that can easily change the backend server when we are ready to flip the switch. This allows us to migrate our data on a new separate server using it’s own database (essentially having two live servers at the same time).

Benefits

Notice that we won’t need to change the DNS records here which meant we didn’t have to wait for DNS records to propagate all over the internet. The new site was live instantly.

Additional Details

Some other notes during the transition that may lead to separate blog posts:

  1. We created a shell script to handle the actual deployment and tested it before the actual “go live” date to minimize surprises.
  2. A private network was created to allow the servers to communicate to each other directly and behind the scenes.
  3. To complicate this process, during development (prelaunch) the user base grew so much we had to off load the Solr server on to another machine to reduce server CPU usage. This means that additional backend servers were also involved in this transition.

Go-Live (Migration Complete)

After you have completed your deployment process, you are ready to switch the floating ip to the new server. In our case we were using “keepalived” which responds to a health check on the server. Our health check was a simple php file that responded with the text true or false. So, when we were ready to switch we just changed the health checks response to false. Then we got an instant switch from the old server to the new server with minimal interruption.

Acceptable Losses

There were a few things we couldn’t get around:

  1. The need for a content freeze
  2. The need for a user registration freeze

The reason for this was that our database was the database updates required the site to be in maintenance mode while being performed.

A problem worth mentioning:

  1. The database did have a few tables that would have to have acceptable losses. The users sessions table and cache_form table both were out of sync when we switched over. So, any new sessions and saved forms were unfortunately lost during this process. The result is that users would have to log in again and fill out forms that weren’t submitted. In the rare event that a user changed their name or other fields on their preferences page those changes would be lost.

Additional Considerations

  1. Our mail preferences are handled by third parties
  2. Comments aren’t allowed on this site

Recommended Posts

  • Engineers find solving complex problems exciting, but as I’ve matured as an engineer, I’ve learned that complexity isn’t always as compelling as simplicity.
  • Cloudflare Bug May Have Created Security Leak Cloudflare, a major internet host, had some unusual circumstances that caused their servers to output information that contained private information such as HTTP…
  • When you already have a design and are working with finalized content, high fidelity wireframes might be just what the team needs to make decisions quickly.
Chris Martin
Chris Martin

Chris Martin is a junior engineer at Four Kitchens. When not maintaining websites he can be found building drones, computers, robots, and occasionally traveling to China.

Development

Blog posts about backend engineering, frontend code work, programming tricks and tips, systems architecture, apps, APIs, microservices, and the technical side of Four Kitchens.

Read more Development
Sep 07 2016
Sep 07

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:

  1. Installing Aquifer
  2. Creating a new Aquifer project
  3. Preparing your project for Pantheon
  4. 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:

  1. 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.
  2. If you had a version of Aquifer already installed, delete the node_modules directory within the Aquifer directory.
  3. If not, navigate to a directory you wish to install Aquifer in and clone the repository:
    a. git clone [email protected]:aquifer/aquifer.git # SSH version - or -
    b. git clone https://github.com/aquifer/aquifer.git # HTTPS if no github keys
  4. IMPORTANT: Checkout the 1.0.0 branch git checkout 1.0.0
  5. Run npm install to get the latest packages.
  6. 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.
  7. 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.

  1. Navigate to a directory you want to install your Aquifer project in.
  2. Create a new project named “test”: aquifer create test
  3. Navigate into the project that was generated: cd test
  4. 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.

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

This:


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

Should read:


projects:
  # Core version 7.50.
  drops_7:
    type: "core"
    download:
      type: "git"
      url: "[email protected]: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: ~

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


projects:
  # Core version 7.44.
  drupal:
    type: "core"
    download:
      type: "git"
      url: "[email protected]: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

If this succeeded and in your terminal output you see:


drops_7 cloned from [email protected]: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).

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

In a new project, this reads:


  "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"
  }
},

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",

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}",

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://[email protected]: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"

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",

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

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"
},

  • 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.
}

  • 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.

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web