development

Major improvements to Drupal VM - PHP 7, MariaDB, Multi-OS

Drupal VM - Vagrant and Ansible Virtual Machine for Drupal Development

For the past couple years, I've been building Drupal VM to be an extremely-tunable, highly-performant, super-simple development environment. Since MidCamp earlier this year, the project has really taken off, with almost 200 stars on GitHub and a ton of great contributions and ideas for improvement (some implemented, others rejected).

In the time since I wrote Developing for Drupal with Vagrant and VMs, I've focused on meeting all my defined criteria for the perfect local development environment. And now, I'm able to say that I use Drupal VM when developing all my projects—as it is now flexible and fast enough to emulate any production environment I use for various Drupal projects.

Easy PHP 7 testing with CentOS 7 and MariaDB

After a few weeks of work, Drupal VM now officially supports running PHP 7 (currently, 7.0.0 alpha 2) on CentOS 7 with MariaDB, or you can even tweak the settings to compile PHP from source yourself (following to the PHP role's documentation).

Developing for Drupal with Vagrant and VMs

Many blog posts have outlined the benefits of using VMs (Virtual Machines) for local Drupal development instead of either using native PHP and Apache, or a bundled environment like MAMP, XAMPP, or Acquia Dev Desktop. The advantages of using virtualization (usually managed by Vagrant) are numerous, but in certain cases, you can make a good argument for sticking with the traditional solutions.

If you'd like to take the dive and start using virtualized development environments, or if you're already using Vagrant and VirtualBox or some other VM environment (e.g. VMWare Fusion or Parallels Desktop), how do you optimize local development, and which pre-bundled Drupal development VM will be best for you and your team?

Criteria for the Perfect Local Development Environment

These are the criteria I use when judging solutions for local Drupal development (whether virtualized or traditional):

  • Should be simple and easy to set up
  • Should be fast by default
  • Should be flexible:
    • Should work with multiple providers; VirtualBox is free, but VMWare can be much faster!
    • Should allow configuration of the PHP version.
    • Should work with your preferred development workflow (e.g. drush, makefiles, manual database sync, etc.)
    • Should prevent filesystem friction (e.g. permissions issues, slow file access speeds, etc.)
    • Shouldn't have hardcoded defaults
  • Should be complete:
    • Should work without requiring a bunch of extra plugins or 3rd party tools
    • No extra languages or libraries should be required (why install Ruby gems, npm modules, etc. unless you need them for your particular project?)
  • Should be Free and Open Source
  • Should include all the tools you need, but allow you to disable whatever you don't need (e.g. XHProf, Apache Solr, etc.)
  • Should work on Windows, Mac, and Linux with minimal or no adjustment
  • Should be deployable to production (so your local dev environment matches prod exactly)

A lot of these points may have more or less importance to a particular team or individual developer. If you're a die-hard Mac user and don't ever work with any developers on Windows or Linux, you don't need to worry about Windows support. But some of these points apply to everyone, like being fast, simple, and flexible.

Ensuring Drupal email doesn't get sent from a local development environment

It seems most developers I know have a story of running some sort of batch operation on a local Drupal site that triggers hundreds (or thousands!) of emails that are sent to the site's users, causing much frustration and ill will towards the site the developer is working on. One time, I accidentally re-sent over 9,000 private message emails during a test user migration because of an email being sent via a hook that was invoked during each message save. Filling a user's inbox is not a great way to make that user happy!

With Drupal, it's relatively easy to make sure emails are either rerouted or directed to temp files from local development environments (and any other environment where actual emails shouldn't be sent to end users). Drupal.org has a very thorough page, Managing Mail Handling for Development or Testing, which outlines many different ways you can handle email in non-production environments.

However, for most cases, I like to simply redirect all site emails to my own address, or route them to a figurative black hole.

D8CX at MWDS - Porting Wysiwyg Linebreaks to Drupal 8

I have been at the Midwest Drupal Summit for the past few days, focusing on #D8CX and reducing Drupal 8's technical debt (at least, a tiny bit of it!).

Wysiwyg Linebreaks

My main goal at the conference was to port the Wysiwyg Linebreaks module to Drupal 8. I originally built the module for Drupal 6 while helping the Archdiocese of St. Louis migrate almost 50 separate Joomla-based websites into one organic-groups-driven Drupal site. Their legacy content used linebreaks (rather than markup like <p> and <br /> tags) for paragraphs of text, and when we originally enabled Wysiwyg with TinyMCE, the editor ran all the text together in one big paragraph. The Wysiwyg Linebreaks module fixes that problem by running some JavaScript that adds the required tags when an editor is attached to a textarea, and (optionally) removes the tags when the editor is detached.

The Drupal 6 and Drupal 7 versions of the module depended on the Wysiwyg module, and worked with many different editors—however, the way the linebreaks plugin was added was slightly clunky, and required a little bit of a hack to work well (see Let cross-editor plugins be button-less (aka 'extensions')).

Running Vagrant + VirtualBox from an External Drive

I have a MacBook Air with a 128 GB SSD, so I'm always in a bit of a crunch for space on my hard drive. Developing with local VMs provisioned by Vagrant and VirtualBox makes my Drupal (and other) development experience great, but it also quickly fills up the (tiny amount of) remaining space on my SSD!

Here's how you can move your Vagrant files and VirtualBox VMs out of your home folder onto an external hard drive:

  1. Copy the .vagrant.d folder from your home folder (~/.vagrant.d) to your external drive (I renamed the folder to vagrant_home:
    cp -R ~/.vagrant.d /Volumes/[VOLUME_NAME]/vagrant_home"
  2. Delete the .vagrant.d folder from your home folder:
    rm -rf ~/vagrant.d
  3. Edit your .bash_profile file, and add the following line (example for Mac OS X):
    export VAGRANT_HOME="/Volumes/[VOLUME_NAME]/vagrant_home"
  4. Open VirtualBox, go to Preferences, and set the Default Machine Folder to a location on your external hard drive (I created a new folder called 'VirtualBox VMs').

At this point, if you download new base boxes, or provision new VMs, they should be on your external drive. (This assumes that you didn't have any existing VMs that you needed to move; in that case, read Moving VirtualBox and Vagrant to an external drive.

Questions about Wordpress

Having been away from the WordPress scene since version 2.x days (I think the last time I launched a WordPress website was around 2009), I recently had reason to develop some WordPress plugins, and I wanted to ask some questions about the WordPress coding standards and API that I hope will help enlighten me (and, maybe, other PHP developers coming from other frameworks/platforms to WordPress).

Here are some questions I've had while working on my first WordPress plugin (coming purely from the development side—I'm deliberately ignoring any mention of WordPress's UI, as I don't want to inspire any trolling along the lines of 'WordPress vs. [Another CMS]'):

Pages

Subscribe to RSS - development