development

This is a reposting of what I wrote on the Acquia Dev Center blog in 2016, Should I disable PHP warnings and notices?.

Many developers who work on Drupal (or other web/PHP) projects have error reporting disabled in their local or shared dev environments, for a variety of reasons—some don't know how to enable it, some are annoyed by the frequency of notices, warnings, and errors, and some don't like to be reminded of how many errors are logged!

There are a few important reasons you should make sure to show all errors when developing, though:

One of the motivations behind Drupal VM is flexibility in local development environments. When you develop many different kinds of Drupal sites you need to be able to adapt your environment to the needs of the site—some sites use Memcached and Varnish, others use Solr, and yet others cache data in Redis!

Drupal VM has recently gained much more flexibility in that it now allows configuration options like:

• Choose either Ubuntu or CentOS as your operating system.
• Choose either Nginx or Apahe as your webserver.
• Choose either MySQL or MariaDB for your database.
• Choose either Memcached or Redis as a caching layer.
• Add on extra software like Apache Solr, Node.js, Ruby, Varnish, Xhprof, and more.

Out of the box, Drupal VM installs Drupal 8 on Ubuntu 14.04 with PHP 5.6 (the most stable release as of December 2015) and MySQL. We're going to make a few quick changes to config.yml so we can run the following local development stack on top of CentOS 7:

Configure Drupal VM

To get started, download or clone a copy of Drupal VM, and follow the Quick Start Guide, but before you run vagrant up (step 2, #6), edit config.yml and make the following changes/additions:

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.

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.

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.

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.

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:

I recently read a very good interview with Jason Fried on The Great Discontent, and one of the answers towards the end of the interview struck me:

The other advice is to focus on one thing. I see a lot of entrepreneurs build something and then move onto the next thing and the next thing and the next. Building something is only step one. It’s not that hard to put something out there. Building on top of that to maintain and improve it is actually the harder thing to do. Anyone can release something, but it’s much harder to polish and refine it over time once it’s out there.

I admit I've been tempted by this same thing many times—trying out new idea after new idea, leaving the old to gather cobwebs in a closet. Lately I've been refocusing on some of my older, mildly successful projects, like my Hosted Apache Solr service and Server Check.in (they're not that old compared to other mature services, but they're old for me).