WP 6.3: remove IS_GUTENBERG_PLUGIN from PHP files

[ramonjd]

Resolves #52103

What?

This PR removes IS_GUTENBERG_PLUGIN blocks from PHP files in the wp/6.3 branch only.

This is mostly the interactivity API.

Why?

So that there is no plugin-specific code in Core.

How?

Deleting stuff.

Testing Instructions

Check that the file and navigation blocks still render correctly on the frontend. Make sure to verify all attributes/classes/styles please :)

[github-actions]

Flaky tests detected in 57b72e5.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/5452119048
📝 Reported issues:

• [Flaky Test] allows rotating using the crop tools #36904 in /test/e2e/specs/editor/blocks/image.spec.js

[ntsekouras]

I think we can rename to loose the gutenberg prefix, but I don't think we should remove the above navigation block code. --cc @scruffian @draganescu

Since they are wrapped in IS_GUTENBERG_PLUGIN they are not part of the build in WP core, right? They are handled by Webpack.

[ramonjd]

I'm not sure they are removed in PHP: https://github.com/WordPress/wordpress-develop/blob/1815f4c76c9f51665f046d79284552d09849597b/src/wp-includes/blocks/file.php#L8

In JS, yes.

I just threw this PR up as a "just in case". We could easily rename the functions too, but keep them in a wrapper.

[ramonjd]

I'm not sure they are removed in PHP

Sorry, that link was to an unbuilt file. I just checked my build folder locally and can still see the IS_GUTENBERG_PLUGIN blocks.

[ntsekouras]

Yeah, the code is there, but not used in core. My wording above was ambiguous, sorry. Check my comment in the issue.

The blocks code is built automatically in WP core folder structure. There are some features/code that needs to be part of the php blocks' code, but we don't want it to be part of WP core.

So we should remove the code only if the code is not used/needed anymore.

[ramonjd]

So we should remove the code only if the code is not used/needed anymore.

Ah, okay. No worries. Just to confirm, the code is needed in the plugin but not in Core. The interactivity API will not be backported to WP 6.3.

So better to rename the functions? It's not quite the same as in #51989, which only renamed to an existing core function that had been around for a while. Here we are potentially introducing two new, currently experimental, functions, albeit guarded by the IS_GUTENBERG_PLUGIN checks.

As long as we are sure this is a good approach, then I can rejig this PR.

[ntsekouras]

It's not quite the same as in #51989,

That's a different use case. Since the code in blocks.php files are copied for core, we can't have functions that only exist in GB. Additionally, if blocks call some core functions(like the above PR) and we want to override in GB, we have the Webpack mechanism to add the gutenberg prefix to these specific functions.

I'll -cc @Mamaduka too

[tellthemachines]

I think renaming the functions in trunk is the more future-proof approach. If all goes well, at some point the logic will make it into core and they'll have to be renamed all the same, so we might as well do it straightaway. In any case, given the block PHP files are auto-generated in core, it's good practice to never use gutenberg prefixes in them. If we need the functions to be namespaced for development reasons, we can use the webpack task to add the prefix at build time.

I also don't love the idea of introducing changes directly to the release branch, as it can cause conflicts if we later need to make changes to the files. This branch will still be used for minor releases after 6.3.0 is out.

[ramonjd]

Thanks for the feedback folks. I'll update this PR and change the base branch to trunk.

[ramonjd]

Actually, I'll create a new branch. This one has a name that might confuse: remove/is-gutenberg-plugin-from-6-3

[ramonjd]

I think renaming the functions in trunk is the more future-proof approach. If all goes well, at some point the logic will make it into core and they'll have to be renamed all the same, so we might as well do it straightaway. In any case, given the block PHP files are auto-generated in core, it's good practice to never use gutenberg prefixes in them. If we need the functions to be namespaced for development reasons, we can use the webpack task to add the prefix at build time.

These have been removed in Gutenberg trunk in 9b8d5c1#diff-adf84f1d0ae56974f4c9f23d5d07d3e1fe9f3bda38d4bd2d8ba13ba41d9f0e70 already