Darren Ethier (nerrad)

Hi @rughooker. That’s awful! We definitely don’t want any release of Woo Blocks breaking people’s sites and spend a lot of effort and time testing before release to try to avoid that.

Are you be able to share any more additional details about what was broken on your site? Were there any error messages in your PHP logs?

Hi @argentum,

The error you are reporting is a strong signal that the version of PHP executing in your environment is not supporting the return type declaration syntax (the part beginning with the colon after the wc_get_container function declaration).

WooCommerce core requires PHP 7 or greater. Since you mentioned you are encountering this when running WP-CLI, it’s possible your environment is using a lower version of PHP for command line execution (it’s possible to have different versions of PHP running for web and cli).

Since this is not a WooCommerce Blocks issue, I’m going to mark this thread as resolved.

Sorry to hear about your experience.

We’d love to hear more specifics if you’d care to share them?

Regarding “bloat on the frontend”:

– Performance is very much a real concern for us and we are always looking for ways to make things more performant. Do you have any specific concerns around the bloat you are seeing?

Regarding “it is not extendible”:

While we definitely know there isn’t the same extendibility in the blocks as there were for shortcodes and some other functionality, I would disagree it isn’t extendible at all. We’ve been especially focused on the Cart and Checkout blocks for the past year or so and extendibility has been a high priority there with a number of different ways to extend the Cart and Checkout blocks already in place (and implemented by payment methods, Subscriptions, and other extensions). However, we’re definitely not done here yet.

Regarding “It’s absolutely unusable”:

I understand it may not be usable for your context and that’s largely one of the reasons this remains a feature plugin for now so folks that don’t find value from the functionality can disable the plugin. We are very grateful for the many people who have used the plugin and are providing valuable feedback that help us identify areas to improve so that we are building something useful for merchants and stores. That’s definitely why we release a lot of the work we’re doing through this feature plugin so that we can get that early feedback.

Thanks for your review Emer! It was very motivating to see this (and sorry for the delay in replying).

Good news! Having a checkbox option for Terms and Conditions is something we’re working on. I don’t have an ETA but we are hoping to have that available (along with some other really cool changes around further customization options) within 1-2 months.

Thanks for the kind words! Is there anything in particular you really enjoy?

Hi @jackcao,

Thanks for your review and for your feature request. Improving various functionality for the checkout block to better support one page checkout or one click checkout options is definitely something on our radar for consideration.

Hi @deny21

The account creation flow works differently for the checkout block than it does for the default shortcode based checkout flow. Currently there is no password field for shoppers to fill out. Instead a password is automatically created for them and they will receive an email for setting a new password after completing the order.

This implementation was put in place because research has shown that reducing friction by eliminating things like user account creation fields etc during the checkout flow contributes to higher conversion rates (see one example of the research here.

With that said, we do have on our roadmap to implement some additional functionality that allows for merchants to implement delayed account creation after the checkout submission. This would include the ability for shoppers to specifically designate the password they want to use for their accounts.