Darren Ethier (nerrad)

Hey there! Thanks for taking the time to leave a review. I’m interested in learning more about the lack of value you received from the documentation and appreciate any insight you can give.

To be clear on what documentation you viewed, can you share with me the URL of what you referenced?

What were you hoping to find in the documentation that wasn’t there?

What were you hoping to accomplish with WooCommerce Blocks but were unable to?

Thanks!

Hi there. We definitely don’t intend this plugin as a joke and your experience is not what is being aimed for.

You mentioned:

I can’t understand yet what is the function of this plugin. There are no settings.

We take care to craft the plugin description to help explain what it does. Is there anything in the description that wasn’t clear or left you with questions? I’d be happy to help answer any you might have.

The only change I saw when turning it on was that it changed the style of my front page

That’s unfortunate! I can understand how that would make someone upset. If you have the time to answer a few questions that we might be able to use for troubleshooting that could hopefully help prevent future users from experiencing the same:

1. WooCommerce Blocks is intended to be used with WooCommerce. Is WooCommerce active on your site?
2. What theme are you using?
3. Will you share any details (before & after screenshots would be awesome!) about what specific styling changed on your front page. Was it styling for button elements? Were colors off or was it spacing? Did fonts change?
4. Are you using a page builder plugin? If so, which one?

Thanks for reporting, this is definitely not expected and I’ve created an issue: https://github.com/woocommerce/woocommerce-blocks/issues/7176

Hi there @nineplanetsllc – I did some troubleshooting of this and it looks like the Astra theme is capturing the onClick handler for the button. The relevant code is in their frontend.js theme:

button.onclick = function() {
			if ( -1 !== containerMenu.className.indexOf( 'toggled' ) ) {
				containerMenu.className = containerMenu.className.replace( ' toggled', '' );
				button.setAttribute( 'aria-expanded', 'false' );
				menu.setAttribute( 'aria-expanded', 'false' );
			} else {
				containerMenu.className += ' toggled';
				button.setAttribute( 'aria-expanded', 'true' );
				menu.setAttribute( 'aria-expanded', 'true' );
			}
		};

You could reach out to their support team and see if that’s something they could address.
The specific relevant code in WooCommerce Blocks has been the same for 3 years.
I hope that helps. Let us know how that goes!

		
	

Hi there!

Is there a timeline/estimate for when Blocks will stop being “experimental” and start working with WooCommerce’s own plugins (or when WooCommerce official plug-ins catch up and stop using webhooks for everything)? Or are there plans to update the regular checkout flow to be more user-friendly and current?

You may be interested in this recent post which includes some info around the plans for the new checkout flow provided by blocks.

Hi there Johan, while from your post you have indicated that you noticed this happen as a result of updating the Gutenberg plugin, I’m not sure how there would be a causal relationship here. The fields you referenced are user-editable fields that are saved to the database and Gutenberg doesn’t have any integrations with WooCommerce that would impact that particular field.

If you continue to see issues you may want to post in the WooCommerce support forums about this.

Hi @fedux

It does sound like what you are experiencing is related to this issue that is already known. We have a fix for that issue that is almost ready to go and should surface in the next release of WooCommerce blocks.

For some background on why this bug surfaced, we did some recent changes to improve the performance of some of the WooCommerce blocks on the frontend by lazy loading certain assets. An unfortunate side-effect, is that by default, WordPress doesn’t support automatically loading translations for these lazy loaded “chunks” so that lead to issues similar to what you’re reporting where the translations for strings are available, but not loaded. The prepared fix will take care of that by automatically handling lazy loading translated strings along with the other assets as needed.

To be clear though, while this will fix issues with translations coming from WordPress.org, we’re uncertain at this time whether it will also fix issues with plugins like Loco Translate that allow for on demand user customization of translated strings. Unfortunately that’s not something that we would be able to fix on our end if that’s the case, those plugins might need to add explicit support for lazily loaded translated strings.

Also, this issue isn’t necessarily WooCommerce Blocks specific. This is one of the first plugins in the WordPress.org repository experimenting with improving performance on the frontend by lazily loading translated strings for JavaScript and it will be an issue for other plugins that start doing the same. At some point , this likely will be something addressed within WordPress itself.

• This reply was modified 4 years, 7 months ago by Darren Ethier (nerrad). Reason: fix broken link