Today we announced our official support for WordPress, and we’re excited to offer the Pantheon website platform as a professional-grade option for all the WordPress developers out there. As many of you may know, users have been running WordPress on Pantheon—at first unofficially, and then through a limited pilot program—for a while now. I'm here to explain why we did this and how it works.
Our core idea is that the “under the hood” portion of website infrastructure is common, even though websites themselves run a huge gamut of design and functionality. While we initially built and tuned Pantheon based on our expertise building, launching, and running Drupal at scale, it turns out to be an excellent platform for WordPress as well.
We first realized this a few years ago, when blog posts from developers starting appearing in the wild explaining how to put WordPress on Pantheon. It also became apparent that many of our larger-scale customers want to use the “right tool for the job,” which sometimes means WordPress. While they loved our platform, it was an incomplete solution if it was Drupal-only.
Professional web developers commonly use a mix of Drupal and WordPress to meet their client needs. Drupal where a robust CMS toolkit is called for; WordPress where the use-case is more straightforward publishing. That makes sense, and it’s great to see there are high-quality open-source tools to choose from in either case.
Most of the engineering work needed was on our roadmap already, and the decision was easy once we realized that:
People were running WordPress on Pantheon, whether we liked it or not; and
Many of our most passionate users (and biggest customers) were stuck half-on/half-off Pantheon until we supported all the tools they used.
So we decided to go for it. We prioritized implementing the platform capabilities to fully support WordPress, and the rest is history. Here’s what’s been added in this release:
WordPress-friendly Platform Settings
The first and most obvious thing we did was ensure the platform was WordPress-friendly. This is the only piece of work that wasn’t on our roadmap already, but luckily it wasn’t very hard. The requirements for running Drupal vs. WordPress are quite similar.
The upside is that WordPress developers can expect tuned and friendly configurations for php, nginx, Varnish, mysql and Redis, with a stock set of Plugins to make the most of everything the platform has to offer.
Robust Workflow Tooling
Something we’ve been working on for some time is an upgrade to our workflow system that allows more robust batching of jobs and explicit chaining of actions to be performed between each workflow step. This improves the flexibility of the platform by opening up more custom workflows for advanced users.
WordPress, for instance, likes to store the “site url” in the database, both in config and by storing fully-qualified URLs in its content. To make Pantheon’s workflow shine under those circumstances, we absolutely needed a mechanism to automatically chain runs of wp-cli’s “find/replace” tools after database migrations. That became a very concrete reason to implement a better workflow accounting system, which is a win/win for the platform as a whole and for WordPress in particular.
Abstraction for Site Status
One of the coolest things we’ve created this year at Pantheon is the Launch Check status system. It’s saved us and our customers tons of time spotting potential trouble and zeroing in on what needs doing in order to have a great launch.
Obviously, you need to check for different things on WordPress and Drupal sites. For us, it was a good exercise to abstract and re-implement this functionality in a pluggable manner, so we can run different checks for different kinds of sites.
Environment Variable Management
Every framework uses different names for its variables to connect to the database/etc. While the core requirements are similar, the semantics tend to be different. For instance, WordPress uses a set of PHP constants to define database configuration, while Drupal uses a global $conf array.
To bridge this gap and to prepare for future development, we implemented a structured and extensible system for managing environmental configuration, using the emerging standard of PHP dotenv to establish core configuration values. In addition to supporting solid abstraction of configuration values from code, the new system will make it possible to allow our users to set their own custom environment variables, a commonly-requested feature.
This also means there’s zero configuration for starting a new WordPress site. Step one is to name your site and set up the admin login credentials.
A New Command Line Interface Tool
Lastly, this work accelerated our development work on version 2.0 of “Terminus,” thePantheon Command Line Interface tool. Rewriting Terminus as a standalone application rather than as a Drush extension was something we knew we needed to do regardless. It didn’t make sense to have Drush as a dependency for working with Pantheon via a command-line, and setting up our own application would open up all kinds of future possibilities.
The new CLI is still in early days, but it works and we'd love for everyone to give it a try:
We actually borrowed quite a lot from the wp-cli toolkit in this refactor. Our library code was largely portable from Drush, but we took their object structure and docstring-parsing magic, which is pretty strong stuff. As a result, we have a more robust CLI tool to build off in the future.
More to Come
There’s much more to dig into on all these fronts. Expect to hear more from us in the coming days. For now, if you’d like to know more, the best place to go is our helpdesk, which now sports a few shiny new WordPress articles.
We will also be hosting a webinar on March 26th where Alley Interactive will share how they pull off complex WordPress launches on Pantheon.Topics: WordPress