Preparing Plugins for the New WordPress Editor
Our team is excited to see Gutenberg’s full integration into WordPress on the horizon. Our clients, partners, and colleagues are shipping useful, powerful projects with the new content editor everywhere you look. However, if you think back a few months, there was some initial anxiety around how we’d get our arms around a big bag of unknowns.
One of the most challenging of those unknowns was plugin compatibility. Like any group that supports active plugins, we wanted to make sure our code would work with Gutenberg as quickly as possible. And until we dug into it, we didn’t know if that was going to require a little work, a ton of work, or something in between.
Facing this uncertainty, we took a big deep breath…and started testing! We’re in a pretty good place now, and want to help others get there, too. We’re sharing our findings and process here for those who may be at that “I don’t yet know what I don’t know” stage in their Gutenberg transition.
First, we had to decide where and how to focus our efforts. For us, we needed to think about how our plugins are used within VIP/Automattic and how they’re used by the WordPress community at large. We also had to consider all the third-party plugins clients may be using on our platform. And although we can only directly impact the first of those two areas, we decided to cast a wide net and study all three, to see what we could learn and share.
We’ve been advocating for a transitional approach to Gutenberg, so we decided to break this project into manageable stages for ourselves:
- Assessment > test plugins to ascertain their level of Gutenberg readiness
- Compatibility > make sure stuff doesn’t break with Gutenberg
- Optimization > update plugins to make full use of Gutenberg’s features (Gutenberg native)
Next, we had to define “compatible”, and come up with concrete testing steps for our team. Daniel Bachhuber has already done awesome work in this space. Rather than re-inventing the wheel, we based our approach on his very well thought-out definitions he developed as part of the community plugin compatibility database project here.
- A plugin is compatible with Gutenberg when:
- A user can perform the same functional task with Gutenberg active (feature-parity), and;
- There are no (obvious) errors when the plugin is active alongside Gutenberg.
- A plugin can be marked as ‘Likely Compatible’ based on reasonable assumptions (e.g. a caching plugin probably doesn’t expose editor-specific functionality).
- A plugin can be marked as ‘Optimized’ if it is making best use of Gutenberg features (e.g. shortcode has been converted to blocks).
Finally, we had to collate a list of plugins for testing, and enlist volunteers*! We divvied up our own plugins amongst VIP team members and reached out to 3rd party plugin vendors encouraging them to test their work and share their results with us.
*A HUGE thank you to all the plugin authors who responded: Daniel Bachhuber, Michael Bester, Lester Chan, Brad Kofoed, Chris Northwood, Chris Scott, Justin Tadlock, 10up, Alley, Codepress, Delicious Brains, Getty Images and @scribu. Your contributions were extremely helpful for us, and will help the entire community as we all work towards this brave new Guten-world!
Helpful Tips for Plugin Testers
- Breaking it down into realistic, manageable stages made this task achievable. We’d definitely recommend this approach to other developers with a similarly large portfolio.
- Be on the lookout for plugins which add media buttons in the classic editor. Those buttons are unlikely to be exposed in Gutenberg unless the author has made special provision for it, making this a common culprit for incompatibility.
- There are some common compatibility issues to look out for with Metaboxes.
- Plugins that contain metaboxes may be compatible without doing anything. If they are, the compatibility argument should be added in the short term. Long-term, metaboxes should be converted into blocks to be considered optimized.
- There are ~167 different plugins running on VIP.
- 39 of those plugins are maintained by Automattic/VIP, of which:
- All 39 have been tested
- 34 are compatible or likely compatible
- 5 are not compatible
- 128 of those plugins are by 3rd party developers, of which:
- 14 have been tested
- 10 are compatible or likely compatible
- 4 are not compatible
If your assessment reveals that you support active plugins that haven’t yet been accounted for, the best place to share what you find is the plugin compatibility database.
We will take a closer look at the 5 Automattic/VIP plugins found not compatible and take appropriate action to remedy. Testers have recommended 3 of them to be deprecated. Others will be updated for Gutenberg compatibility.
We will add our results to the public plugin compatibility database.
We will continue working with 3rd party plugin developers encouraging compatibility testing and updates.
Over the long term, we are working towards our stage (3) goal of optimizing our plugins to make the best use of Gutenberg features, i.e. Gutenberg-native.
- Testgutenberg.com: Front-end playground
- VIPGutenberg.com: How-to videos
- Gutenberg handbook: Main reference on WordPress.org
- VIP News initial post: Introducing the Gutenberg project
- VIP News readiness recommendations: Getting ready for testing
- Plugin Compatibility Database: Community project led by Daniel Bachhuber