Skip to content
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

Closed
wants to merge 1 commit into from

Conversation

ramonjd
Copy link
Member

@ramonjd ramonjd commented Jul 4, 2023

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 :)

@ramonjd ramonjd self-assigned this Jul 4, 2023
@ramonjd ramonjd requested a review from ajitbohra as a code owner July 4, 2023 07:44
@ramonjd ramonjd added the [Type] Task Issues or PRs that have been broken down into an individual action to take label Jul 4, 2023
@github-actions
Copy link

github-actions bot commented Jul 4, 2023

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:

*
* @return array Filtered block type metadata.
*/
function gutenberg_block_core_navigation_update_interactive_view_script( $metadata ) {
Copy link
Contributor

@ntsekouras ntsekouras Jul 4, 2023

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.

Copy link
Member Author

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.

Copy link
Member Author

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.

Copy link
Contributor

@ntsekouras ntsekouras Jul 4, 2023

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.

Copy link
Member Author

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.

Copy link
Contributor

@ntsekouras ntsekouras Jul 4, 2023

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

Copy link
Contributor

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.

Copy link
Member Author

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.

Copy link
Member Author

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

@ramonjd ramonjd added [Type] Plugin Interoperability Incompatibilities between a specific plugin and the block editor. Close with workaround notes. and removed [Type] Task Issues or PRs that have been broken down into an individual action to take labels Jul 4, 2023
@ramonjd
Copy link
Member Author

ramonjd commented Jul 5, 2023

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

@ramonjd ramonjd closed this Jul 5, 2023
@ramonjd ramonjd deleted the remove/is-gutenberg-plugin-from-6-3 branch July 5, 2023 02:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Type] Plugin Interoperability Incompatibilities between a specific plugin and the block editor. Close with workaround notes.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants