Vedanshu - a11n

Thanks for the screenshots, I am seeing some clauses that are not added by WooCommerce core, such as private, wc-shipping, wc-refund-request and wc-shipping-status. They might be getting added by a plugin, and if this query is happening on every page, it will definately slow down the site immensly.

Do you know where might these be getting added from? Perhaps doing a plugin conflict test like this will help -> https://woocommerce.com/document/how-to-test-for-conflicts/.

Ok, that’s not high number of products at all. Are you comfortable with running queries? If so, would you be able to EXPLAIN on the above slow query, like this:

EXPLAIN SELECT SQL_CALC_FOUND_ROWS mVkV6_posts.ID

FROM mVkV6_posts

LEFT JOIN mVkV6_term_relationships

ON (mVkV6_posts.ID = mVkV6_term_relationships.object_id)

INNER JOIN mVkV6_postmeta

ON ( mVkV6_posts.ID = mVkV6_postmeta.post_id )

INNER JOIN mVkV6_postmeta AS mt1

ON ( mVkV6_posts.ID = mt1.post_id )

WHERE 1=1

AND ( mVkV6_posts.ID NOT IN (

SELECT object_id

FROM mVkV6_term_relationships

WHERE term_taxonomy_id IN (7,9) )

AND mVkV6_term_relationships.term_taxonomy_id IN (366) )

AND ( ( mVkV6_postmeta.meta_key = '_price'

AND CAST(mVkV6_postmeta.meta_value AS SIGNED) != '' )

OR ( mt1.meta_key = '_price'

AND CAST(mt1.meta_value AS SIGNED) != '0' ) )

AND ((mVkV6_posts.post_type = 'product'

AND (mVkV6_posts.post_status = 'publish'

OR mVkV6_posts.post_status = 'wc-shipping'

OR mVkV6_posts.post_status = 'wc-shipped-status'

OR mVkV6_posts.post_status = 'private')))

GROUP BY mVkV6_posts.ID

ORDER BY mVkV6_posts.menu_order ASC, mVkV6_posts.post_title ASC

LIMIT 0, 12

It’s basically the same query, EXPLAIN keyword added in front of it. This will tell us what part of the query is slow exactly.

But let us know if you are not able to run a direct query, in which case, screenshots from query monitor on the slow page will also be very helpful.

Hey @belalzekry ,

This is essentially a slow query issue, presumably because of number of products/categories that are there on the site. Before we suggest possible options, would you be able to share how many products and variations do you have ?

If there are a lot of products, then there are plugins that will help in better storing/querying this data, or even export this query to systems such as elastic search.

Hi @kaschwei,

Thanks for bringing this to our attention. Accessibility is very important to us, and there has been lot of work for accessibility in last few releases, especially in WooCommerce 9.0 (https://developer.woocommerce.com/2024/06/18/woocommerce-9-0-our-most-accessible-checkout-and-much-more/). 

Ist there a working group, who modified the woocommerce online shops and makes it accesible for this law?

We track accessibility (and other bugs/enhancements) in GitHub ->?https://github.com/woocommerce/woocommerce. If you notice something that’s not accessible or in compliance with EU directive, I’d recommend opening an issue on the Github so that we can track and address it in time:?https://github.com/woocommerce/woocommerce/issues/new/choose.

Let us know if you need any additional help.

Thanks!

Hi @datracon

We are investigating the issue, but for this comment:

I can’t create new orders in backend. All theses problems appeared with version 8.8.2

Are you seeing an error, maybe something in the logs? Can you provide more details please

Hey, this notice comes when ActionScheduler migration is pending and is likely not related to HPOS. Can you share if you see any pending actions when you go to WooCommerce > Status > Scheduled Actions, and see if there are any actions under the “Pending” tab?

Hey, it seems like there was some error in creating custom order tables, and the weirdness you are seeing is because of this. Although, the tool to create the table should still be presented (I will log a report and investigate and fix this).

(Note that this is not for the production site, I am assuming you are testing on a staging site with a cloned database. Please let me know if that’s not the case).

Meanwhile, can you please try the following:

1. Switch back to post as the choice of data storage from WooCommerce > Settings > Advanced > Custom Data Stores. This will enable the option to disable the feature.
2. Disable the HPOS feature by going to WooCommerce > Settings > Advanced > Features.

Above steps will enable the tool to delete custom order tables, which you can find in the WooCommerce > Status > Tools actions.

Please delete the custom order tables, and then follow the steps again to enable the feature and see if that fixes it. Please also see if you can find any error logs about what might be happening. If you can reproduce the issue again, please share the WooCommerce status report, so that we can try to reproduce the error.

Hey, I won’t recommend enabling HPOS until all your plugins are compatible. Theoretically, you can enable it with sync enabled, which will speed up all the search, lookup (and other related queries happening in the post meta table) at the cost of performance decrease in creating orders.

If you have a staging site (with a copy of the database, but not the same database), though, I’d recommend you perform the initial migration and test out the site to see what it’s like.

We are planning to reach out to yet incompatible plugins and request them to support HPOS very soon, so hopefully, it won’t be months/years before you can use the feature.

I see. Thanks for this extra context. This does not looks related to the recent update, and is possibly something else. It seems like there is an issue in the arguments where the action was scheduled.

Can you post what hooks are actions attached to?

If you are comfortable with PHP and running custom code, then for both these actions, perhaps you would be able to run them manually by executing do_action_ref_array( 'name_of_the_action_hook', array_values( 'args' ) );

Caveat -> Below section is likely only relevant for specific case faced by @hoodvisions.

If you can run them after fixing the error in arguments manually, then it would be safe to delete the actions so that you won’t have to truncate the table periodically. Alternatively, if you are confident that those actions are not important, or can be enqueued again, then you can delete them too (because they are not being processed anyway). <- But do this only if you are confident with PHP and WordPress/WooCommerce.

Thanks for all the reports, we are looking at this as the priority. Redoing setup is not intended at all and is a bug. Sorry for the inconvenience everyone!

Hi, can you help us in reproducing this bug by adding following info:

1. Which version did you upgrade from if you remember it?
2. System status report, you can get it by going to WooCommerce > Status and click on get System report button.

This would definitely be a bug and not intentional at all. But so far I have not been able to reproduce it in my test sites.

This setting changes what is displayed on the main category page.

In my local testing, if I set the value to “Category display” the main category page does show me a list of sub-categories if the main category has any.

If the main category does not have any subcategories it shows me products instead, which I think is the expected behavior.

So just to confirm can you check that from wherever you clicking on the main parent category, it actually takes you to the parent category page?

Some widgets may apply a filter for the category instead of redirecting you to the parent category page. The category page may look like /product-category/category-name, although could change depending upon configuration.

Hi @rhyszh,

By default this plugin will load GA code only on eCommerce specific pages.

If you’d like to enable for all pages, go to WooCommerce -> Settings -> Integrations -> Google analytics page and tick the checkbox for “Enable Standard Tracking” setting. This will load GA code on all pages.

I tested on my local install with the twenty-twenty theme and enabling this setting worked for me.

Feel free to reply back if this does not fix your problem.

Hi, I am assuming you are on WooCommerce 4.3, if so, please go to wp-admin/admin.php?page=wc-status&tab=tools page on your website and find a button called Verify Database (It should be second last tool on the page). If you click on this button, WC will try to verify if all the tables are present (and create the ones that are not present).

You are seeing this notice because we added a check to make sure if all needed DB tables are present or not.

I overlooked earlier and noticed just now that you have already created the table in your original post, in this case, I would recommend staying at 4.3 version. This notice only displayed when checking for the table fails for some reason, if the table is created (as you have verified), then its harmless and safe to ignore. We will look into why it is shown in the first place though.

You can also confirm if this table is present and detected by WC by going to /wp-admin/admin.php?page=wc-status#status-database.