Feature #10849
closedGutenberg / WP 5.0 upgrade strategy
0%
Description
WordPress 5.0.x was released a few weeks ago, and we have to decide how we're going to handle it on the Commons. The issue is the introduction of the new editor interface (called Gutenberg during development, and the Block Editor in the 5.0+ interface).
By default, if we upgrade to WP 5.0.x, all sites will be switched over to the new interface, with no way to switch back. There may be some technical issues; see https://redmine.gc.cuny.edu/issues/10146#note-7. The more serious problem is likely to be user confusion and obsolete documentation. So a sudden switchover is probably not the best idea. (Note that users have had the option to use Gutenberg for a few months, and to my knowledge we haven't had any reports of issues with it.)
At the other end of the spectrum, we can install the Classic Editor plugin, which has the option to completely hide the existence of the new editor across the network, and stick with the status quo indefinitely. This is probably not a good strategy either, since the new editor is the way of the future, and is legitimately better than the old one in many ways.
Between these extremes, there are a few ways forward. The Classic Editor plugin allows for some granularity regarding who sees what. For example, a setting allows site authors to select between the Classic and Block editors; this setting can be toggled on a per-site basis. It's also possible to write a secondary plugin that changes the behavior of the plugin on a per-site, per-user, or per-post-type basis.
I'd like to propose the following strategy, which I consider to be moderately aggressive. (The attached screenshots clarify some of these points.)
1. We upgrade to WP 5.0.x and add the Classic Editor, which will be network activated.
2. On all sites, we expose the choice between editors to individual authors.
3. On sites created before some date (mid-January?), the editor default will be Classic. This means that clicking Add New will launch the Classic Editor, but users will have the choice to switch to Block if they'd like. On sites created after that date, the editor default will be Block.
4. Site admins retain the ability to switch the default editor on specific sites, or to disable the ability for site authors to toggle between the editors.
I'm suggesting a January date above because it's going to be disruptive to switch people over mid-semester. But not changing the behavior of existing sites mitigates this disruption somewhat. We also don't want to force a situation where half the students in a class create a site with Block as default while half have Classic. So I'd suggest not making the switch mid-term. So we should do it now, or wait until after the Spring term is over. But the other steps would still be performed now, to start getting people acclimated to the new tool.
We could also move the entire project to the summer, forcing Classic behavior and totally hiding Block until then. I don't recommend punting the issue like this, but it's a viable choice.
Files
Related issues