Lessons from WordPress Core

Steve Persch, Director, Developer Relations Reading estimate: 4 minutes

At DrupalCon New Orleans this month, my co-worker Andrew Taylor and I presented Lessons from WordPress Core.

DrupalCon New Orleans 2016: Lessons from WordPress Core
60 Minutes

We focused primarily on similarities in how core development is planned and executed, rather than on the substance of the code itself. In the post-Drupal 8.0.0 world, new features are released in core every six months. 8.1.0 came out on April 20th and featured BigPipe. 8.2.0 is scheduled for October 5th and will contain new features as well. Drupal 8 is the first major version in which major feature additions are happening in conjunction with the maintenance of backwards compatibility.

Community Structure

In our roles as Agency and Community Engineers, Andrew and I stay close to both the WordPress and Drupal communities. We saw this shift in Drupal organization and thought it looked very similar to what WordPress has done for years.

The WordPress community has:

These teams, structures, and schedules look very similar to processes actively evolving in the Drupal community. Pre-Drupal 8.0.0, the concept of initiatives served as an organizing focus for teams of people working on Drupal core. Dries Buytaert’s opening keynote at DrupalCon New Orleans highlighted that the initiative concept is being refreshed. And the new initiative process looks a lot like what WordPress does in terms of separating out proposal, planning and execution stages. This more formalized process will help accomplish what was articulated in a blog post from Gábor Hojtsy in 2014. He emphasized that initiatives and their leaders “have responsibility to show the community there is a (1) shared goal, that (2) it is an achievable goal, and then (3) help people get there.”

Similar to the way WordPress has defined the role of “release lead” to be close to that of project manager, the Drupal community has renamed “Initiative Lead” to “Initiative Coordinator.” This terminology has even entered the Drupal community’s Governance project which defines roles related to core development. It is also a sign of community maturation that this governance document delineates among different roles with the team of core committers like Framework Managers, Product Managers, and Release Managers. Drupal can see from WordPress that more clearly defining the who / what / when / where / why of core development makes the work more successful.

Site Administration with JavaScript

Drupal can also learn from the Calypso project. Automattic, the dominant WordPress-focused company, funded the development of Calypso as an alternative administrative user interface. Calypso uses the WordPress.com API to feed administrative components written with React.js. The Drupal Community has seen a lot of similar discussion around using JavaScript frameworks for administrative tasks, including talks at DrupalCon. There are a few lessons that can be taken from Calypso for creating alternate administration in JavaScript:

  • It is possible! A PHP CMS does not to rewrite itself completely to support a JavaScript UI.

  • It can happen outside of Core. Calypso is a standalone project.

  • Limited APIs limit reach. Some in the WordPress community would use Calypso were it not for the requirement of using WordPress.com’s API. A community-built API could have wider reach.

Backwards Compatibility and User Trust

The Drupal community’s jump to focusing on what would need to be rewritten to accommodate JavaScript administration highlights different attitudes on backwards compatibility. The WordPress community sees maintaining backwards compatibility as a huge driver of growth. Maintaining backwards compatibility means maintaining user trust which builds community. Dries articulated a different attitude back in a 2006 blog post: "I feel that preserving the ability to constantly innovate is of higher importance, at the present time at least, than preserving backward compatibility."

A willingness to rewrite significant portions of code allowed Drupal 8 to catch up with the Composer-based, Object Oriented world of modern PHP. That attitude has attracted many great developers and many great projects. However it is difficult, likely impossible, to know how many developers and projects were driven away from Drupal by regularly shaking the base on which sites are built. WordPress’ much larger market share gives Drupal a hint of what was given up and what could be ahead by keeping the focus on Drupal 8 longer.

Focusing the Team

Personally, I think the key lesson from WordPress is the huge upside to having a community with shared focus. 2016 will likely be the first full year where nearly all of the focus of the Drupal community stays on one major version, Drupal 8. Previously the community was split between core developers working on D8 while everyone else built and maintained sites in D6 and D7. We are just beginning to reap the benefits of having everyone focused in the same place. The initiatives, core committer roles and release schedule make that focus even clearer. WordPress shows that we can expect steady progress and improvements, especially for content authors, when all of the developers are working on the same version.

Discover More

Pantheon and Tag1 to Provide Free Long-Term Support for Drupal 7 Websites

Chris Yates
Reading estimate: 2 minutes

Top 10 Innovation Sessions to Attend at DrupalCon Barcelona 2024

Alex Moreno
Reading estimate: 4 minutes

What Does a Developer Advocate Actually Do?

Chris Reynolds
Reading estimate: 4 minutes

Try Pantheon for Free

Join thousands of developers, marketers, and agencies creating magical digital experiences with Pantheon.