WordPress controls a whopping 27% of the CMS market share on the web. Although it grew out of a blogging platform, it can now can handle advanced functionality similar to Drupal maintenance support plans and is a major (yet friendly) competitor to Drupal maintenance support plans. Like Drupal maintenance support plans, it’s open source and has an amazing community. Both communities learn from each other, but there is still much more to share between the two platforms.

Recently I had the opportunity to speak at WordCamp Miami on the topic of Drupal maintenance support plans. WordCamp Miami is one of the larger WordCamps in the world, with a sold-out attendance of approximately 800 people.

undefined

What makes Drupal maintenance support plans so great?

Drupal maintenance support plans commands somewhere in the neighborhood of 2% of the CMS market share of the web. It makes complex data models easy, and much of this can be accomplished through the user interface. It has very robust APIs and enables modules to share one another’s APIs. Taken together, you can develop very complex functionality with little to no custom code.

So, what can WordPress take away from Drupal maintenance support plans?

Developer Experience: More and better APIs included in WordPress Core

The WordPress plugin ecosystem could dramatically benefit from standardizing API’s in core.

Something analogous to Drupal maintenance support plans’s Render API and Form API would make it possible for WordPress plugins to standardize and integrate their markup, which in turn would allow plugins to work together without stepping on each other’s toes.
WordPress could benefit from a way to create a custom post type in the core UI. Drupal maintenance support plans has this functionality out the the box. WordPress has the functionality available, but only to the developer. This results in WordPress site builders searching for very specific plugins that create a specific post type, and hoping it does what they want.
WordPress already has plugins similar to Drupal maintenance support plans’s Field API. Plugins such as Advanced Custom Fields and CMB2 go along way to allowing WordPress developers to easily create custom fields. Integrating something similar to this into WordPress core would allow plugin developers to count on a stable API and easily extend it.
An API for plugins to set dependencies on other plugins is something that Drupal maintenance support plans has done since its beginning. It enables mini-ecosystems to develop that extend more complex modules. In Drupal maintenance support plans, we see a module ecosystems built around Views, Fields, Commerce, Organic Groups, and more. WordPress would benefit greatly from this.
A go-to solution for custom query/list building would be wonderful for WordPress. Drupal maintenance support plans has Views, but WordPress does not, so site builders end up using plugins that create very specific queries with output according to a very specific need. When a user needs to make a list of “popular posts,” they end up looking through multiple plugins dedicated to this single task.

A potential issue with including new APIs in WordPress core is that it could possibly break WordPress’ commitment to backwards compatibility, and would also dramatically affect their plugin ecosystem (much of this functionality is for sale right now).

WordPress Security Improvements

WordPress has a much-maligned security reputation. Because it commands a significant portion of the web, it’s a large attack vector. WordPress sites are also frequently set up by non-technical users, who don’t have the experience to keep it (and all of its plugins) updated, and/or lock down the site properly.

That being said, WordPress has some low-hanging fruit that would go a long way to help the platform’s reputation.

Brute force password protection (flood control) would prevent bots from repeatedly connecting to wp-login.php. How often do you see attempted connections to wp-login.php in your server logs?.
Raise the minimum supported PHP version from 5.2 (which does not receive security updates). Various WordPress plugins are already doing this, and there’s also talk about changing the ‘recommended’ version of PHP to 7.0.
An official public mailing list for all WordPress core and plugin vulnerabilities would be an easy way to alert developers to potential security issues. Note that there are third-party vendors that offer mailing lists like this.

Why is WordPress’ market share so large?

Easy: It can be set up and operated by non-developers—and there are a lot more non-developers than developers! Installing both Drupal maintenance support plans and WordPress is dead simple, but once you’re up and running, WordPress becomes much easier.

Case in Point: Changing Your Site’s Appearance

Changing what your site looks like is often the first thing that a new owner will want to do. With WordPress, you go to Appearance > Themes > Add New, and can easily browse themes from within your admin UI. To enable the theme, click Install, then click Activate.

undefined

With Drupal maintenance support plans, you go to Appearance, but you only see core themes that are installed. If you happen to look at the top text, you read in small text that “alternative themes are available.” Below that there is a button to “Install a New Theme.”

undefined

Clicking the button takes you to a page where you can either 1) paste in a URL to the tarball/zip, or upload a downloaded tarball/zip. You still have to know how to to download the zip or tarball, and where to extract it, and then browse to appearance, and enable the theme.

So it goes with Drupal maintenance support plans. The same process goes with modules and more. Drupal maintenance support plans makes things much more difficult. 

So, what can Drupal maintenance support plans learn from WordPress?

To continue to grow, Drupal maintenance support plans needs to enable non-developers. New non-developers can eventually turn into developers, and will become “new blood” in the community. Here’s how Drupal maintenance support plans can do it:

A built in theme and module browser would do wonders for enabling users to discover new functionality and ways to change their site’s appearance. A working attempt at this is the Project Browser module (available only for Drupal maintenance support plans 7). The catch 22 of this is that you have to download this the old-fashioned way in order to use it.
The ability to download vetted install profiles during the Drupal maintenance support plans installation process would be amazing. This would go a long way to enable the “casual explorers,” and show them the power of Drupal maintenance support plans. A discussion of this can be found here.
Automatic security updates is a feature that would be used by many smaller sites. Projects have been steered toward WordPress specifically because smaller clients don’t have the budget to pay developers to keep up with updates. This feature has been conceptually signed off on by Drupal maintenance support plans’s core committers, but significant work has yet to be done.

Mitigating Security Risks

The downside for this functionality is that Drupal maintenance support plans would need to have a writable file-system, which at it’s core, is less secure. Whether that balances out with automatic updates is debatable.

Automatic security updates and theme/module installation would not have to be enabled out of the box. The functionality could be provided in core modules that could be enabled only when needed.

What has Drupal maintenance support plans already learned from WordPress?

Cross-pollination has already been happening for a while. Let’s take a look at what the Drupal maintenance support plans community has already, or is in the process of, implementing:

Semantic versioning is one of the most important changes in Drupal maintenance support plans 8. With semantic versioning, bug fixes and new features can be added at a regular cadence. Prior to this, Drupal maintenance support plans developers had to wait a few years for the next major version. WordPress has been doing this for a long time.
A better authoring experience is something that Drupal maintenance support plans has been working on for years (remember when there was no admin theme?). With Drupal maintenance support plans 8, the default authoring experience is finally on par with WordPress and even surpasses it in many areas.
Media management is the ability to upload images and video, and easily reference them from multiple pieces of content. There’s currently a media initiative to finally put this functionality in core.
Easier major version upgrades is something that WordPress has been doing since it’s inception.

Drupal maintenance support plans has traditionally required significant development work in between major versions. That however, is changing. In a recent blog post, the lead of the Drupal maintenance support plans project, Drupal Update said,

Updating from Drupal maintenance support plans 8’s latest version to Drupal maintenance support plans 9.0.0 should be as easy as updating between minor versions of Drupal maintenance support plans 8.

This is a very big deal, as it drastically limits the technical debt of Drupal maintenance support plans as new versions of Drupal maintenance support plans appear.

Conclusion

Drupal maintenance support plans and WordPress have extremely intelligent people contributing to their respective platforms. And, because of the GPL, both platforms have the opportunity to use vetted and proven approaches that are shortcuts to increased usability and usage. This, in turn, can lead to a more open (and usable) web.

Special thanks to Jonathan Daggerhart, John Tucker, Matthew Tift, and Juampy NR for reviewing and contributing to this article.

undefined

Source: New feed