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
Updated by Boone Gorges almost 6 years ago
- Related to Feature #10847: Select which blog posts are sent to group added
Updated by Boone Gorges almost 6 years ago
- Related to Bug #10146: "Try Gutenberg" flag added
Updated by Chris Stein almost 6 years ago
Boone, thanks for laying it out like this. I agree generally with your strategy and timeline. My only addition would be that we should have some kind of similar explanation for users on the site in the documentation and we consider not only the usual promotion but some kind of mass communication like a mass email or banner on the site.
Sonja with fresh eyes may have some insight into the efficacy of our existing communication strategies or ideas for new/revised means of communicating a change like this that effects so many users.
Best,
Chris
Updated by Matt Gold almost 6 years ago
Thanks, Boone. I am also mostly on board with this strategy. The one question I have is whether there is a way to put the choice between classic and block editor on the writing interface itself, in the way that the classic editor gave one the choice between visual and text editors.
Updated by Boone Gorges almost 6 years ago
Thanks, Matt. The problem with your suggestion is that switching between editors generally means changing the underlying structure of the posts, which is not foolproof in all cases. When taking a post started in Classic and editing it in Block, the content will be turned into a "Classic Block", with the option to convert it to separate blocks (per header, image, paragraph, etc). In the other direction, things are a bit hairier. It usually works fine to move back and forth, but not universally enough that we should be encouraging it.
Perhaps more importantly, we should not really be encouraging people to use Classic at all, at least not in the medium- to long-term. It will go away eventually.
Updated by Matt Gold almost 6 years ago
Okay. that's fine, then. we'll just need to document the process and perhaps do some outreach for people who might be confused
Updated by scott voth almost 6 years ago
Hi - I created a draft introducing Gutenberg and describing our update stategy on the News Site. Here is the link: https://news.commons.gc.cuny.edu/?p=4083&preview=true
Updated by Boone Gorges almost 6 years ago
- Target version changed from 1.14.4 to 1.14.5
Scott, thanks so much for the draft! Looks great for the most part. Just a bit of clarification about how the Classic option will actually work: The Classic Editor plugin will be (must be, technically) network-activated on the Commons. So site admins will not have the option to turn it off, and will not see it in the list of plugins. As such, we should hide references to the Classic Editor plugin. Instead, there'll be new sections at Dashboard > Settings > Writings that allow the admin to control editor behavior on the site. 'Allow users to switch editors' will be set to Yes by default, but if the admin decides to turn it to No, then the Classic and Block selector interface will disappear throughout the dashboard, and all posts will be created and edited in the editor set in 'Default editor for all users'. Does this make sense?
I'm pushing this to the 1.14.5 release so that we've got time to get our ducks in a row. (Also, that's a "major plugin and theme update" release, which is when we've historically done major WP updates.) After the 1.14.4 release tomorrow, I'll make the necessary changes and push them to cdev so that folks can play with them.
Updated by Boone Gorges almost 6 years ago
One more thing - the 1.14.5 release will take place on Jan 22, so you should safely be able to fill in that date.
Updated by Matt Gold almost 6 years ago
Can I just editorialize and say that I used Gutenberg for a recent post on my own blog and GAH it is pretty terrible. I was pasting a talk from a Word doc into a blog post. Each paragraph became a separate content blog that had to be edited individually.
Updated by Boone Gorges almost 6 years ago
Look around - most of the technological present is pretty terrible. This thread is about developing a coping strategy.
Updated by Boone Gorges almost 6 years ago
- Status changed from New to Testing Required
This is ready to test on cdev. Changesets:
- https://github.com/cuny-academic-commons/cac/commit/ffc46d88f214c0e0320764e970382f38188e3dc0 updates to WP 5.0.x
- https://github.com/cuny-academic-commons/cac/commit/4d39c7c5f8ebb632b208f52453877fef84f60b74 installs classic-editor
- https://github.com/cuny-academic-commons/cac/commit/0fd3364711212779c9c2b723aa3304ce87ed386f sets defaults
As noted above, defaults are:
1. Individual users may switch between editors
2. The default editor for old sites is Classic, the default editor for new sites is Block. (What counts as "old" on cdev is "created before Jan 1 2019". This will be set to the launch date of 1.14.5 for the final release.)
Site admins may change these settings on a per-site basis at Dashboard > Settings > Writing.
Updated by scott voth almost 6 years ago
Hi - I checked out Dev site and have updated the "news" post -https://news.commons.gc.cuny.edu/?p=4083&preview=true - Boone can you read to ensure I have everyting correct. I also have a hero slide ready to go - whenever. Do we want to notify members ahead of the Jan 22nd release? I can also let members of the WordPress Help site know about the change
Updated by Boone Gorges almost 6 years ago
Technical details look good, Scott. Thanks! I will say that the tone of the message feels pretty negative to me - "here's Gutenberg, we know it stinks, but get used to it". This may be what we indeed feel, but is it what we want to say to our users? I don't care too much either way, just thought I'd raise the issue :)
I don't see a reason to warn people of this. It will not affect existing sites, so there's nothing to prepare for. Any confusion will only arise for experienced Commons users creating sites after the 22nd. (On that note, it seems to me that the phrasing of the blog post might be rethought a bit in order to deemphasize the Jan 22nd date - since the blog post will have that publication date, it may suffice to say that "existing sites will continue use the Classic Editor, while the default for new sites will be Block" or something along those lines. But this too is just a minor thing - what you've got there is good too.)
Updated by Matt Gold almost 6 years ago
FWIW, I just took a look and don't find the page overly negative. I think it foregrounds the controversy over this (which seems reasonable to me) and is written for people who may be coming to it confused or upset over the change. So, f you want to soften the language a bit to respond to Boone's concerns, Scott, please do, but I don't think it needs all that much further editing myself.
Updated by scott voth almost 6 years ago
Ok - I will look to lighten it up a bit :) So are we going to plan to publish on Jan 22nd when we move to WP 5.0, or do we want to publish before that?
Updated by Boone Gorges almost 6 years ago
Doesn't matter to me whether we publish early or not. My thought is that it's not really actionable info until after the release, so I'd lean toward waiting.
Updated by Boone Gorges almost 6 years ago
- Status changed from Testing Required to Resolved
About to ship this, so I'm closing. The release will be live within the next 30 minutes or so.