Add a mu-plugin loader that loads a specific version of a plugin if required.

[dd32]

Certain plugins on WordPress.org require specific versions of other plugins in order to operate.

One of these plugins is Blocks Everywhere, the current version of which requires Gutenberg 16.8.

We however use Gutenberg widely on other sites, and often want to use features from the recent versions.

This mu-plugin let's us load blocks-everywhere with Gutenberg 16.8, but use Gutenberg trunk/stable on other sites.

(edit: Obviously, this needs to be combined with an additional svn:external to have the plugin available)

[adamwoodnz]

I tried running this in my sandbox and it works as described for the support forums. Unfortunately I run into the HTML API out of memory issues with the later version of Gutenberg on the rest of wporg. Any version 16.9.x on causes it.

[pkevan]

Guessing I might have done something wrong in testing this, but it broke the support forums and deactivated the Gutenberg - i manually reactivated it to fix it.

What I did:

• copy the changes from this PR
• load the v16.8.0 version of Gutenberg through SVN external creating an additional copy of Gutenberg gutenberg-16.8
• update the standard Gutenberg plugin external to 17.5.1
• visit the forum site (front and back-end)

Unsure if the breakage was due to my method, or the way we attempt to override the sites' option values, as switching to non-sandbox mode didn't fix it.

Error:

Uncaught Error: Class 'WP_Theme_JSON_Data_Gutenberg' not found in /wp-content/plugins/blocks-everywhere/classes/class-editor.php:33

- attached to priority 10: Automattic\Blocks_Everywhere\Editor->wp_theme_json_data_theme

[ryelle]

I pushed a few commits to fix some things I noticed:

• array_splice runs over $plugins by reference, so we should return $plugins, not the array_splice result
• In my testing, I had Gutenberg in both locally active and network active lists, so I split those into two checks

To test, I added a new folder gutenberg-16.8 on my sandbox, updated the main gutenberg to 17.5.2, and tried to load the Support Forums. The forum editor worked. I also tried loading other wporg sites, and looking at wp-admin. Other sites load Gutenberg 17.5.2, and the Support Forums load 16.8.1.

I assume there should be no effects on the WordCamp network, even though it won't have a gutenberg-16.8 folder, because it does not use Blocks Everywhere.

[ryelle]

I tried running this in my sandbox and it works as described for the support forums. Unfortunately I run into the HTML API out of memory issues with the later version of Gutenberg on the rest of wporg. Any version 16.9.x on causes it.

@adamwoodnz I don't think I've ever run into this, but you've had memory issues with your sandbox before, right?

[adamwoodnz]

I tried running this in my sandbox and it works as described for the support forums. Unfortunately I run into the HTML API out of memory issues with the later version of Gutenberg on the rest of wporg. Any version 16.9.x on causes it.

@adamwoodnz I don't think I've ever run into this, but you've had memory issues with your sandbox before, right?

That's true, but this is different. This was a production issue for some sites on the day of that slack post, and reproduced by others. If it's not an issue for anyone else now then I'll investigate further once shipped.

[dd32]

• array_splice runs over $plugins by reference, so we should return $plugins, not the array_splice result
• In my testing, I had Gutenberg in both locally active and network active lists, so I split those into two checks

'doh! yeah array_splice() wasn't properly tested there for sure.. oops.

I hadn't considered it might be site-activated in network-activated contexts, but yeah it makes sense to do it like that.

I assume there should be no effects on the WordCamp network, even though it won't have a gutenberg-16.8 folder, because it does not use Blocks Everywhere.

That was the intention I had - That it would only kick in if the "problem" plugin existed, and that we'd have the environment setup for the plugin elsewhere. Realistically; having a non-existent plugin in the array isn't a problem, it would just mean the plugin isn't loaded at all.

Thanks @ryelle!

[dd32]

A thought I had over the weekend:
This should probably return early on wp-admin/plugins.php, or the option filters should cease functioning once plugins_loaded has fired.

That would avoid future people attempting to "switch to the newer version of gutenberg" via wp-admin/plugins.

[ryelle]

Looks like we'll want this for the pattern directory, pattern-creator/pattern-creator.php, it has the same issue as Blocks Everywhere (using private APIs).

[dd32]

I tried running this in my sandbox and it works as described for the support forums. Unfortunately I run into the HTML API out of memory issues with the later version of Gutenberg on the rest of wporg. Any version 16.9.x on causes it.

I've run into this as well, only on block theme sites though (ie. wordpress.org/showcase or https://developer.wordpress.org/, but not w.org/plugins) with GB 16.9~17.2. 17.3 appears to be the first version that works without running into memory exhaustion.

I'm guessing that's either a fixed bug, or an incompatibility between WordPress trunk and those versions of Gutenberg.

I'm going to merge this, I was going to bump the main deployed gutenberg to 17.1 as well since the interactivity changes were after that, but I'll hold off on that bump due to the above memory issues.

The Interactivity PRs can then be merged, the main Gutenberg version increased, and both deployed at once.