Include Cart and Checkout Blocks when included in WC Core #6805
Conversation
The release ZIP for this PR is accessible via:
|
// This code is being kept in case we add a feature-plugin-only block in future. It will be easy to reinstate. | ||
// /** | ||
// * Registers a new feature plugin block provided a unique name and an object | ||
// * defining its behavior. Once registered, the block is made available as an | ||
// * option to any editor interface where blocks are implemented. | ||
// */ | ||
// export const registerFeaturePluginBlockType = ( | ||
// blockNameOrMetadata: string | BlockConfiguration, | ||
// settings: Record< string, unknown > | ||
// ): Block | undefined => { | ||
// if ( WC_BLOCKS_PHASE > 1 ) { | ||
// return registerBlockType( blockNameOrMetadata, settings ); | ||
// } | ||
// }; |
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.
Are you commenting this out because it's not used 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.
Yes, I chose to do this instead of deletion because it will be easier to reinstate this if required in future. Easier than finding the PR that removed it I mean.
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 on the camp of leaving it intact. It will get treeshaken id not used so it’s not hurting anyone, better than someone using it out of memory just so it doesn’t work for them because it’s commented out. X is undefined are hard to track sometimes.
// phpcs:disable Squiz.PHP.CommentedOutCode | ||
// phpcs:disable Squiz.Commenting.InlineComment.InvalidEndChar | ||
// phpcs:disable Squiz.Commenting.InlineComment.SpacingBefore | ||
// public function is_feature_plugin_build() { | ||
// return $this->feature()->is_feature_plugin_build(); | ||
// } | ||
// phpcs:enable Squiz.PHP.CommentedOutCode | ||
// phpcs:enable Squiz.Commenting.InlineComment.InvalidEndChar | ||
// phpcs:enable Squiz.Commenting.InlineComment.SpacingBefore |
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.
Any reason we're commenting out those functions?
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.
They aren't used and it seems reasonable to keep it around in case we add new blocks in future that should be behind this feature flag. It would be easier to reinstate by uncommenting this than looking for the PR that removed it and re-adding it that way (I think).
Though I do see a bunch in FeatureGating.php
that aren't used and also not commented out. Should we keep it around uncommented?
Size Change: -246 B (0%) Total Size: 871 kB
ℹ️ View Unchanged
|
Script Dependencies ReportThere is no changed script dependency between this branch and trunk. This comment was automatically generated by the |
We might need this later, so keeping it around seems useful.
This reverts commit bec6ed8.
ce78586
to
8309382
Compare
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.
For me this works as expected. Thank you for your work! 👏
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.
Thank you for working on this, @opr! It works perfect. 👍
This PR will graduate the Cart and Checkout Blocks so they are available even when WooCommerce Blocks is not running as a feature plugin (i.e. it is included in WooCommerce Core).
To achieve this, I ensured both blocks, and their inner blocks were registered using
registerBlockType
rather thanregisterFeaturePluginBlockType
-registerFeaturePluginBlockType
has been commented out, but left in thefeature-flags.ts
file so it can easily be reinstated in future if we ever add a feature-plugin-only block.I then found all instances in PHP where classes were only registered if WooCommerce Blocks was running as a feature plugin (Payments Api was the only place).
There was also an inbox notification added in #4518 to surface these blocks to a certain subset of users, however this message is defunct. I removed the code to add this notification, but left the code to delete it. This should ensure any sites that still have this message have it removed.
Fixes #6699
Other Checks
Testing
Automated Tests
User Facing Testing
npm run build
.blocks.ini
with the following config:Cart
Checkout
Allow customers to create an account during checkout
andAllow customers to log into an existing account during checkout
.create account
box when entering your details.SW19 1AA
if in UK).Manual testing for Rubik only
After trying all the steps above, please:
plugins
directory, run:npx @wordpress/create-block -t @woocommerce/extend-cart-checkout-block checkout-integration
.Checkout Integration
plugin in your dashboard.+ extra data!
(this is from thecheckout integration
plugin).Denver
. Ensure the COD option disappears from available payment methods.Data passed to this component: This is some example data from the server
- this signifies Slot/Fill is working.WooCommerce Visibility
Changelog