-
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
Implement pattern overrides behind IS_GUTENBERG_PLUGIN
flag
#59702
Conversation
This pull request has changed or added PHP files. Please confirm whether these changes need to be synced to WordPress Core, and therefore featured in the next release of WordPress. If so, it is recommended to create a new Trac ticket and submit a pull request to the WordPress Core Github repository soon after this pull request is merged. If you're unsure, you can always ask for help in the #core-editor channel in WordPress Slack. Thank you! ❤️ View changed files❔ lib/load.php ❔ lib/compat/wordpress-6.6/block-bindings/pattern-overrides.php |
Size Change: +124 B (0%) Total Size: 1.71 MB
ℹ️ View Unchanged
|
@@ -284,6 +286,9 @@ export default function ReusableBlockEdit( { | |||
onNavigateToEntityRecord: | |||
getSettings().onNavigateToEntityRecord, | |||
editingMode: _getBlockEditingMode( patternClientId ), | |||
hasPatternOverridesSource: !! getBlockBindingsSource( |
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 wonder why you chose to use the selector over process.env.IS_GUTENBERG_PLUGIN
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, I was in two minds about it.
My thinking is that this could be maintained to work like this even after the process.env.IS_GUTENBERG_PLUGIN
code is removed, as a potential unregisterBindingSource( 'core/pattern-overrides' )
call could result in the same thing.
Actually, I don't think this approach is a good idea, as a WP 6.5 user could re-register pattern overrides, so I think we'll need to add process.env.IS_GUTENBERG_PLUGIN
everywhere.
edit: The register
action is private at the moment, so maybe this solution is ok. I don't mind implementing it either way though.
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.
The register action is private at the moment, so maybe this solution is ok.
Given that it's still possible, shall we just put behind the flag?
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.
@getdave It's not possible for third-parties, so it doesn't impact.
Personally, I don't mind either way.
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.
Oh I thought a third party could opt into Private APIs it's just they have to jump through a lot of hoops to do so.
Personally, I don't mind either way.
Good enough for me. @talldan can make a call.
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 tested this by applying the following patch to simulate not being in the Gutenberg Plugin:
Disable Gutenberg Patch
diff --git a/lib/load.php b/lib/load.php
index dc3a6533a5..7d62ce342a 100644
--- a/lib/load.php
+++ b/lib/load.php
@@ -9,7 +9,7 @@ if ( ! defined( 'ABSPATH' ) ) {
die( 'Silence is golden.' );
}
-define( 'IS_GUTENBERG_PLUGIN', true );
+define( 'IS_GUTENBERG_PLUGIN', false );
require_once __DIR__ . '/init.php';
require_once __DIR__ . '/upgrade.php';
diff --git a/tools/webpack/shared.js b/tools/webpack/shared.js
index debd3fc93f..fc348dc7b7 100644
--- a/tools/webpack/shared.js
+++ b/tools/webpack/shared.js
@@ -64,8 +64,7 @@ const plugins = [
process.env.WP_BUNDLE_ANALYZER && new BundleAnalyzerPlugin(),
new DefinePlugin( {
// Inject the `IS_GUTENBERG_PLUGIN` global, used for feature flagging.
- 'process.env.IS_GUTENBERG_PLUGIN':
- process.env.npm_package_config_IS_GUTENBERG_PLUGIN,
+ 'process.env.IS_GUTENBERG_PLUGIN': false,
// Inject the `IS_WORDPRESS_CORE` global, used for feature flagging.
'process.env.IS_WORDPRESS_CORE':
process.env.npm_package_config_IS_WORDPRESS_CORE,
I saw that the overrides feature was completely disabled in the UI.
I also tried registering some overrides whilst in the Gutenberg Plugin and then switching back to the "Disabled Gutenberg Plugin" environment and I didn't see anything persisted. All the bindings in the source appeared to have been removed as well.
If there's anything else I could test such as APIs that were previously exposed that would be useful to know. Otherwise this appears to be looking good.
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.
To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
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.
Let's ship this to include in RC1.
Co-authored-by: talldan <[email protected]> Co-authored-by: youknowriad <[email protected]> Co-authored-by: getdave <[email protected]>
I just cherry-picked this PR to the pick/wp-65-rc-2 branch to get it included in the next release: dee8699 |
Co-authored-by: talldan <[email protected]> Co-authored-by: youknowriad <[email protected]> Co-authored-by: getdave <[email protected]>
…ess#59702) Co-authored-by: talldan <[email protected]> Co-authored-by: youknowriad <[email protected]> Co-authored-by: getdave <[email protected]>
What?
See #53705 (comment).
Puts the pattern overrides feature behind the
IS_GUTENBERG_PLUGIN
flag to prevent it shipping to core.How?
I've taken the approach of using
IS_GUTENBERG_PLUGIN
where thecore/pattern-overrides
block bindings source is registered.In other places in the codebase, we check for the existence of that
core/pattern-overrides
block binding source to disable the feature.Testing Instructions
This needs some thorough testing to ensure all traces of pattern overrides are no longer present.
To replicate
IS_GUTENBERG_PLUGIN
beingfalse
you can do the following:webpack/shared.js
file, changing this line to'process.env.IS_GUTENBERG_PLUGIN': false
. You can usually also modify this in the project package.json itself, but for me this caused a build failure.gutenberg/tools/webpack/shared.js
Lines 67 to 68 in ed7edbc
lib/load.php
file, changing this line todefine( 'IS_GUTENBERG_PLUGIN', false );
:gutenberg/lib/load.php
Line 12 in ed7edbc
Then finally rebuild.