Upgrading to 5.0 and handling the Gutenberg plugin

[mcsf]

Once 5.0 lands, a process will be needed through which users running 4.9.* with the Gutenberg plugin activated can have the plugin automatically deactivate upon upgrading to 5.0. As is expected.

As a feature plugin, Gutenberg differs slightly in a couple of ways:

• Gutenberg development — phase 2 and beyond — will continue via the plugin. A small subset of users may be interested in remaining on the faster-iterating cycle of the plugin.
• The feature being merged, i.e. the new editor, can be disabled by way of a second plugin: Classic Editor. Although everything is being done to eschew its need, it will nevertheless be sought by many.

These beg a few of questions:

• How much information should be offloaded to the “Welcome to 5.0” post-upgrade page and what should we handle separately?
• Should we account for the prospective intent of some users to keep using the Gutenberg plugin?
• Should the message conveyed vary depending on a user’s installed plugins (Gutenberg, Classic Editor)?

The overarching goal for the entire process should be to minimize the user’s burden of choice, especially upfront choice (e.g. requiring a decision before trying the changes), and the anxiety that comes with it.

Thus a tentative flow could be:

1. User requests 5.0 upgrade.
2. Upgrade is carried through.
3. In the process, the Gutenberg plugin is deactivated. No user action is required (nor is any explicit notice of this deactivation necessary).

And that’s it in terms of flow. After the upgrade, the 5.0 Welcome page should present Gutenberg as a highlight of the release. Perhaps this page is enough.

If not, should a ​callout-like header appear in WP-Admin, letting users know about the Gutenberg plugin and/or Classic Editor?

cc @pento

[netweb]

Related: #45063 Remove the "Try Gutenberg" callout

[JoshuaWold]

I spent a little bit of time thinking this over today and trying to figure out the various flows for which plugins might be installed. I welcome feedback on my initial thoughts. Are there steps that should be added or removed from the flow I’ve sketched out?

Thank you!

[mcsf]

@JoshuaWold: this is great, thanks for flow sketch! On the surface, the one thing I would change would be to bring path 2 next to path 4 so that we can better highlight that they are functionally the same path.

Also, I believe you may have forgotten to note, in path 3, that the Gutenberg plugin gets deactivated right at the beginning (after WordPress 5.0 is available'').

[JoshuaWold]

@mcsf thanks for that feedback. Updated the sketch to account for that. Thinking through one more use case and then will post an update

[JoshuaWold]

Sharing an updated flow with a few changes based on feedback here and some additional feedback I received:

1. Path 2 and 4 are now next to each other to show how similar they are (kept the names the same)

2. On Path 2 and 4 you'll see a new message that lets users know that they'll keep the classic editor experience, as a reassurance.

--

One additional thing this doesn't account for is the Gutenberg Ramp plugin. Should we think through what that looks like in this flow?

[mcsf]

One additional thing this doesn't account for is the Gutenberg Ramp plugin. Should we think through what that looks like in this flow?

Good question, but Ramp is an Automattic plugin and thus shouldn't be contemplated by core. Only Gutenberg and Classic Editor are official plugins.

[blvtomoya]

I have a question about Path 2.

When the Classic Editor plug-in was enabled
Does that mean that warnings will continue to be displayed forever?

I understand that I use the Classic Editor plug-in and it is not a pleasant thing to always be warned.
Is there any freedom to hide it once?

[postphotos]

Does that mean that warnings will continue to be displayed forever?

@blvtomoya - @JoshuaWold and I worked on update to this user flow yesterday... I think he'll be posting it sometime tomorrow. The suggestion we've agreed that makes sense here is to nudge a user in the right place (e.g. on the "5.0 Welcome" screen, perhaps on the main dashboard, etc.) there would be dismissible notices that encourage sites to try Gutenberg. I think it's important to encourage, but not to force, users to try the new editor. We also think it's important to tailor the messages on the 5.0 Welcome page based on path that site is in the userflow presented. In short, some sites are ready to dive deeply into Gutenberg, others will take a while to get there. (We hope not too long.)

Also, a heads up - there's a mistake in the current sketch in flow 2 that reads:

Would you like to try the new editing experience? Requires deactivating classic editor plugin.

This would appear in Classic Editor, probably above a post.

Just as you can now use both the Classic and Gutenberg editors in a paired mode, you'll be able to do the same from 5.0. Our suggestion would be that another encouragement would appear n # of times (three?) but also be dismissible probably though a toggle in Screen Options as is the pattern to hide/show things in the current interface for WordPress. But if it's not for you yet, that's fine too.

We believe W.org's intent is to show that Gutenberg provides great value, and we there's an important effort here to provide enough of a way for sites to hold off if they need to, hence the reference to ​Gutenberg Ramp earlier, which takes the Classic Editor controls and expands them a bit further to encourage an opt-in experiences for sites that need that functionality fully.

@mcsf - Speaking of which, we'll take the discussion regarding Ramp to the appropriate repo to focus this discussion :)

[cathibosco1]

"Just as you can now use both the Classic and Gutenberg editors in a paired mode, you'll be able to do the same from 5.0. Our suggestion would be that another encouragement would appear n # of times (three?) but also be dismissible probably though a toggle in Screen Options as is the pattern to hide/show things in the current interface for WordPress. But if it's not for you yet, that's fine too."

To me using the Screen Option to control your screen is a winning idea! - Are we updating or adding content to the Help regarding this? (the help dropdown next to the Screen Options is contextual depending on the admin page you are using. I don't have a recommendation but utilizing it could be usefulto consider too.)

[postphotos]

@blvtomoya Also, of note, if you truly wanted to suppress these notices, ​there are plugins available that can set custom Screen Options for all users.

@cathibosco1:

Are we updating or adding content to the Help regarding this? (the help dropdown next to the Screen Options is contextual depending on the admin page you are using. I don't have a recommendation but utilizing it could be useful to consider too.)

In regard to the "Help" section next to the screen options, it'd be great if there were a new "About the Classic Editor" section that described a short synopsis of what this editor was designed to do and another minor callout to Gutenberg.

FWIW, it won't be long until we start to see plugins that don't have compatibility with Classic, and of course, the core features are being developed for the new editor. Something like:

About the Classic Editor

The Classic Editor was the default editor before 5.0. It uses an older approach toward content authoring, encouraging shortcodes, metaboxes and lots of things. etc.

For all the latest features in WordPress, we recommend you switch to the new editor, which is significantly more powerful for authoring, media management and publishing. You can do everything that you can do in Classic, and more! To learn more about the new editor and how to switch, read here.

(^{Also, please revise this first draft!!)}

[cathibosco1]

Good first draft @postphotos

About the Classic Editor

The Classic Editor was the default editor before 5.0. It uses an older format for content authoring.

For the most current features in WordPress, we recommend you switch to the new editor, which is a significant upgrade with more dynamic experiences authoring, managing media, and publishing. You can do everything that you can do in Classic, and more! To learn more about the new editor and how to switch, read here. (where should it link to?)

Any additional suggestions?

[postphotos]

@cathibosco1 -
I know @gidgey and I have talked in the past that a critical need for W.org sites to succeed in the transition to Gutenberg is going to be not only community support, but documentation. Maybe this is something the marketing team can help construct? Essentially,

I think there's a few links that @JoshuaWold and I are thinking of:

• An "About Gutenberg" page
• A "How to Switch" guide (In particular, your copy block should link to the transition page described here)
• A "Don't be afraid, Gutenberg doesn't kill your classic" page

The last one should also be described in our draft help text, e.g.

If you aren't ready to switch yet to the new editor, Classic will be around for a while. Make sure you keep the classic plugin activated and updated. Read more about this.

[bridgetwillard]

I know we'd love to help write that copy, @postphotos. Let us know if we should start some Trello cards.

[postphotos]

@bridgetwillard - yes, please, if you can see if folks are interested in contributing here that would be great!

This set of pages and whether we'd like to create them impacts this ticket as it explains how the user goes on their journey past the main flow.

I know you saw I posted in the #marketing channel in Slack today, and @mcdwayne ​suggested this might need to go to Meta, but here's a few more thoughts on what that would look like in execution. In summary, we're focused on how to handle Classic Editor plugin activated sites via Core, and what callouts they'd see to go to discover about Gutenberg.

I think the current main URL - ​http://wordpress.org/gutenberg - would serve as a good landing place for what's been called here the "About Gutenberg" page, but the other two would be linked to provide ease of action for users. We'd not need to touch this for those links in the current proposed user flow.

The other two suggestions, though, would help round out the user flow efforts to explain actions they could or would take. In summary, we'd need some help writing:

• A "How to Switch" guide that talks about sites with Classic Editor on default going through a testing or transition process. It wouldn't be too technical; more so an encouragement to test, back up, stage, etc. It'd also highlight that switching is probably safe for many users. I know @danielbachhuber did a ton of work in ​prepping a technical guide that's spot on and quite informative that we should link to, and there is also ​the Ramp plugin by VIP already mentioned that makes switching in a slower state much easier. There's probably more someone could write on the subject, too, like trying that "Gutenberg" URL above.

• A "Don't be afraid, Gutenberg doesn't kill your classic" page (that probably has a better title) that explains that Legacy support was a requirement for the tooling of the new editor, and that as of now, the "5.0 + Classic Editor plugin" would be 100% the same as "4.9.8 + Gutenberg plugin." It probably attempts to quell discussions of the need for a fork, an LTS or wearing of a tinfoil hat to keep using WordPress. (None of those are needed.) This upgrade path question is what so many people have been clamoring about, and the project needs to address it straight on.

For both, I'd probably talk about the block conversion tooling of Classic-to-Guten and Guten-to-Classic. So much effort went into solving this problem, and that testing, trying and playing is encouraged.

The goal that @JoshuaWold and I have in regard to user flow is to allow sites understand what's going on, how they could respond and what they should probably do next, so that they confidently make the choice to switch at this stage if they've actively chosen not to proceed (via installing Classic.) We feel Gutenberg is worth the effort in playing with and converting to, it's all about how, when and to what extent on a per site basis.

[JoshuaWold]

Thank you for all the great discussion and feedback! Based on this I've made some changes to the sketches and updated them into full mockups in Sketch (file available if anyone wants!).

Please take a look at the image below and give your feedback on the flow of each path. I've made some copy suggestions throughout (very much placeholder), so I welcome feedback on ways to improve it.

[chanthaboune]

Replying to postphotos:

@cathibosco1 -
I know @gidgey and I have talked in the past that a critical need for W.org sites to succeed in the transition to Gutenberg is going to be not only community support, but documentation. Maybe this is something the marketing team can help construct? Essentially,

Documentation is being worked on/coordinated in a different ticket. We should move this discussion to ​https://github.com/WordPress/gutenberg/issues/10549

[JoshuaWold]

Sharing a new version of this based on feedback in the #design Slack channel during our previous Bug Scrub.

1. Added the option to re-activate Gutenberg on path 4
2. Added an option to install the Classic Editor on the update page if you're on Path 1.

Note: I think this is enough, it was suggested by @postphotos to potentially group together the ability to install the plugin and update at the same time, but that seems like an unnecessary complication.
Additional note: @joyreynolds brought up a great point regarding 4.9.3 users having an update and not seeing anything about Gutenberg until this update hits. The minor change above for Path 1 may be enough for them to learn more about Gutenberg and activate the Classic Editor if need be. Welcome feedback on this point!

3. Removed the checkmark to validate that you want to update. It was discussed as adding unnecessary complication to the update process.
4. Simplified the text on the WordPress updates page. It should now be easier to read and easier to translate.
5. Re-arranged the paths so they're shown sequentially.

[JoshuaWold]

A new week, a new update to the mockups :). We had a great Slack chat about this today in the #design meeting, so wanting to share the update!

1. Developer note: if you see blue underlined fonts next to normal black fonts those are all intended to be the same size font, Sketch might just be rendering it differently.
2. Updated the "Beta" tab on paths 3 and 4 to "What's New", and changed the copy inside.
3. Made a minor note to the developer notes on paths 2 and 4 at the bottom.

Unless something else comes up we can consider this ready for development.

@mcsf and @karmatosed do we have someone available to work on this? :)

[mcsf]

Replying to JoshuaWold:

A new week, a new update to the mockups :). We had a great Slack chat about this today in the #design meeting, so wanting to share the update!

Great, @JoshuaWold!

do we have someone available to work on this? :)

I'll should either find someone in the next day or two, or assign myself.

Unless something else comes up we can consider this ready for development.

I may or may not get back to you on the pre-upgrade copy, depending on technical feasibility. I'm waiting for someone's input on it. :)

[dd32]

Hi :) This comment might seem a little blunt and out-of-nowhere, but it turns out I have some strong feelings here, and this ticket seems to be going in a direction that I don't think is right, this is meant constructive and I'm happy to work with anyone else to come to a final solution here (DM me on Slack if needed)

---

Speaking from a practical stand point here, a lot of what I'm seeing within Upgrade Paths revision 2.jpg​ doesn't feel ideal, and is definitely not the message which I believe WordPress should be putting forward here.

The post-upgrade screen should be a celebration of the new editor, it shouldn't be giving the feeling of half-baked or "you probably don't want this" which I'm getting from the proposed changes.

A small side-note of Things not working as expected? The _Classic Editor_ plugin is available is reasonable, but definitely shouldn't be front-and-center.

Upgrade Path 1 - No Plugins

WordPress 5.0 is available - This update brings a whole new editing experience ...

Unfortunately at present we don't have the ability to customise the display of the update message about the upcoming release in previous WordPress versions.
If anything though, such a message should be positive and shouldn't be giving mixed signals or giving the user fear of clicking the button.

If we really need to add the message there, that'll require a 4.9.9 release prior to 5.0 to add that feature - but keep in mind that not all users will be upgrading to 5.0 from such a 4.9.9 release.

The new Gutenberg editor is now your default editor. Do you want to change that? learn more

Asking the user immediately after updating feels like the wrong time to be asking this, it's just way too early.
The user is unlikely to be informed and probably doesn't know what "Gutenberg" is anyway (either by codename, OR by using it).

To me, it feels like we're jumping ahead and saying "Hey, we've changed things and we're not really sure it's for you".

Welcome Box: Try the new editor ...

That feels way out of place as well, most users would have probably hidden that box as well, the main audience of it is the new users on a fresh WordPress site.

Upgrade Path 2 - Classic Editor plugin activated

Seems like the Classic Editor plugin should definitely add a note to the post-Upgrade screen and to the new-post screen to mention that it's active, and it's changing the experience the user will get.

I don't think that's something that Core should do at all.

Upgrade Path 3 - Gutenberg plugin activated

As core will be disabling the Gutenberg plugin, there should be a bold obvious note of that. I think it's reasonable to expect that if a user has the plugin installed, they have seen the phrase Gutenberg and has probably tried it. The note should be only really be outweighed by the "Welcome to 5.0" heading, and there's zero reason to hide it away in a tab - doing so is just asking for it to be never read, and possibly leading to a confused user later.

I'd suggest something like this: (of course, this needs a lot of word-smithing)

The Gutenberg plugin has been deactivated, as the features are now included in WordPress 5.0 by default. If you'd like to continue to test the upcoming changes in the WordPress Editing Experience, please [Reactivate the Gutenberg Plugin].

---

Based on the above, I believe the focus of this should be a little more clear and concise:

• Ensure that the Classic Editor plugin properly announces itself where needed (Including it adding a note to the post-upgrade page if needed)
• Ensure that the Gutenberg plugin is disabled upon upgrade to 5.0, and if it was active, that status be noted for later use
• Add a positive note welcoming the user to 5.0 with it's new editor. Maybe with a small side-note that the Classic Editor plugin is available if required
• [If Applicable] Add a warning/note which is obvious to the user that the Gutenberg plugin was disabled as the feature-set is now included, and that if they'd like to continue beta-test Gutenberg Phase 2+ things that they should reactivate the plugin.

[mcsf]

Replying to dd32:

Thanks for the comment. First of all, my apologies to all involved in this ticket, as I should have corrected its course earlier.

Unfortunately at present we don't have the ability to customise the display of the update message about the upcoming release in previous WordPress versions.

This was one of the things for which I needed to set time aside in order to better understand core's upgrade process. Indeed, any change in the pre-upgrade copy would require a 4.9.9 release, which I would really like to avoid for many reasons.

As such, we need to say no to any sort of messaging in core that happens before the upgrade.

The post-upgrade screen should be a celebration of the new editor, it shouldn't be giving the feeling of half-baked or "you probably don't want this" which I'm getting from the proposed changes.

I agree that a better balance is needed here. The starting focus of this ticket was the flow moreso than the copy, but it's time to look at that now.

Asking the user immediately after updating feels like the wrong time to be asking this, it's just way too early.

Agreed.

The user is unlikely to be informed and probably doesn't know what "Gutenberg" is anyway (either by codename, OR by using it).

The name Gutenberg should probably be left out of the messaging unless a user has the Gutenberg plugin installed. At most, it should be mentioned as a codename when pointing to a canonical reference such as wp.org/gutenberg (e.g. "Read more about WordPress's new block-based editor, codenamed Gutenberg, […]").

Seems like the Classic Editor plugin should definitely add a note to the post-Upgrade screen and to the new-post screen to mention that it's active, and it's changing the experience the user will get.

I think a lot should be offloaded not just to Classic Editor, but also to the Gutenberg plugin. Actually, this is in line with:

I'd suggest something like this: (of course, this needs a lot of word-smithing)

The Gutenberg plugin has been deactivated, as the features are now included in WordPress 5.0 by default. If you'd like to continue to test the upcoming changes in the WordPress Editing Experience, please [Reactivate the Gutenberg Plugin].

Setting aside the technical means and recapping in terms of user interactions, the bulk of these should be limited to the post-upgrade page and timely WP-Admin notices. I can see the Help drawer be updated to provide context for the user, but this should be dealt with separately, likely led by the Docs team. I'm not sure about Screen Options.

Finally, I think we can separate responsibilities a little:

• Classic Editor could absorb some of the communication seeking to assuage the user who is afraid to upgrade or to lose legacy functionality. It could even reach out to the user, once 5.0 is out, pre-emptively informing of this available upgrade even if the user isn't looking at the Updates page.
• The Gutenberg plugin would make its own case to its users, informing them that they can get on the Beta track by reactivating it.
• Thus, changes in Core would mostly be limited to the post-upgrade page, which gives us a nice narrower scope but also, personally, greater confidence that we aren't "tainting" core's upgrade process with new logic.

[dd32]

The Gutenberg plugin would make its own case to its users, informing them that they can get on the Beta track by reactivating it.

As Core will be the one deactivating the plugin, Core will have to be the one with the messaging as Gutenberg will no longer be active on the site at that point :)

[mcsf]

Replying to dd32:

As Core will be the one deactivating the plugin, Core will have to be the one with the messaging as Gutenberg will no longer be active on the site at that point :)

Yes, though maybe a deactivation hook in Gutenberg could be the one requesting that a certain notice be shown? Core would then have to honour it.

[JoshuaWold]

Thank you for the great feedback. We also had an extensive discussion on ​Slack about this. Based on the feedback, and technical limitations, it looks like we need to make the following changes:

1. The classic editor path shouldn't be considered here, instead that should be an issue created and handled over on the Classic Editor repo. As such I've crossed it out.
2. We can't change the update message prior to updating (at least not without releasing 4.9.9 to change the way that messaging appears). So all the paths will need to be the generic update message, no message can be presented ahead of time that the editor is going to change.
3. The messaging for Classic Editor should be more friendly.

I've made a few changes based on this feedback, and will attach it below. Please let me know something has been missed.

Thank you!

[mcsf]

Replying to JoshuaWold:

Thanks for the revision, Joshua! Some observations on the latest attachment:

• In flow 4, it may not be immmediately apparent that last two illustrations show notices rendered by Classic Editor and not core, the same ones that were deleted in flow 2. It makes sense to show them in the flow, but maybe the document can highlight their source.

• Flows 3 and 4 haven't addressed the question of visibility around a What's Next tab. I don't mind having that tab there, but wonder if instead another notice might be a more flexible and visible mechanism.

Nothing else to point out at the moment. :)

[remediosgraphic]

"How much information should be offloaded to the “Welcome to 5.0” post-upgrade page and what should we handle separately?"

WP 5.0 have a big visual change on WordPress content creation, so let every user know again about this is very important. A link to how Gutenberg work and how install the classic editor is a must.

"Should we account for the prospective intent of some users to keep using the Gutenberg plugin?"

As Gutenberg is native on WP 5.0 the update should deactivate the plugin by default. Manually deactivate this is more clicks and work for the user.

"Should the message conveyed vary depending on a user’s installed plugins (Gutenberg, Classic Editor)?"

The message can be the same but is important show on the welcome board the link to the classic editor plugin.

[JoshuaWold]

@mcsf

In flow 4, it may not be immmediately apparent that last two illustrations show notices rendered by Classic Editor and not core, the same ones that were deleted in flow 2. It makes sense to show them in the flow, but maybe the document can highlight their source.

Updated in the attachment below. What do you think?

Flows 3 and 4 haven't addressed the question of visibility around a What's Next tab. I don't mind having that tab there, but wonder if instead another notice might be a more flexible and visible mechanism.

This may be lame, but we could put an icon beside the "What's Next" label, or change the background color to make it stand out more. Beyond that we could add a section below the what's new paragraphs, highlighted like an alert, offering the message to re-activate Gutenberg. Thoughts?

@remediosgraphic

Thanks for jumping in with feedback. It's much appreciated!

WP 5.0 have a big visual change on WordPress content creation, so let every user know again about this is very important. A link to how Gutenberg work and how install the classic editor is a must.

On Path 1 where would you propose putting in this message, and what would the message look like?

As Gutenberg is native on WP 5.0 the update should deactivate the plugin by default. Manually deactivate this is more clicks and work for the user.

I believe this the case, as proposed in Paths 3 and 4. Am I missing something?

[mcsf]

Replying to JoshuaWold:

Updated in the attachment below. What do you think?

Yup, that's it!

This may be lame, but we could put an icon beside the "What's Next" label, or change the background color to make it stand out more. Beyond that we could add a section below the what's new paragraphs, highlighted like an alert, offering the message to re-activate Gutenberg. Thoughts?

Hm, I'm not super convinced by adding an icon, but adding a note — whether rendered as a notice or strong copy — in the main What's New panel sounds better to me. I think that would altogether eschew the What's Next tab.

A link to how Gutenberg work and how install the classic editor is a must.

In related news, this is relevant to the ticket:

Since the Classic Editor plugin is central in this transition, we are considering including it with upgrades to WordPress 5.0. New WordPress installs would still add it manually, and we’ve included it in the Featured Plugins list to increase visibility.

— ​https://make.wordpress.org/core/2018/11/07/classic-editor-plugin-support-window/

[azaozz]

I'm pretty much with everything @dd32 said above. Just one (technical) exception: it would be better if core would include any warnings about the Classic Editor plugin being active (and preventing the Block editor from loading). The reason is simple: if that text is in core, it will get translated. If it is in the plugin, there would be only few translations, at most.

Also things may be a bit over-complicated in the discussion so far. It is important to tell people why the "Major New Feature" (Block editor) doesn't work on their site: because they have installed a plugin to disable it. Best place for this is right on the post-install (What's New) screen. The same place would be great to notify the users that the Gutenberg plugin has been deactivated, and offer to reactivate it.

IMHO showing additional admin notices seems excessive. Generally users that have installed Classic Editor -know- that they have installed it :) If we keep telling them, it would be super annoying. Also keep in mind that the admin notices are sometimes (often?) overused by plugins. It's not unusual to see several of them popping up everywhere after an upgrade. That, of course, has the exact opposite effect, most users just ignore them.

The tl;dr:

1. The post-install (What's New) screen is the best place to warn the users if the Classic Editor plugin is preventing use of the Block editor, or if Gutenberg was deactivated.
2. Any such warnings should be in core as they will be translated.
3. Admin notices and/or additional tabs will probably be a lot less effective. The same is true for Screen Options or the Help tab. Unfortunately these are used by a very small percentage of users.

Also, I may be missing something but the "Welcome to WordPress x.x" dashboard widget (the one with the huge "Customize..." button) shows only on new installs? Then, there will be no Gutenberg or Classic Editor plugins there.

[mrwweb]

I'm coming to this late, so my apologies for restating anyone's earlier ideas or unintentionally reopening discussions.

Replying to azaozz:

Generally users that have installed Classic Editor -know- that they have installed it :)

I would add to that: "...or someone else installed it for them for a specific reason."

I wonder if some slightly more explanatory language that relies a little less on understanding the plugin name might work better for users with the Classic Editor installed. Here's a first attempt that isn't quite right but heads in the direction I'm thinking:

"You are currently using the WordPress legacy content editor because the Classic Editor plugin is activated. Try out the new editor and have your site administrator deactivate the plugin when you're ready for the new experience."

I also think that text might go really nicely in the "Try the New Editor" section of the Welcome dashboard widget.

Finally, should there be any attempt to add or suppress messaging for other Gutenberg disabling plugins (especially ​Ramp) or simply detecting if add_filter('use_block_editor_for_post', '__return_false'); is set? Especially in that last case, it becomes a pretty darn good assumption that either the person knows what they're doing or doesn't know how to change it even if they know what's happening [and might be better off not knowing?].

[mcsf]

45073.2.patch is the minimum set of changes to let users who previously were using the Gutenberg plugin that they can reactivate it. I completely realise that this doesn't follow Joshua's visuals centred around a new What's Next? tab; my goal was to align with the recent Classic-Editor-related additions to the About page and just use the same spot for messaging. If someone has bandwidth to implement differently, they can grab this, but otherwise we're working with a very tight schedule due to 5.0 RC1.

Per the discussion in this ticket, any messaging encouraging users of Classic Editor to try Gutenberg should be implemented in Classic Editor itself.

I chatted with @azaozz on the technical aspects of this patch, and the idea is to leave the new upgrade_500_was_gutenberg_active option set until the 5.1 cycle, most likely, at which time we'll delete the option in a new upgrade_xyz() routine.

[lonelyvegan]

Replying to mcsf:

45073.2.patch is the minimum set of changes to let users who previously were using the Gutenberg plugin that they can reactivate it.

The patch as-is makes sense to me; approved 👍🏻

[azaozz]

45073.2.patch looks good here too.

[mcsf]

In 43921:

Warn users of Gutenberg plugin of its deactivation upon 5.0 upgrade.

Fixes #45073.

[mcsf]

In the interest of keeping things unblocked in 5.0, I've committed r43921.

Thank you, everyone, for the thorough discussion that made pushing this change so easy, and especially @JoshuaWold for the fast iteration on the flows.

I'm not sure what kind of room we have in 5.0 to iterate on this, but at least we still have the work in Classic Editor ahead of us.

[JoshuaWold]

Thank you @mcsf for the followup! Totally understand the point of running out of time.

1. Could you/someone else share screenshots of what it looks like now? Thanks!
2. If anyone has dev time to push further changes, when is the deadline to do so?
3. If not, should I still continue with design suggestions per the last Slack discussion?

Here's the items I was planning to look at:

• Highlight classic editor in path #1
• Classic editor included in Core, so adjust everything accordingly.
• Figure out a way to make "what's new" more bold, ​https://wordpress.slack.com/archives/C02RQBWTW/p1542230006325300
• Review last comment from @azaozz to see if I missed anything

[azaozz]

Replying to JoshuaWold:

Yeah, I'm still a bit "uneasy" about showing the "Learn how to keep using the old editor." message at the top. We have a big section about it at the bottom. If we keep it, we will also need to update this a bit to not show it when the Classic Editor plugin is activated, there is no way to do that from the plugin.

Last screenshot is what can be done from the Classic Editor plugin as a notice. It will show regardless of the message about Gutenberg being deactivated. Also, as I mentioned before it won't be translated in most languages but that may be acceptable at this point.

when is the deadline to do so

Ideally we should be done with all strings (text) before RC. Then they get "frozen" so translators have a bit of headstart. We still can tweak a bit the HTML, styling, etc. after.

Classic editor included in Core, so adjust everything accordingly.

That wouldn't make big difference imho. If it is distributed in the update, the users would still need to activate it, if it's not, they will need to install it. Both actions are pretty similar and easily performed.

[desrosj]

@mcsf @JoshuaWold @azaozz is this something we should continue to refine for 5.0.x? Or can it be closed out?

[JoshuaWold]

There's still value in this flow, and the time and energy that the whole team put into it. It has the potential to address users that could be confused by the update process.

With that said, we'd need development support in order to make this happen for the next update. I don't have a great sense of priorities for the next 5.0X version, so I'm unsure where this would fit.

My gut sense is we should probably go ahead and close this and move on. Thanks so much everyone for help on this!

[mcsf]

I'll echo Joshua's comment: let's preserve the knowledge gathered in this ticket, but also move on.

[karmatosed]

Closing as this seems to have reached an agreement to move on.