Barry

Thanks for flagging this. We’re aware of some issues relating to translations following the WP 6.7 release, and based on your notes here we’ll also follow-up on the implications of plugin_locale having been removed:

https://github.com/woocommerce/woocommerce/issues/52886

Hi Carl,

https://developer.woocommerce.com/2024/11/11/woocommerce-9-4-supercharging-the-product-collection-block-more/#comment-46638

The above might answer your question. In short, it sounds like the current plan is that the feature will be enabled for all users starting with WooCommerce 9.6.

Yes, broadly speaking it is compatible with PHP 8.3. There may be some minor errors and warnings that surface from time-to-time, however, that do not appear with older versions.

wp-content/plugins/woocommerce-add-ajax-admin-dev

It looks like this error is coming from a different plugin and, based on the plugin slug, I don’t think it is one of ours.

If you can match the above (‘WooCommerce Add Ajax Admin Dev’) to one of your existing plugins, perhaps you can then reach out to the developer?

Thanks! We believe there may be an issue with our translations when running under WordPress 6.7, though that has not officially been released just yet (the current stable release being 6.6.2 at time of writing). Just to confirm, though, what version of WordPress are you using?

Can you also share a note of your language and locale? For instance, for some German-language sites this might be de_DE. You can find this by visiting WooCommerce ? Status (the currently configured language is listed in the first section).

Hmm. I don’t see any relevant changes that were made recently…

This translation issue came up a couple of days ago.

Did this coincide with any other changes you made on your site (such as plugin updates)?

Hi!

I’d recommend starting in this section of the docs. There are various sub-pages and links you may find useful. This guide also remains valid (and, wherever possible, we’d encourage you to use those APIs instead of custom queries).

Lastly, quite a lot of information on HPOS was delivered via the developer blog, so that may also be worth looking at.

I don’t have the Action Scheduler plugin installed. Why are there such tables for Action Scheduler in my database?

Action Scheduler is available as a plugin, but mostly it is included as a library for other plugins.

A great example is WooCommerce—Action Scheduler is packaged up inside it—and lots of other plugins do the same thing. So, to answer your question, I would imagine that you installed some other plugin that happens to use Action Scheduler ‘behind the scenes’.

How do I uninstall and delete these tables from the database?

Well, I’m still not sure how you are building the data to be exported, so it’s a little hard to answer … but if it is via a tool like phpMyAdmin then there are probably options to enforce the use of CREATE TABLE IF NOT EXISTS like I noted in my last reply.

Or, you could delete the tables from the destination database first of all, so long as you aren’t worried about losing data. Or, you could modify the SQL dump (again, per my earlier answer).

Possibly you need to use CREATE TABLE IF NOT EXISTS (relevant docs here). Or, if the tables already exist, then you could perhaps remove the CREATE TABLE statements. What are you using to do the import?

I think CSS was a typo, and should have been XSS ?? That said, please see this pretty relevant discussion (in fact, the same thread is linked to from the report you shared). In summary, it’s not clear that this is a ‘real’ vulnerability—instead, it seems some parties may have been exercising bad practices in relation to this library.

Beyond that, we did recently look at removing Select2, however it caused problems for other plugins. We’ll revisit, though and see what we can do (in the meantime, if you are directly using Select2 yourself, definitely do read through the comment I linked to and update your usage accordingly).

There was version 9.1.2, but they have already removed it from the repository.

We received some questions a little earlier from some other users who saw a notification that 9.1.2 was available after we had tagged it (that is, after we uploaded it to the plugin directory) but before we marked it as the stable release.

I suspect that is the source of the confusion here, but we’re not sure why it was happening and nobody should have seen update notifications prior to the final step of marking it as ‘stable’ (if you are interested, you can bear this out by reading through the SVN log: if we had ‘pulled’ the release, this would be recorded there).

Yes, the team definitely needs to improve testing of their code.

We put a huge amount of effort into testing our code but, even so, I agree there have definitely been some unwanted surprises. We’re working hard to improve on this and get back to steadier ground.

I’m sorry, @moeclone, but we can’t answer questions relating to premium plugins here. For support with those, please see this earlier note:

As for contacting support, please contact us at Woo.com > My Account > Support. You may need to create an account before you can access that page.

Thanks so much for the great feedback, we’re always happy to help ??

I’m not sure what documentation they pointed to, but this is a MySQL error rather than a PHP one … though it is certainly possible it could be triggered by PHP code interacting with the database.

Unfortunately, though, I cannot replicate this problem. However, some improvements to the relevant system (legacy order cleanup) are shipping in 9.1.0 (our next release, which is expected to land next week, on July 10th).

Since the worst of the problem has passed, in the sense you are not experiencing 403s, it may be worth pausing and waiting for that update and seeing what it brings.

Noticed the WooCommerce plugin update today (9.0.1):

• Fix – Check WC_Legacy_API instead of WC_API as that seems to be cached by lightspeed servers

As I guess you found, this was unrelated. Actually, the problem was not with LiteSpeed, but rather was an issue some customers experienced when a third-party update utility performed the plugin update.