Lakjin

If it helps, think of it as cached WordPress page (static) vs uncached WordPress page (dynamic). No reason to do the latter.

Why’s that? Unless a website is adding new content every few minutes, dynamic wastes a LOT of resources. If you are concerned about those high content websites, you can add an option to update the static sitemap every X minutes. Static is way better than dynamic. I don’t want to waste 10 – 100 MB (depending on size of sitemap and website) every time a bot accesses my sitemap.

I understand that. I *want* static files. That is why I’m testing the feature. What I’m reporting to you is the bug when I disable dynamic files. For the time being until this bug is fixed, I have dynamic enable.

Tried that as well. This error happens even if there were no files there before disabling the dynamic feature (i.e., error happens even when AIO itself is the one creating the files).

@michael: deleting the files via FTP does not help. The error just reappears after AIO itself creates the files.

Because some people may not want to turn over their whole DNS to Cloudflare. We offer one-click use of CDN whereas the integration with Cloudflare is significantly more complicated.

You get all the benefits of Cloudflare’s network without the hassle of having to setup and use Cloudflare.

Fair enough. I didn’t use $wpdb because I saw no reason to unnecessarily load wp-load.php, but yeah, I understand the need for it if it is to be a plugin.

Great! Here you go: https://gist.github.com/BobSmithJoe/b76fb90b546560b2b17d

(Don’t laugh, its amateur code.)

Thanks for the link.

It isn’t urgent, as I am already ‘archiving’ orders with code that I have to keep databases small. I was just interested in getting better integration with WooCommerce to make archive orders accessible, such as via reporting.

>>I’ll add it to my ideas list – might have a go at an upcoming hack day. Archived orders wouldn’t be ‘reportable’, just stored elsewhere.

Would you be interested in the code I’ve written up? My code pretty much does this.

Glad to hear it worked! Can you please explain how you got it to work, for the help of people in the future who come across this?

Thanks for the review!

Thanks for the change, appreciate it.

I wouldn’t mind the archive ordering functionality as a plugin. Do you any person recommended in mind to build this? I am open to paying a modest fee to do it, especially as I have part of the code already (they would have to make sure the code logic works and add the WooCommerce customization end).

@mike: If there was some archiving feature, you wouldn’t have to worry about addressing both uses cases in regards to dbdelta, because with smaller ‘main’ tables, the indexes would be recreated very quickly — and thus no downtime — while the indexes on the ‘archive’ tables could be done in the background with no website impact.

@mike: I think the queries eventually finished — my website came back up after about 10 mins, the MySQL queries cleared, and the tables appear to have indexes. Is there any way for me to tell for sure? As I said, I’m no expert.

Migrating orders away from wp_posts is great, but it isn’t the same as archiving old orders. For example, our wp_woocommerce_downloadable_product_permissions table and wp_woocommerce_order_itemmeta are more than 2 gigs each. Most of that is just old data sitting there from very old orders.

If there was some way to move old order data to an ‘archive’ table, that would greatly speed up WooCommerce — and it should be fairly straightforward to make it so WooCommerce first looks in the regular tables for data and then looks in archive tables for data if needed, such as when running reports. I’ve created an elementary script that moves data to archive tables, but it is just that — elementary.

So basically the issue here is, my tables are too large to do this reindexing often.

Have you guys considered adding a feature to WooCommerce to ‘archive’ old orders? This way, WooCommerce stays speedy by having old orders in an archive table, which is only accessed on an as-needed basis as opposed to regularly? That would solve issues like this.

I’ve written a short script to ‘archive’ orders so as to keep the table size down, but I’m no expert and without official WooCommerce support, I can’t access those archived orders (e.g. if I want to run reports). I can share the script, if you like.

Having a feature like this would make WooCommerce more attractive to high-volume websites, like mine.

Mike,

Thanks for the reply. So it has to do with this change in 2.5.5:

Fix – Before running dbdelta, drop indexes to prevent duplicate key notices.

I think I know why my website is hanging. It is because our wp_woocommerce_downloadable_product_permissions and wp_woocommerce_order_itemmeta are fairly large and it is taking a very long time to recreate the indexes. Our smaller websites did this update fairly quickly with little to no hang.

Is this dbdelta function run often or just after plugin update? If it runs regularly, this basically kills WooCommerce for us unless there is a workaround for this.