ivydev

Thank you @omarfpg. This is helpful. I was able to update Woocommerce (and its database!) on the live site this morning.

Please note that this thread is only about possible downtime or other degraded user experience during a lengthy Woocommerce database update. I would like to know if anyone has knowledge of whether the Woocommerce database update in particular causes downtime or other degraded user experience.

Please do not post about what to do during any site maintenance work in general. I’m looking for someone who knows what happens during the Woocommerce database update (beyond what one can google) to provide insight hopefully. Could such a person tell me that the process runs in the background and doesn’t affect the front end at all? It would be great to be reassured of that if someone knows!

Would you consider adding it to a future release of the Pro version?

I’m looking for the category filter to be able to display nested categories something like this, just some kind of indication of the hierarchy:

Category A
Category B
–Category B1
–Category B2
Category C

Excellent! Thank you. Please let me know here when it is available.

Hello,

I get the same error as the original poster with PHP 8.2 and WordPress 6.3.1 and Adminimize?Version 1.11.9.

/wp-admin/index.php is an example page that has the error multiple times.

No, it doesn’t work. No matter how much I browse around the site and then check the size of the cache, it never goes down with this code in place.

I also installed the WP Crontrol plugin, which allows me to see what’s happening in the WP-Cron system, to make sure I scheduled the task correctly. It shows my_purge_cache_function() (which runs WP_Optimize()->get_page_cache()->purge()) in the scheduler, and gives me the option to “Run now”, but when I run it, there is no effect. Even after I browse around the site a little bit after the run, in case it requires page loads to actually run the code. But the cache does not change.

Thanks, this does fire, but it fires all the time. Is it possible to do it only once a day, something like this? (This does not work as it is.):

add_action( 'init', 'purge_cache' );
 
function purge_cache() {
	/*WP_Optimize()->get_page_cache()->purge();*/
	if (!wp_next_scheduled('my_purge_cache_hook')) {
		wp_schedule_event( '1644938400000', 'daily', 'my_purge_cache_hook' ); 
	}
}

add_action ( 'my_purge_cache_hook', 'my_purge_cache_function' );

function my_purge_cache_function() {
	WP_Optimize()->get_page_cache()->purge();
}

Thanks. But I am not seeing that this is working. If I understand correctly, this should be fired once activated plugins have loaded on a page. So, after adding this code, if I browse around to a few pages on the site, the code should have fired a few times, purging the cache. So I refresh WP Optimize in the admin panel, and I look at Current cache size to check that it has gone down, but it always stays the same (or higher).
Does “plugins_loaded” not fire when I think it does, or this really isn’t working?

I had the same problem. I did not have issues with caching or htaccess, as did other users who got the plugin to work. But I installed a lower version of the plugin, Version 1.2.1, and that is working fine with WordPress 5.0.3.

Thanks for your feedback. I also saw the bad reviews of Okta Verify, but our client wants to know if they can use it. Meh.
I tested the plugin with Authy, and everything seemed to work smoothly.

Well, I couldn’t get the plugin to properly filter by my custom attribute.
But the best solution turned out to be writing my own code to output the custom taxonomy archives, putting that into a shortcode, and then outputting the shortcode in the sidebar under the widget for the filtering. Style so that it all looks the same as the other filters coming from the filter plugin. In your theme’s woocommerce directory, you can create taxonomy-name_of_custom_taxonomy.php, and then add styles to your CSS so that the taxonomy results look the same as the other product results.

Your code changed fixed the problem! Thanks so much!

I imagine this tweak will be included in a future update, so we don’t lose it with our future updates?

As for Woocommerce, we have actually have version 2.5.5. Strangely enough, our installation does not give us the nag to update, so we didn’t notice it was very outdated. Perhaps another developer turned the nag off? Anyway, if we update, we’ll have to get the client to agree to pay for that work first. But Thanks for bringing it to our attention.

Thanks for helping me troubleshoot. When I add that code, a product search for “stain” returns this:

array(70) { [“s”]=> string(5) “stain” [“post_type”]=> string(7) “product” [“error”]=> string(0) “” [“m”]=> string(0) “” [“p”]=> int(0) [“post_parent”]=> string(0) “” [“subpost”]=> string(0) “” [“subpost_id”]=> string(0) “” [“attachment”]=> string(0) “” [“attachment_id”]=> int(0) [“name”]=> string(0) “” [“static”]=> string(0) “” [“pagename”]=> string(0) “” [“page_id”]=> int(0) [“second”]=> string(0) “” [“minute”]=> string(0) “” [“hour”]=> string(0) “” [“day”]=> int(0) [“monthnum”]=> int(0) [“year”]=> int(0) [“w”]=> int(0) [“category_name”]=> string(0) “” [“tag”]=> string(0) “” [“cat”]=> string(0) “” [“tag_id”]=> string(0) “” [“author”]=> string(0) “” [“author_name”]=> string(0) “” [“feed”]=> string(0) “” [“tb”]=> string(0) “” [“paged”]=> int(0) [“comments_popup”]=> string(0) “” [“meta_key”]=> string(0) “” [“meta_value”]=> string(0) “” [“preview”]=> string(0) “” [“sentence”]=> string(0) “” [“title”]=> string(0) “” [“fields”]=> string(0) “” [“menu_order”]=> string(0) “” [“category__in”]=> array(0) { } [“category__not_in”]=> array(0) { } [“category__and”]=> array(0) { } [“post__in”]=> array(0) { } [“post__not_in”]=> array(0) { } [“post_name__in”]=> array(0) { } [“tag__in”]=> array(0) { } [“tag__not_in”]=> array(0) { } [“tag__and”]=> array(0) { } [“tag_slug__in”]=> array(0) { } [“tag_slug__and”]=> array(0) { } [“post_parent__in”]=> array(0) { } [“post_parent__not_in”]=> array(0) { } [“author__in”]=> array(0) { } [“author__not_in”]=> array(0) { } [“cache_results”]=> bool(false) [“orderby”]=> string(16) “menu_order title” [“order”]=> string(3) “ASC” [“meta_query”]=> array(1) { [0]=> array(3) { [“key”]=> string(11) “_visibility” [“value”]=> array(2) { [0]=> string(7) “visible” [1]=> string(6) “search” } [“compare”]=> string(2) “IN” } } [“posts_per_page”]=> int(25) [“wc_query”]=> string(13) “product_query” [“tax_query”]=> array(1) { [0]=> array(4) { [“taxonomy”]=> string(11) “product_cat” [“field”]=> string(2) “ID” [“terms”]=> array(4) { [0]=> int(986) [1]=> int(987) [2]=> int(977) [3]=> int(984) } [“operator”]=> string(6) “NOT IN” } } [“ignore_sticky_posts”]=> bool(false) [“suppress_filters”]=> bool(false) [“update_post_term_cache”]=> bool(true) [“update_post_meta_cache”]=> bool(true) [“nopaging”]=> bool(false) [“comments_per_page”]=> string(2) “50” [“no_found_rows”]=> bool(false) [“search_terms_count”]=> int(1) [“search_terms”]=> array(1) { [0]=> string(5) “stain” } [“search_orderby_title”]=> array(1) { [0]=> string(34) “wp_posts.post_title LIKE ‘%stain%'” } }

By the way, I have set to not index any Taxonomies.

We had this error. We turned on the app’s public setting, and the error went away.

Well, it seems that after I clicked OK on the Licensing Module settings that were being shown to me instead of the tab content (even though the license info never changed), it began showing the appropriate tabs’ content again.
So I guess it’s OK now. How frustrating!
(Deactivating plugins had no effect, by the way.)