Sara Die Webmacherin

Hi Alina,
Perfect, thank you. I will advise my customer to buy the PRO version.

Hi Alina,

Is this only available for the Gutenberg block?
We are using the shortcodes with another page builder.

Regards,
Sara

Hello Akshaya,

Thank you very much for the detailed analysis. I will inform the plugin developer.

As far as I can see load-scripts.php is only blocked on the UpdraftPlus page. All other admin pages load normally.

Can ModSecurity block only one page?

Hello Krystian,

Thank you for confirming that “failed” order status shouldn’t reduce stock.

We have a lot of hacky custom code that interferes with stock and I’m in the process of getting rid of it. Unfortunately in this process I break a lot of order processes.

You can mark this issues as resolved, since your plugin is most probably not a fault.

Hello Krystian,

I know what the duplicate invoice ID error is and we want to keep that security feature. We have a very high volume of orders and mostly the error occurs due to user behaviour (so nothing we can do about that).

The problem is with the order status. A failed state should either not reduce the stock, or it should be canceled automatically after a certain time, so the stock will be restored.

How is the plugin supposed to work in this regard?

Regards,
Sara

Update: Some combination of downgrading (to 8.9.0) and reimporting the statistics data helped. After that I could also upgrade to 9.1.2 again.

I guess the problem was somewhere in our huge database…

Hi Carol,

Yes, it worked correctly before. I have a PDF with the numbers of March, which where exported in June.

I do monthly updates, so it could have been this or the last update (I don’t know the exact date of the last export).

Here are the tax settings:
https://ibb.co/sJPvW90
https://ibb.co/tQGy4rp

I tried reverting to WooCommerce 9.0 & even 8.9. No change.

Regards,
Sara

Hi Omar,

I just wanted to update that this is not resolved and cannot be resolved with the methods you suggest.

I did some digging into the Woocommerce files and with the current code for the block checkout it is impossible to correctly translate the errors.

First of all for all empty form errors there is only one translation string “Please enter a valid %s”. But all languages where the nouns influence the words referencing them this will not work. We need a separate translation string for every empty field.

Form validation translation only one string for all fields: https://ibb.co/MsWK3RD

Second the placeholder in the string described above is always converted to lowercase. This does not work in German specifically, because nouns always have a capital first letter.

Form validation placeholder converted to lowercase: https://ibb.co/qCXPbnJ

Third this string does not appear in the normal translation files. The normal translation files have separate (and correct) translations for all fields, but they are not used in block checkout.

Woocommerce translation used in old checkout: https://ibb.co/KLcRDzV

I am aware that you probably can’t solve the issue in the support forum, but this should be considered for future updates. Especially since this was implemented in the old checkout and German is not the only language that has this problem.

List of languages with grammatical gender (or noun classes): https://en.wikipedia.org/wiki/List_of_languages_by_type_of_grammatical_genders

How grammatical gender (or noun classes) influence other words: https://en.wikipedia.org/wiki/Grammatical_gender

• This reply was modified 5 months, 3 weeks ago by Sara Die Webmacherin.

Hi Abdalsalaam, We have only tested in sandbox so far.

Hi Omar,

Unfortunately your tips won’t work.

Woocommerce including translations is up to date and German is translated 100%. The problem is that these strings are already translated incorrectly and not available in the normal translation files at all.

So the question is where does the block checkout (or the form validation) get its translations from?

Hi Carol,

You can find the system report here: https://gist.github.com/DieWebmacherin/beb7522766e970cbcf001180ddc5067f

And here is the report for the shop with correct tax reports: https://gist.github.com/DieWebmacherin/a4eb6e9ba0e0227003694ca0ac13c975

We don’t have fatal errors in the log.

And here is a screenshot of the tax reports:

• This reply was modified 8 months, 4 weeks ago by Sara Die Webmacherin.

Im am in a good spot. I am using only CPTUI taxonomies now. They work fine for CPTUI and other post types.

I can’t find anything related to taxonomies, but the other add_actions have a priority of 10, 5 or nothing.

The Avada theme is rather complex, so it’s quite hard to find anything that isn’t relying on a lot of other code that I have to look up in turn.

I can provide access to the Avada files or the website if that helps.

• This reply was modified 10 months, 2 weeks ago by Sara Die Webmacherin.

Thank you for the reply, I already tried to activate REST for the theme taxonomies. It doesn’t work for me and I don’t know how to debug that part.

I think the effort for debugging is to high anyway, since I can use the CPTUI taxonomies with a bit of extra effort. I just thought maybe you had a solution.

Thank you for your help!

• This reply was modified 10 months, 2 weeks ago by Sara Die Webmacherin. Reason: Marked as resolved without solution