WordPress 3.8, now released in its redesigned glory, was the first WordPress version to make use of the new feature as a plugin development process. I think now might be a good time to take stock of the new initiative and see how it’s been going.
Feature as a Plugin? What’s That?
Well hello curious WordPresser. Feature plugins were formalized in the development process last August. In truth, the idea has been around for a while, but it is now the official methodology of the WordPress core team.
Basically, new features are developed in plugins first, then rolled into core once experimentation and testing is completed. This means that “feature teams” can work together on a single problem and iterate until they have a working solution. After that, the code is rewritten and migrated to core. And if the core team decides that they don’t want to include the feature, the plugin remains.
WordPress 3.8 Feature Plugins
If you’ve updated to WordPress 3.8 then you’ve already seen some of these feature plugins in action.
Probably the most common example is MP6, which has been rolling around the WordPress community for a little while now. In WordPress 3.8, it has become the foundation of the brand new responsive and flatter admin design. While the UI has retained most of its information architecture, it has been given a fresh coat of paint, with new icons, typography, homogenous color palette, and a generally cleaned up interface.
There were two other feature plugins that have been rolled into core. The first was DASH which overhauled the WordPress dashboard to make it simpler and more usable. There’s a lot less bloat on the screen now, so you only get information an admin user might actually need. The other is THX38 which is responsible for the new theme preview experience. Hopefully you’ve noticed that the new theme live preview is significantly better then we’ve seen before and it’s easier then ever to make small customizations to your theme’s style right from within the admin panel.
How’s It Looking?
Given the initial response, it appears that feature plugins are a resounding success. And there are certainly a few key advantages out there.
First, as I mentioned briefly before, features can now be easily organized into feature teams. Each member of the feature team works on a single problem and implements a single solution. That means plugins can be experimented with and edited without having to worry about a domino effect that might crash all of core, or adversely effect another feature. Once all the functionality of a particular solution is worked out in its entirety, then the core team can take the plugin and figure out the smartest way for it to be included. It’s a measure twice, cut once kind of philosophy.
It also makes testing dirt simple. Testers only need to download the plugin and start using it and pushing it to its limit. The instructions are simple and unilateral without the need to download nightly builds or hone SVN skills. Hopefully this will inspire more users in the community to get out there and start testing out new features.
Lastly, features that are not deemed necessary by the core team can still be available as a plugin. There are some features that only certain users will actually find helpful. There’s no need to waste value development time to create a new feature, only to have it discarded at the last minute. Instead, those users can download the plugin, available for everyone.
So What’s The Problem?
There’s no problem. Still, it’s important to question our assumptions along the way and make sure we are giving the process due diligence. After all, there are a couple of red flags for me regarding feature plugins. Nothing earth shattering, but I think worth mentioning.
The first is that developing plugins can be very different from developing for core. The actions and hooks that you use are entirely different, and even the basic structure of the code is changed. Fundamentally, plugins are meant to be developed as silos so they don’t conflict with other plugins and the core functionality of WordPress. Core features, on the other hand, need to be weaved into the code and coexist alongside every other feature. Migrating code from a plugin to core could potentially be a difficult process. In some cases, code will have to be significantly restructured. In the worst cases, code will have to be completely rewritten in order for it to play nice with the rest of the API. As long as the core team continues to integrate features from plugins intelligently, that won’t be much of a problem, but we have to keep it in mind.
They did a great job of that in WordPress 3.8. However, many of the changes made this time around were either aesthetic or mostly concerned with the admin’s front-end. When features have to be more heavily integrated into server side code, like the REST API that is still coming, it may require a bit more work. I think the process will hold up fine, but it may be worth evaluating.
Also, placing development teams in groups according to features is great but we have to make sure that proper communication is facilitated among them. Right now, with just a few features in the pipe, this has been more than manageable. The way the dashboard, theme menu and admin panel line up aesthetically and functionally is proof of that. But when more features need to be added, in a variety of different categories, communication will be key. I would hope that not too much development time gets eaten up trying to coordinate between the various teams. But the advantages seem to outweigh the negatives at this point.
For now, the features as plugins process will continue in full force, and I’m glad it is. There are a few more features that are currently in development to be implemented in future versions of WordPress using the feature plugin model. Features such as…
- The Search Initiative – based on the Omnisearch plugin. This will let you search the WordPress admin for custom post types, media attachments, and basically anything from the same search bar.
- JSON REST API – if you know what this is, you’re excited about it. If you don’t, know that it makes making queries to the server simpler, easier and quicker. Thanks to the work of Ryan McCue.
- AH-O2 – A new [admin help] that will help users with what they want when they need it. Currently in development by the docs team.
- Widgets UI – Making the process of adding widgets and customizing them even simpler. Hard at work by the UI team.
These are just the features that are currently in development, but there are currently more in the pipeline. As you can see new features will spread across different use cases and WordPress teams. As we move forward with the formalized feature plugin process, let’s make sure to keep ourselves in check and move the WordPress codebase even further.
Jay Hoffmann is a WordPress developer hailing from NYC. In the strictest sense of the word, he is a WordPress enthusiast with an eye for front-end development and design. He has been working with WordPress since 2006 and currently works for a popular children’s media company. This year, Jay started Tidy Repo, a curated list of the best and most reliable plugins from around the web. You can also follow Jay on Twitter.