Darren Ethier (nerrad)

The Cart and Checkout blocks are a preview, so we are still iterating to improve them and create extension points for other WooCommerce extensions. Eventually, there should be support for things like the Facebook pixel.

I’ll go ahead and close this issue since you were able to restore the shortcode checkout and cart flows.

Hi there,

Facebook purchases would likely not be tracking because whatever plugin you are using for that tracking is not integrated with the new Cart and Checkout blocks yet.

You can restore the original Cart and Checkout page by opening up whatever is set as those pages, removing the relevant block, and then adding the relevant shortcode back.

So for example, in what is currently set as the checkout page for your site, you would remove the checkout block, and then add the

[woocommerce_checkout]

shortcode. For the Cart page you’d remove the cart block and then add the

[woocommerce_cart]

shortcode.

I hope that helps!

Hi!

You mentioned that your website is returning a 500 server error code when you “use an api to organise” your products. You mention also that you’ve tracked this down to being caused by the Woo blocks plugin.

In order to help you resolve this we need more details than you’ve provided. As an example?

– What specific api are you using? Is this a REST API route/endpoint you’re writing about, or are you using some code API from WooCommerce core?
– What specific error is pointing you to WooCommerce Blocks being the cause?
– Will you outline for us some specific reproducible steps that provides a way to reproduce this on other sites?

If WooCommerce Blocks is causing critical errors on other sites we definitely want to investigate and find out what can be done to prevent that, but in order to do that we need more information.

Thanks!

I’m curious to know, is there a reason this plugin was designed to load strings via i18n instead of other conventional methods that would make translating these blocks easier?

We are using a conventional method for translating strings in JavaScript. A method that is currently supported by language packs in WordPress.

that would make translating these blocks easier?

“Easier” is a fairly relative term here. For folks used to using tools like Loco Translate and WPML I definitely can see how that would be seen as easy way to have custom translations for one’s own site. However, there’s also a whole group of users that could benefit from language packs being automatically installed on their sites in their Site’s language (if enough people saw the value in contributing translation strings for those languages so everyone can benefit)!

It also would be nice if plugin authors that built these other alternatives for translations would add support for the new conventional method of translating JavaScript in WordPress (which in turn would make it easier for folks like yourself who prefer to use such tools).

We definitely want to support folks in other languages that want to use our plugin so we’ve made sure to use the provided API WordPress exposes for ensuring the strings are translate-able.

Keep in mind, one of the reasons we released the blocks as an early preview is so that translators could start actively translating the strings as we iterate on the blocks to add more features. If we waited until the blocks were fully feature complete and then published them, that wouldn’t give translators much time to add strings.

Thanks for taking the time to comment, and I hope that helps explain things from our point of view?

What does a language pack do that is different from downloading the existing translations (i.e., Italian, which is at about 65%) as a .po or .mo, and loading them through WPML?

.po and .mo files are not what the JavaScript i18n API loads its strings from. Instead it uses JED formatted JSON files. While this format is available from download, it unfortunately is a single file that is not loaded automatically via the JavaScript i18n API used by WordPress core.

Unfortunately, because of this, there is currently no other way to get translated strings for the client rendered JavaScript unless it is through a language pack because of the way those strings are loaded and provided via the WordPress JavaScript i18n API. The language packs include multiple JSON files that are split out into just the strings related to a specific JavaScript file that is loaded and WordPress knows what JSON files correspond to the JavaScript file because of a MD5 hash of the file path. These individual JSON files are not available via direct download via the GlotPress interface.

• This reply was modified 5 years, 10 months ago by Darren Ethier (nerrad). Reason: fix message to remove already mentioned content and improve explanation

Hi again!

Thanks for the additional details. I’m a bit confused about where things are at. In your latest message it appears that you are saying the original reported issue is resolved. So to clarify, for the first (original) issue:

> In some reason after purchasing it shows empty checkout page.

Is this still happening, or are you saying it was resolved by redirecting to the thank you page which is what you seem to indicate here:

> So I had to create a redirect that contains checkout/order-received/ to custom /thank-you page. I used Astra Theme, Elementor Pro and Woo. Everything has the latest version.

Or are you saying that you attempted to create a redirect, but that also is not working?

Does the regular (using the shortcode powered checkout flow) checkout/order-received route work for you? As I mentioned in my original reply, the checkout block doesn’t modify the original route at all (in fact it simply allows the shortcode to power that route). So it looks to me like there’s something happening (possibly on a customized WooCommerce core template for that route) that is causing the issues.

For your second issue, it’s puzzling how a shopper could get to the state where they are able to add an additional item to the cart. I tried doing this on my test site and every place I could add a “single purchase” only item, I was prevented from adding that item to the cart when it’s already there. The only way I was to able to get into this condition was to change the setting for the product when the shopper already had two many products in their cart.

With that said, once I forced that condition, this is what I see with the Storefront theme and the rendered error message for the checkout block:

https://p299.p4.n0.cdn.getcloudapp.com/items/eDu1w5zD/Image%202020-06-19%20at%204.22.24%20PM.png

I’m guessing you are using the gettext filter to modify the string of this message? If so, you can’t use any html in that string because with it being a translation, it is not something rendered directly to the content as that would be a potential security concern.

Regarding your first issue, I definitely think this is something in your environment (custom code, another plugin) that is causing an error on the checkout/order-received route. As I mentioned in my previous reply, if you’re able to get access to your PHP error logs, that could help point you in the direction of the culprit.

> But I wish you can do something with it to fix such issues

I hear you there! Unfortunately, there’s nothing that can be done if we’re unable to replicate your reports. So to summarize:

1. The issue with the order-received route appears to be something causing an error in your environment. The Blocks plugin just passes off things to the checkout shortcode to handle that route and thus is not likely the cause here. You’ll need to find out what errors are happening that prevent that route from loading (which could be in your PHP error logs).
2. The issue with the error message for the checkout block appears to be custom text added via gettext that included html which will not be rendered for security reasons. The default message has no problems (that I can see).

I hope that helps!

Hi there @saugatakoley,

For item 2, the cart block is a change from the shortcode generated cart. With the block, merchants are able to configure the empty cart view using blocks in the editor. Here’s an example:

https://p299.p4.n0.cdn.getcloudapp.com/items/GGuo2Xbn/Image%2006-19-2020%2009%2003.jpeg?response-content-disposition=attachment&v=9a6bed4f18ebf8d3487fd4692ef469ef

Each of the elements in this editor view are blocks (which can be moved). This provides more flexibility to merchants to control how the empty cart view looks (adding or removing blocks to suit).

Regarding item 3, the border around the payment method description is likely something added by your theme. Do you still see that with other themes? It likely could be fixed with some custom css (either added to your theme if it’s a custom theme, or using the customizer advanced css option). Without knowing what exact selectors your theme is targeting for that border it’s hard to suggest a fix (it might be :focus that the theme is targeting on that element).

Looks like this review was duplicated here: https://wordpress.org/support/topic/so-disappointing-so-featureless-2/