Comment on Greenpeace’s Planet 4 technical discovery findings

Greenpeace has been undergoing what seems to be a pretty open process in developing Planet 4, the plan for redesigning greenpeace.org. A series of posts have been published on Medium providing details on the discovery process and some of the decisions that have been made.

A few days ago, Davin Hutchins posted “Why Greenpeace and WordPress need each other“, which shares some thoughts on why WordPress is the right choice for a new CMS platform and how Greenpeace and the WordPress community share a similar set of goals in their respective domains.

A few weeks ago, Kevin Muller posted “Checking technical options, we discovered…“, which dives into the more technical details of the stack. This links to a pretty great slide deck that shows how much research went into the technical discovery process.

Both posts, and the process in general, are looking for input, so I’m going to toss out some initial thoughts I have in response after reading through all of that material. I’m going to start with the most reactionary first and then work my way through the mundane. 🙂

And to Greenpeace – Hi! I’m happy you’re moving forward with WordPress!

Customizing WordPress

The word “fork” comes up at some point in the technical discovery post and “customized version of” appears in Davin’s post. Those start raising a yellow flag for me. Not because I think forking is bad, as that’s the heart of free and open source software, but because I think it would be the wrong technical decision.

The WordPress core project has hundreds of contributors and ships 3 major releases a year. As soon as a fork happens, a maintenance burden begins. This maintenance burden grows as things are built into the forked version that do not make their way into the upstream project.

That said, having your own production version of WordPress managed in git makes complete sense. This is a common practice, and something we do with our multi-network multisite WordPress platform at Washington State University.

This provides the ability to test patches in production or release hotfixes while you’re waiting for contributions to be merged upstream. It also makes management of local, staging, and production environments easier across the team.

Multisite vs Single Site

This list of pros and cons in the slide deck is a good one. I have quite a bit to say about multisite, as I think it’s a good enough decision for something like this. I’ll break it down to a couple points:

• If you foresee using the same set of plugins on every site, or making the same set of plugins available for every site, multisite is a good answer.
• If it makes sense for a global set of users to have access to multiple sites, multisite is a good answer.

There’s always more detail, but those are pretty good initial gut checks.

I’d be less concerned about the performance issues. Today’s modern LEMP stack is pretty dang good at serving requests and from a maintenance perspective I’d rather manage one installation than many.

For reference, WSU’s installation of WordPress has 57 networks, 1500 sites, and serves about 2.5 million page views a month on one server. WordPress.com is a single installation of WordPress with many millions of sites, spread out across many thousands of servers.

Performance

The slide deck mentions a couple things. Here are a couple more (very much my opinion):

• Use something for object cache, and get a good object cache plugin. See plugins for PECL memcached and PECL memcache.
• Use Batcache for page caching before moving on to something more complex like Varnish. This uses your object cache to cache pages and is super straight forward.
• HyperDB is worth paying attention to when using multisite. This will help you scale.

Plugins

Don’t install too many plugins and be focused with the ones you do install.

WordPress is extremely extensible and has a great plugin ecosystem, but when approaching a project this large you’ll want to be sure that any plugin you install goes through a code review focused on security and performance. This also helps with developer familiarity when things go wrong.

Here are the basic criteria we use at WSU when vetting plugin requests.

REST API

The slide deck briefly mentions a REST API, but it’s not entirely obvious that it means the forthcoming WordPress REST API, which will be shipping next month in WordPress 4.7.

This should be a very useful tool in building custom applications that use data throughout the Greenpeace network. Use the built in routes and create your own custom routes rather than developing a new API on top of WordPress.

Community

And (of course) the last important note is community.

At the very least, pay attention to the notes that are frequently published on Make/Core, the official blog for WordPress core development. As things move forward, raise bugs and enhancements, submit patches, etc…

The easiest way to reduce maintenance burden when extending WordPress is to be familiar with WordPress.

Everyone contributing to WordPress is also interested in the ways that people use and extend WordPress, so please keep sharing your work as you build Planet 4 out. And as Petya mentioned on Twitter, it’d be great to hear your experience at next year’s WordCamp Europe or any other.

Please feel free to ask for more detail if you’d like! 💚☮