-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WP 6.3: remove IS_GUTENBERG_PLUGIN from PHP files #52274
Conversation
Flaky tests detected in 57b72e5. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/5452119048
|
* | ||
* @return array Filtered block type metadata. | ||
*/ | ||
function gutenberg_block_core_navigation_update_interactive_view_script( $metadata ) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the feedback folks. I'll update this PR and change the base branch to trunk.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, I'll create a new branch. This one has a name that might confuse: remove/is-gutenberg-plugin-from-6-3
These have been removed in Gutenberg trunk in 9b8d5c1#diff-adf84f1d0ae56974f4c9f23d5d07d3e1fe9f3bda38d4bd2d8ba13ba41d9f0e70 already |
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 :)