[wp-trac] [WordPress Trac] #59718: Short-term (WP 6.4) hotfix to prevent fatal error in standalone Gutenberg (<16.5)

[WordPress Trac]

#59718: Short-term (WP 6.4) hotfix to prevent fatal error in standalone Gutenberg
(<16.5)
-----------------------------+---------------------
 Reporter:  rebasaurus       |       Owner:  (none)
     Type:  defect (bug)     |      Status:  new
 Priority:  normal           |   Milestone:  6.4
Component:  Upgrade/Install  |     Version:
 Severity:  critical         |  Resolution:
 Keywords:                   |     Focuses:
-----------------------------+---------------------
Changes (by hellofromTonya):

 * milestone:  Awaiting Review => 6.4


Comment:

 Hello @rebasaurus,

 Welcome back to WordPress Core's Trac :)

 This ticket is the next step in a discussion that started in Make/Core
 `#6-4-release-leads` channel
 ([https://wordpress.slack.com/archives/C055Y7FKS7N/p1697743553695489 found
 it here]).

 == Context for plugin deactivation during Core upgrade

 `_upgrade_core_deactivate_incompatible_plugins()` was added in 5.8.0 to
 safeguard users when they upgrade to a newer version of WordPress Core.

 Why was it needed?
 Some older versions of the Gutenberg plugin shipped without enough
 protection to avoid loading the same named class(es) and/or function(s)
 that were (possibly later) merged into Core. It aligned to Core files
 should load by default. By deactivating the known older versions of the
 plugin, it avoids a naming collision fatal error. In other words, it seeks
 to maintain users' trust that it's safe to upgrade to the newest version
 of WordPress.

 Why is Gutenberg special? Why not enforce that it must fix its
 incompatibilities like all other plugins? Because Gutenberg is not just a
 plugin and its code is intended to land in Core. I think of as Core's R&D,
 an incubator for new ideas that, when ready for the masses, come to Core.
 Gutenberg and Core are intertwined.

 == What is the ask for 6.4?

 Is there a short-term way to possibly prevent the fatal errors for all
 ways WordPress Core itself gets upgraded? This includes those upgrade
 processes that do not use Core's `update_core()`.

 What was discussed in the slack thread and thus here in this ticket:

 1. Could Core not load its class files and/or functions that will be
 incompatible with different versions of Gutenberg that have the same named
 classes and/or functions?

 2. Is there a way to trigger
 `_upgrade_core_deactivate_incompatible_plugins()` as part of the upgrade
 processes not using Core's `update_core()`?

 3. Could the Gutenberg team fix the incompatibilities in each older
 version and then ship .x release for each? Note: These upgrade processes
 will first upgrade the plugin before upgrading WordPress Core.

 I'm bringing this ticket into 6.4 for discussion. That said, any changes
 in Core's source code must be minimal and with very high confidence given
 how late it is in the cycle.

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