[wp-trac] [WordPress Trac] #41316: Introduce "Try Gutenberg" callout

Thu Jul 26 05:12:40 UTC 2018

#41316: Introduce "Try Gutenberg" callout
-------------------------------------+-------------------------------------
 Reporter:  melchoyce                |       Owner:  pento
     Type:  task (blessed)           |      Status:  reopened
 Priority:  normal                   |   Milestone:  4.9.8
Component:  Editor                   |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch has-           |     Focuses:  administration,
  screenshots                        |  privacy
-------------------------------------+-------------------------------------

Comment (by pento):

 Thanks for the comments, y'all! 🙂

 > Why is the callout even shown to users without the necessary
 capabilities in the first place?

 @SergeyBiryukov linked to where the button behaviour based on capabilities
 was discussed, but for the larger question of why we're showing the
 callout to everyone, it's because Gutenberg affects everyone, even if they
 don't have the capability to install the plugin. Site users should be
 aware that this change is coming.

 On top of that, for many sites, the people who use the site on a daily
 basis won't necessarily be site admins, so won't have the capability to
 install the plugins: they need to be aware of Gutenberg, so they can speak
 to their site admin about it.

 That said, it'd be nice to have somewhere to direct folks who can't
 install the plugin, or use the block editor locally.
 https://wordpress.org/gutenberg/ is
 [https://make.wordpress.org/meta/2018/07/12/revised-gutenberg-landing-
 page/ currently being revised], and a feature that will hopefully be
 implemented is to add [https://frontenberg.tomjn.com/ Frontenberg] to it,
 so visitors can try out Gutenberg right there. If that makes it before
 4.9.8, the "Try Gutenberg" button could link to
 https://wordpress.org/gutenberg/ for everyone who currently doesn't see a
 button. This is easy to add at the last minute, once the meta team are
 certain they can have it ready in time.

 > Having "Learn more about Gutenberg" immediately followed by "Learn more
 about Gutenberg on <host>" is a bit confusing. Rather than an action, it
 would be much preferred that the entire link (the output of the printf) be
 filterable instead.

 Good suggestion, thanks @andrew.taylor! [attachment:"41316.22.diff"]
 removes the `try_gutenberg_after_install_button` action, and replaces it
 with a `try_gutenberg_learn_more_link` filter, which can be used like so:

 {{{#!php
 <?php
 add_filter( 'try_gutenberg_learn_more_link', function( $learnmore ) {
         return '<a href="https://support.my.host/gutenberg">Learn more
 about Gutenberg on My Host</a>';
 } );
 }}}

 > I'm a bit concerned that, as far as I can tell, there isn't a way for
 WordPress.org to remotely toggle this metabox.

 That's correct, it isn't possible to remotely toggle it, I don't believe
 that adding such a flag wouldn't really give us any practical benefit. The
 flag would have to be provided by the w.org update API, which sites check
 every 12 hours. If there were some dire emergency, we would be able to
 push out a 4.9.9 release with the meta box hidden, and because of the lag
 time in sites checking the API, it would have approximately the same rate
 of uptake as an API flag would. (We would presumably drop the update check
 TTL as soon as we decided to push out 4.9.9, so all sites would be updated
 in 12 hours from that point, the only practical difference would be the
 earliest set of sites to check the API would hide the meta box a little
 later.)

 While the option exists to push out a rapid 4.9.9 release, I would be
 extremely reticent to use it. I expect that there will be sites that
 Gutenberg doesn't really work for, yet, but the proper response to that is
 not to panic and shutdown the callout, it's to ensure that the site user
 can easily keep using Classic, so we can focus on fixing the problem in
 Gutenberg. There are several levels of opting in to Gutenberg here:
 install the plugin, activate the plugin, and then for every post that you
 edit, choose the "Edit" button instead of the "Classic Editor" button.
 People can very easily back out of using Gutenberg at any time.

 It's also worth remembering that the Gutenberg plugin is currently
 installed on over 20,000 sites, it's organically growing by more than 1000
 installs per week, and that rate is accelerating. There will be
 incompatibilities with unusual site configurations, of course, but it's
 reasonable to assume that, given Gutenberg's existing install base, a
 catastrophic incompatibility would likely have been reported already. (I
 do realise how much I'm tempting fate by stating this aloud! 😉)

 In order to leave the option of a rapid 4.9.9 release open, however, I
 think it's reasonable for us to have a 48 hour code freeze on the 4.9
 branch after the release of 4.9.8. This will ensure it's in a clean state
 for us to get a 4.9.9 release out as quickly as possible.

 > That said, "Install the Classic Editor" button might be hidden for users
 who cannot install plugins, but the text still says "Install the Classic
 Editor plugin to keep using the current editor until you’re ready to make
 the switch" regardless of the capabilities, which doesn't make much sense.

 "Install the Classic Editor" doesn't necessarily mean "click the install
 button below to install it now". It can mean "speak to your site admin,
 discuss your migration plan, and decided whether the Classic Editor plugin
 is the correction option for your site". 🙂 It's impossible for us to
 specify the exact steps every site user should take to respond to the
 callout, but we're providing a combination of immediately actionable
 buttons to click, information about the two options available, and links
 to read more, that should inform folks to the point that they can take the
 right next step for their site.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/41316#comment:172>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform