Update: The Custom Taxonomies for Blocks plugin is now available on the WordPress plugin repository.
This past weekend was WordCamp U.S., and while Taupecat Studios didn’t attend in person, there was one session in particular I was very interested in and made sure to catch on the livestream: It was a panel featuring WordPress core developers Andrew Nacin, Mika Epstein, and Jake Spurlock regarding the proposal to automatically update all of the “older” versions of WordPress out on the Internet to the latest version.
I’ve already seen where blindly updating an older version of WordPress to 5.* could cause custom taxonomies to no longer work, and want to make sure the community—and more importantly, WordPress site owners—know about this potential problem and how to resolve it, especially if auto-updates to major versions moves from proposal to reality.
Automatic Updates
If you haven’t followed this proposal, it has generated quite a bit of controversy. Much of it revolves the legal ramifications: is the WordPress project breeching the trust of site owners by instigating a major-version update without their opt-in?
While the legal questions are certainly worth debate on their own, it’s not my primary concern. Rather, WordPress core has undergone a number of significant technical changes since auto-updates for minor versions were implemented in version 3.7 (October 2013). Two technological changes in particular are at play here: the integration of the WordPress JSON REST API into core in version 4.7 (December 2016), and the integration of the “Gutenberg” block editor interface in version 5.0 (December 2018).
A step back as to why these are so concerning to me as a developer: While I was en route to PressNomics this past September, a client from my previous role at another agency contacted me to say that their IT department had recently updated their WordPress installation, and now things were broken. After a few back-and-forth emails and a phone call, it became clear to me what had happened: the custom taxonomies that I had written those many years ago, before the REST API integration and block editor roll out, were no longer compatible with the changes that had taken place in WordPress core. The quick answer was to install and activate the Classic Editor plugin, which fixed the immediate problem.
In the lead-up to WordCamp U.S., and during the session itself, I tried to get an answer regarding this problem. If this proposal were to go forward, I maintained that two other actions need to happen:
- The Classic Editor plugin needs to be installed and activated when a site is being updated from pre-5.0 to 5.*; and
- A big, obvious “Roll Back” button needs to be made available so site owners who weren’t prepared for the update can go back to their previous version
It has been frustrating that to this point, this problem has not been addressed by anyone on the WordPress core development team. Much of the talk around what constitutes a “failed” update, or a “broken” site involved a problem with the update process itself, not a “successful” update that left functionality degraded, but not actually causing a “white screen of death” type error.
I tried to pose this question to the panel, but questions from Twitter ended up not being asked, likely due to time constraints.
The Technical Problem
On the technical side, here’s the problem: In order for a taxonomy to be compatible with the block editor, it must have its “show_in_rest” property set to true. This property was added with the REST API integration in version 4.7. However, the default value for this property is false, for reasons that completely elude me. Additionally, the main documentation page for registering a custom taxonomy doesn’t state what the default value is; one has to read the WordPress core source code to find it.
So with the default “show_in_rest” property value for custom taxonomies being false, and any custom taxonomy registration code written prior to December 2018 likely missing explicitly setting it to true, most custom taxonomies created before this date will not be compatible with the block editor. That’s potentially a lot of custom taxonomies on older, but still actively used, WordPress sites.
Custom Taxonomies for Blocks
Installing and activating the Classic Editor plugin is certainly a viable solution, but it’s not a panacea. I’m sure there are likely instances where a website owner will want to use the new WordPress block editor interface and all the benefits it brings to the table, but will not want to undertake the expense of having a developer review their old custom code in order to update the taxonomies.
Furthermore, while no definitive end date has been given to Classic Editor’s support, Matt Mullenweg in his State of the Word address indicated that support would not go on forever. Eventually, all actively maintained WordPress sites will need to adopt the block editor interface.
Therefore, Taupecat Studios has created the Custom Taxonomies for Blocks plugin which specifically addresses this issue. (It’s currently awaiting review by the WordPress Plugin Review Team, but until it appears in the WordPress.org plugin repository you can pull it from GitHub here.) All it does is take any custom taxonomy whose “show_in_rest” value is false and changes it to true so that it will work in the block editor, and it’s freely available for anyone to install and activate from the WordPress plugin repository.
Doesn’t Solve All the Problems
However, this plugin alone won’t solve all the problems that upgrading to WordPress 5.* raises. After all, a website owner needs to understand what the problem is, and that this plugin exists to solve it. Given the lack of response I’ve received on this issue since I first raised it in September, I’m not optimistic about the prospects of publicity for this plugin other than my own direct efforts.
Furthermore, this plugin only addresses one potential technical problem that auto-updates could reveal; there could potentially be many others that haven’t been uncovered yet.
The WordPress project has long prided itself on its backward compatibility with previous versions, but now we’re running headlong into a problem where backward compatibility is simply failing users of older WordPress sites. Classic Editor and Custom Taxonomies for Blocks are two technical attempts at a solution, but they rely on site owners being aware that they exist, and that, in of itself, is a huge problem.
A Side Note About How Taupecat Studios Handles Updates on Pantheon
The problems my former client experienced were exacerbated by the fact that they updated their production website without testing the update on a staging instance first. Using a staging instance would have allowed them to test their site for potential issues, such as this one, and then stop the process before it hit their production website.
When we update our maintenance plan WordPress websites with plugin and WordPress core updates, we always do so first on a staging instance and test for major issues. Sometimes, minor issues slip by us, but we have a process that allows us to easily roll back to previous versions if any issues are uncovered in the update process.
Our webhosting partner, Pantheon, is a great ally in this. All websites hosted on Pantheon come with development and test (staging) instances that are separate from the live (production) instance, allowing an easy workflow and testing updates before they hit the production site. Furthermore, Pantheon’s architecture won’t allow the WordPress auto-updates mechanism—even the one currently in place for minor revisions—to happen. Security is not compromised because no changes are ever allowed to happen to the file structure of production WordPress sites on Pantheon without going through their workflow, and we take a lot of comfort in that fact.
Do you have an older WordPress site whose code hasn’t kept pace with the technological changes happening in WordPress core? Get in touch with us and let us know how we can help.
Photo by jesse orrico on Unsplash
