"Proceed to Checkout" BUTTON in Cart URL option does not work

[lashawnie]

Describe the bug

Hello, I decided to try to use the WooCommerce Blocks for my Cart since it gives the Advance option to change the page to which the “Proceed to Checkout” BUTTON can be redirected to. However, after selecting the page I want the BUTTON to be redirected to – it still redirects to my Checkout page. How can this be fixed? Any help would be greatly appreciated!!! Thank you!

Screenshots

[opr]

Hi thank you for the report. I've investigated and it looks like it's being caused by the Cart Block's inner blocks' attributes not
being available to the PHP script that renders the blocks.

I wonder if we could change AbstractBlock so that render_callback includes $block as its third argument, which will subsequently be passed to enqueue_assets, then enqueue_data.

The Cart class's implementation of enqueue_data could include something like this at the end, instead of:

woocommerce-blocks/src/BlockTypes/Cart.php

Line 198 in 444b818

$this->asset_data_registry->register_page_id( isset( $attributes['checkoutPageId'] ) ? $attributes['checkoutPageId'] : 0 );

we could do:

if ( $block->inner_blocks instanceof \WP_Block_List ) {
			// Find the `woocommerce/proceed-to-checkout-block` and enqueue the checkoutPageId from it.
			$filled_cart_block = null;
			foreach ( $block->inner_blocks as $inner_block ) {
				if ( ! $filled_cart_block && 'woocommerce/filled-cart-block' === $inner_block->name ) {
					$filled_cart_block = $inner_block;
				}
			}

			// Now loop through all inner blocks, and their inner blocks until we find 'woocommerce/proceed-to-checkout-block'.
			foreach ( $filled_cart_block->inner_blocks as $inner_block ) {
				if ( $inner_block->inner_blocks instanceof \WP_Block_List ) {
					foreach ( $inner_block->inner_blocks as $inner_inner_block ) {
						if ( 'woocommerce/proceed-to-checkout-block' === $inner_inner_block->name ) {
							$attributes = $inner_inner_block->parsed_block['attrs'];
							$this->asset_data_registry->register_page_id( isset( $attributes['checkoutPageId'] ) ? $attributes['checkoutPageId'] : 0 );
						}
					}
				}
			}
		}

If we did this, we would need to edit all blocks extending AbstractBlock to have $block as their second argument.

This is an explicit approach to solving for the checkoutPageId attribute, but we should investigate if it can be generalised.

[lashawnie]

Thank you for looking into this matter!! Where would i put this coding at?

[opr]

Hi @lashawnie I am sorry for any confusion - the code I mentioned above is not something that will help you immediately, and I can't think of a workaround right now.

I posted this code to provide context for the other engineers on our team who might look into this!

[lashawnie]

@opr OH - ok! Thank you!

[senadir]

This used to work fine before Thomas so I'm not really sure we need such logic. How is this related to the PHP rendering logic? In the code, this is the JS part responsible for deciding the link.
Is the attribute not being passed to the frontend?

const link = getSetting( 'page-' + checkoutPageId, false );

[opr]

The attribute itself is being passed on the front-end, but the checkoutPageId attribute is not passed to enqueue_assets/enqueue_data which is where page-{ checkoutPageId } is registered. This is because it is not an attribute on woocommerce/cart.

In Cart.php - $attributes includes only the attributes on woocommerce/cart. The attribute is on an inner block (woocommerce/proceed-to-checkout-block).

I thought about getting all attributes and just bubbling them up to the top-level block, but this is not reliable, there could be multiple inner blocks with the same named attribute.

[senadir]

I see, thank you for taking time to explain this Thomas!

Some possible solutions:

• Create a class and register Cart/Checkout inner blocks, Kirigami did a similar thing as well.
• At php render time, when we try to render that inner block, we call register_page_id and render the link directly. Not sure if this is possible without the first one.
• Instead of saving a post id in the attribute, save the link, this might result in broken links.

[lashawnie]

If this ever gets resolved, can someone please let me know. Thank you - have a great day!

[opr]

@lashawnie if this gets resolved you should get a notification via email, you should ensure you have GitHub notifications turned on for this issue. Thanks again for reporting it to us!

[lashawnie]

OK @opr Thank you!