-
Notifications
You must be signed in to change notification settings - Fork 219
Product Gallery Block > Remove global variable overwrite and keep support for the Single Product Block. #9458
base: trunk
Are you sure you want to change the base?
Product Gallery Block > Remove global variable overwrite and keep support for the Single Product Block. #9458
Conversation
…ock to continue to work within the Single Product template without any problems.
The release ZIP for this PR is accessible via:
Script Dependencies ReportThe
This comment was automatically generated by the TypeScript Errors Report
🎉 🎉 This PR does not introduce new TS errors. |
Size Change: 0 B Total Size: 1.08 MB ℹ️ View Unchanged
|
…le within the ProductImageGallery class for rendering the Product Image block.
ob_start(); | ||
echo sprintf( '<span class="onsale">%1$s</span>', esc_html__( 'Sale!', 'woo-gutenberg-products-block' ) ); | ||
return ob_get_clean(); |
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.
No need to use an output buffer here since you have control over the output. Just return it.
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.
If this is a copy of the classic template, it'd be better to pull in the template directly via Woo template functions. That way if the theme has any template override it'll use the override. It's also possible (but rare) that a plugin (or custom code) might be adding a template override.
I'd also want to avoid just copying template code into here (along with the filters) because it gives the impression this will be the long-term version of the block and we're committing to these filters long-term in this context. I'd prefer to leave room for potential iterations that might not/likely won't expose these filters.
return ''; | ||
} | ||
|
||
ob_start(); |
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.
Output buffer isn't needed here, just save the output from the loop to a variable and then return it.
$single_post = get_post( $post_id ); | ||
if ( ! $single_post instanceof \WP_Post ) { | ||
return ''; | ||
} |
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.
Posts with product
post_type will be an instance of WP_Post, why return? These conditionals seem unnecessary.
return ''; | ||
} | ||
|
||
$single_product = wc_get_product( $post_id ); |
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 single
prefix on the variable name is redundant. You can still use product
.
* | ||
* @return string | ||
*/ | ||
private function product_image( $product, $post ) { |
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.
$post
isn't used by the function.
* @param \WC_Product $product Product instance. | ||
* @param \WP_Post $post Post instance. | ||
*/ | ||
private function sale_flash( $product, $post ) { |
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.
$post
isn't used by the function.
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 realize this PR is still draft. I'd suggest just focus on fixing the global in this PR and the other changes can be made in a separate PR. Those changes are questionable in their current state and keeping in a separate PR can allow for the more pressing issue of the global overwrite to be dealt with sooner.
Sounds good! I'm cherry-picking the commit for the global variable change and opening a separate PR for that.
Yep! They are 100% questionable :D I did this in 20 minutes by quickly adapting the code of those 3 templates and consolidating them in our class as a proof of concept for the discussion kicked off on #9457: I didn't want to go into details here without gathering folks opinions first, in case someone had any serious concerns with us following this path. I'll be working on this and another separate PR for the Add to Cart with Options blocks so we can discuss what should be effectively ported over from core and what should be ditched. |
…ix/remove-call-to-global-variables-from-gallery-block
This PR has been marked as If deemed still relevant, the pr can be kept active by ensuring it's up to date with the main branch and removing the stale label. |
This PR has been marked as If deemed still relevant, the pr can be kept active by ensuring it's up to date with the main branch and removing the stale label. |
Ensure the
$product
global variable is not overwritten within theProduct Gallery
block while still keeping support for the (still experimental) Single Product block.Additionally, the following templates are also being incorporated to the
ProductImageGallery
class:single-product/product-thumbnails.php
single-product/product-image.php
single-product/sale-flash.php
Those are added as a viable alternative for allowing the render of the Product Gallery Block as an inner block for the Single Product Block. In other words, this change enables the usage of the Product Gallery Block outside of the scope of the Single Product template by not relying on the global
$product
variable, but on the context of the Single Product block instead.Fixes #9453
Testing
User Facing Testing
WooCommerce Visibility
Performance Impact
Changelog