Automatic Permalink regeneration

1. I think the “update_option_rewrite_rules” action fires when rules are flushed. (unverified)

2. I believe you have a larger issue than rewrite rules. All WC post types and taxonomies get re-registered on every single request, they do not persist like rewrite rules. Without proper registration, products and related taxonomies will not work right, even if the rewrite rules remain operative.

I realize this is at odds with observed behavior, but I still think it’s real issue. IMO you’re better off aggressively caching non-WC pages so WP doesn’t have to load at all, everything is served from cache. Seems more effective and less troublesome than selectively activating plugins or not. Note that activating a plugin on demand also involves some additional overhead, so while it may sound good in theory, the real gains may not be as great as you might think.

Thanks @bcworkz.

I do really like the caching idea; I wish I could set different cache timeouts based on sitemap (or taxonomy), but AFAIK, there’s no such option in wp-rocket, which seems (so far) to be the best caching plugin for me.

As for WC re-registering… if that’s the case, then why would there be WC entries (for Products) on the WP Permalinks page? Also, does that mean that the rewrite rules are flushed *every* request, when the taxonomies are re-registered? That seems goofy at best.

At least right now, the rewrite rules seem to be my only issue. That is, the (re-)registration of WC taxonomies doesn’t really matter if the user isn’t on a WC page. However, if the rewrite rules are not correct, then a request to a WC page (//site/product/product-name) ends up in an endless redirect since WP can’t figure out where to send the browser.

Rules only auto-flush when you visit the permalinks settings screen. There shouldn’t be WC elements on the permalinks screen if it’s deactivated. I have it installed on my test site, but it’s normally deactivated, and there’s nothing related on the permalinks screen. Elements could be there from a WC extension perhaps? The only other time a flush happens is when code calls for it. It’s not unheard of for plugins or themes to inappropriately call for flushing when it’s not needed.

The redirect for product URLs when WC is deactivated is due to the lack of registered post types. The rewrite rules exist (because the rules do persist) and attempt to initiate a query for the related product, but the parser at that moment knows of no post type “product”, so it triggers the redirect.

If products URLs ever do work with WC inactive, it’s likely due to caching. Even though selective server side caching on that level of detail isn’t feasible with WP Rocket, you could at least set appropriate caching headers for client side caching (you may already do so) on certain pages so people only need to endure a longer load time once per page. It’ll at least benefit return visitors.

While not having WC active when not needed would certainly benefit such pages, when you do need to activate it for WC related URLs, it would likely trigger a rules flush which would involve a significant performance hit. Only you can decide if the trade off is worth it; but for myself, I’m not convinced.

What I’m not understanding is, if one makes a product URL request, thus causing WC to be reactivated, why would that request get redirected? It seems like WC isn’t getting auto-activated like you think it does. Otherwise the post types and taxonomies would be registered and the URLs would work, right?

A bunch to unpack there, which I’m appreciative of. Let me give it a shot…

Rules only auto-flush when you visit the permalinks settings screen. There shouldn’t be WC elements on the permalinks screen if it’s deactivated.

I agree with you on this. Even when I was disabling WC, I always enabled it on /wp-admin/ requests, so it would always be present on the Permalinks screen.

The only other time a flush happens is when code calls for it. It’s not unheard of for plugins or themes to inappropriately call for flushing when it’s not needed.

I think this is getting at the crux of my question, and (unfortunately) means there’s no way for me to know / there’s not a specific page request that causes the flusing/rewriting. Rather, it’s some other plugin that’s calling flush_rewrite_rules() as part of some general page/post/tax request, resulting in the rules being regenerated when WC is not active.

I took a quick look through all the source for all the plugins and it is shocking to me how often/many times flush_rewrite_rules() is called. I wouldn’t have thought it necessary to flush those rules so often, but perhaps it is! (I don’t pretend to be an expert on permalinks/rewrites – not by a long shot!)

The redirect for product URLs when WC is deactivated is due to the lack of registered post types. The rewrite rules exist (because the rules do persist) and attempt to initiate a query for the related product, but the parser at that moment knows of no post type “product”, so it triggers the redirect.

This is the interesting bit. What I was *hoping* would be the case (and is the case for ~half a day at a time until the persisted rewrite rules are regenerated) is that the (persisted) rewrite rules would initiate a query for the related product, which would then cause WC to be loaded on the product page (and other WC pages like /cart, etc. which were whitelisted to run the plugin. The endless redirect only happens when the persisted rewrite rules have been regenerated (at a time when WC wasn’t active) to not have all the /product* rewrite rules present. Then, other “fallback” rules kick in and continue to redirect until the browser bails.

I hope that the paragraph above also answers this following point you made, but perhaps I’m still missing something?

What I’m not understanding is, if one makes a product URL request, thus causing WC to be reactivated, why would that request get redirected? It seems like WC isn’t getting auto-activated like you think it does. Otherwise the post types and taxonomies would be registered and the URLs would work, right?

Onto more caching…

you could at least set appropriate caching headers for client side caching (you may already do so) on certain pages so people only need to endure a longer load time once per page. It’ll at least benefit return visitors.

I do already have client side headers set, but unfortunately I have very few (single digit percent?) return visitors to any given page that would be cached – my site is a series of stories that folks tend to read, and then are done with that story. I like the thought process though, thank you!

Also, just to share – not that it matters all that much – when WC is enabled, I see about a 4-7 second increase to any (uncached) page generation, which is why I’m looking to make some sort of optimization. And, I’m running this on what is a severely underpowered/unoptimized system (in Azure) because… well, mostly because I’m both cheap and have a propensity to MS infrastructure given my work life.

I really do appreciate your time/responses here. Even if I’m not able to do what I wanted to do, it does help me to (slightly) better understand the situation and other ways to address it.

it is shocking to me how often/many times flush_rewrite_rules() is called.

You and I both! In my practice I only call it on plugin activation/deactivation to add/remove plugin specific rewrite rules. Because the rules persist, I cannot imagine when else it’s needed.

that the (persisted) rewrite rules would initiate a query for the related product, which would then cause WC to be loaded on the product page

From the rewrite rules, the request is passed to the parser. If the parser cannot understand /product/ because it’s not currently registered, the request may not ever get to a query. I’m not sure, I don’t fully understand how WP handles unknown request elements. Just what would cause WC to be loaded? WP would not do it on its own, you’d need code to detect a WC dependent request and to initiate its activation.

Maybe the answer is moot since things seem to be working as you want, at least until some unknown plugin code mucks up your scheme by flushing rewrite rules. I guess the crux of the issue is what is flushing rewrite rules and what to do about it. If you can figure out where it is called and find an action which fires before then, you could hook into it and reactivate WC. It’ll be essential that the action does not fire unless a rule flush is imminent, or that there’s some context your code could check to know that a flush is imminent.

Based on how many instances of flush_rewrite_rules() you’ve found, this may be a daunting task. However, it’s likely only one or very few instances are the cause of the problem. Figuring out which would be difficult unless you can identify a particular request or action that’s responsible so you can initiate it on demand.