[wp-trac] [WordPress Trac] #59720: Long-term plan for handling Gutenberg version compatibility with core

[WordPress Trac]

#59720: Long-term plan for handling Gutenberg version compatibility with core
-----------------------------+-----------------------------
 Reporter:  iCaleb           |      Owner:  (none)
     Type:  enhancement      |     Status:  new
 Priority:  normal           |  Milestone:  Awaiting Review
Component:  Upgrade/Install  |    Version:  trunk
 Severity:  normal           |   Keywords:
  Focuses:                   |
-----------------------------+-----------------------------
 There's now a fairly common precedent that new major WP releases are often
 incompatible with many prior versions of Gutenberg. This makes sense,
 given that more and more we're going to see GB tie into the WordPress core
 experience. However there are some problems with how this version
 dependency / relationship is currently treated.

 In #59718 this is explained some. But to briefly re-iterate:

 1) Currently, when a traditional WP upgrade is triggered and files are
 being replaced, core will also decide if it should deactivate the
 Gutenberg plugin based on the plugin version, [seen
 here](https://github.com/WordPress/wordpress-
 develop/blob/32f75bf0f4c9adeaa51277f979490a53bea07e4f/src/wp-
 admin/includes/update-core.php#L1842-L1868).

 2) This brings about some issues. Two in particular come to mind:
  - If the Gutenberg plugin is not db-activated, but rather code activated,
 it will not be deactivated and the WP upgrade will cause the site to fatal
 error. An example of this is if GB is being loaded as an MU Plugin.
 - Even if the GB plugin is db-activated, it's fairly common for
 applications to be managed via version control. Meaning the
 `_upgrade_core_deactivate_incompatible_plugins` routine isn't actually
 being called. So the newly updated core files are essentially instantly
 present on an application that never got the chance to deactivate the
 older version of GB.

 So I wanted to open up this ticket for some discussion on how we could
 make this better, and perhaps prioritize for the next major release so we
 can stop risking fatal errors due to this during WP upgrades :)

 ----

 Ideas:

 The first thing that came to mind is how the Action Scheduler
 plugin/library works. Many different plugins can load in this library, or
 it can be added as a standalone plugin. Each instance will register
 itself, but then it will only initialize one version ([the
 latest](https://github.com/woocommerce/action-scheduler/blob/trunk/action-
 scheduler.php#L36)). This helps prevent duplicate class/function name
 fatal errors, and makes the loading process safe and easy.

 Gutenberg is perhaps an even simpler use case, in that there's just two
 pieces - there is the standalone plugin and there is core. And rather
 conveniently, core is able to intercede early on in the process and
 register some loading rules before any plugins get a chance to load in.

 A quick code example could be something like this inside the GB plugin:

 {{{#!php
 <?php

 //
 https://github.com/WordPress/gutenberg/blob/187224a67b839ace8e9c42b85f351fda996a2361/gutenberg.php#L72
 function gutenberg_pre_init() {
         global $wp_core_minimum_allowed_gutenberg_version;
         $current_gutenberg_version = '16.4';

         if ( version_compare( $current_gutenberg_version,
 $wp_core_minimum_allowed_gutenberg_version, '<' ) ) {
                 // Add some UI messaging to explain that the plugin isn't
 truly being loaded.
                 return;
         }

         // Load the plugin.
         require_once __DIR__ . '/lib/load.php';
 }
 }}}

 In this example, WP core would be responsible for declaring
 `$wp_core_minimum_allowed_gutenberg_version`. This will help ensure that
 the conflicts between older versions of GB and WP core can truly be
 avoided.

 Notably, it'll be important to think this through and make sure we give
 core all the controls it will need to influence the loading of the GB
 plugin. It's not really enough to rely on every GB plugin version to set
 these things and know it's future compatibility status.

 I was recently was pointed towards this PR which looks like a great start:
 https://github.com/WordPress/gutenberg/pull/35194. Although I would
 probably opt towards leaving something like `GUTENBERG_MAX_WP_VERSION` to
 always be defined by WP core since that is where we'll have the best
 context and the ability to alter it before a release.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/59720>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform