therab

It is still there, it still does not go away.
And it is SO annoying.
Where is a checkbox to remove it for good?

There IS a reason why I don’t need the paid plugin version on ALL systems, e.g. dev and staging.

So how to get rid of the banner?

Same here, it broke after my update yesterday.
In the code, that should send the emails, this error is triggered. I’m still digging in, but do you happen to see the same error in your logs?

PHP Fatal error: Uncaught Exception: Cannot construct an instance of Automattic\WooCommerce\Blocks\Domain\Services\CheckoutFields because it has not been registered. in /var/www/staging/wp-content/plugins/woo-gutenberg-products-block/src/Registry/Container.php:89

1.) Of course that works, because in effect it disables the code that was added (and with it introducing a breaking change). Something like this is what everybody needs to do as a workaround. Sadly.
Please note: Your fix may only help in some cases. In other cases, the user may be asked to log in, and that’s a different part of the code.
2.) Be careful, because with the next plugin update, you need to re-do your fix.
3.) Some of us are currently trying to persuade the developer of that piece of code to add a hook to turn on and off his breaking change, but we’re not there yet.

https://github.com/woocommerce/woocommerce/pull/38983

The look for a fix (or the problem) goes on on github, you may want to have a look here:
https://github.com/woocommerce/woocommerce/pull/38983

I rolled back this commit: https://github.com/woocommerce/woocommerce/commit/1cd947a32064bf3b716521110eae2856711ab775

in the file
/plugins/woocommerce/includes/shortcodes/class-wc-shortcode-checkout.php

in my installation, and it solved the problem.

I rolled back this commit: https://github.com/woocommerce/woocommerce/commit/1cd947a32064bf3b716521110eae2856711ab775

in the file
/plugins/woocommerce/includes/shortcodes/class-wc-shortcode-checkout.php

in my installation, and it solved the problem.

From those three plugins, I also use woocommerce and Payment plugins for Stripe WooCommerce.
But disabling “Payment plugins for Stripe WooCommerce” does not help now. When I re-view the “thankyou” page for my order, I always see the login form, instead the normal “thankyou” page.
It seems as if the order (post) itself is marked “private”, and anytime I want to see its thankyou page, I only get to see the login form. If that makes any sense…

Nope… that’s not it. It’s the same for the “thankyou” page of very old orders, too.

• This reply was modified 1 year, 4 months ago by therab. Reason: ...tried some more

There is no answer behind that link, so would you please post the solution here?

Same here. Not allowed to send the logs.

@alyvegermany nope, sorry.

Same here.
It works in Test mode where there is no 3D secure check, but in live mode, the checkout page simply stays put.

The stripe log gives it away that in reality, there should be some kind of (3D-Secure) dialog:

2020-09-23T15:27:41+00:00 DEBUG
====Stripe Version: 4.5.2====
====Start Log====
Stripe PaymentIntent pi_[blablayaddayadda] requires authentication for order 12345
====End Log====

So why does the 3D Secure dialog not appear?

Not a bug. There *are* plugins out there that remove <script></script> tags on purpose.
doh!

But still there is the nagging question: Why are the version numbers different?
Does that mean that the code base between ‘free’ and ‘paid’ is not the same?
Then it’s difficult to trust the paid version… does not seem right at all.

Ok, I fixed this brutally:
Whenever you change the country using the country selection dropdown, I set the shipping/billing country in the session, by using
WC()->customer->set_shipping_country(…)
and
WC()->customer->set_billing_country(…)
in class-wcj-price-by-country-core.php

Sadly, there is no hook for that to implement it in functions.php,
so I had to modify the plugin code directly and set the modified file to read-only to keep it from being overwritten on the next update.

Very ugly, very dangerous.
Would love to know a better way. A hook on WC()->session->set(…) would be great.

hi,
ok I understand. I was hoping for something I might have missed in your plugin.
After some more investigation, the “germanized” plugin stores most of the data for a possible export of invoices by date in the post_meta table.
An export option for invoices does exist for that plugin, but needless to state, it has barely the features of your export plugin (like scheduled export of your plugin’s ‘pro’ version)
Some of them are serialized objects, so there’s a lot of work ahead of me to export that stuff, and it will be a different task to export all single items sold in a date range, but those two are obviously two entirely different tasks to handle.

Thanks for your quick reply.

FYI: the woocommerce germanized post_meta keys for an invoice/packing slip
_invoice_address
_invoice_shipping_address
_invoice_recipient
_invoice_items
_invoice_currency
_invoice_tax_totals
_invoice_payment_method
_invoice_payment_method_title
_invoice_totals
_invoice_order
_invoice_order_number
_invoice_order_data
_invoice_number
_invoice_number_formatted
_invoice_filename
_invoice_attachment

Thank you, too.
It’s only worth patching if what’s already there is worth patching ??
Keep up the good work!

Rainer