Title: Automatic Permalink regeneration
Last modified: March 13, 2023

---

# Automatic Permalink regeneration

 *  [turbodb](https://wordpress.org/support/users/turbodb/)
 * (@turbodb)
 * [3 years, 2 months ago](https://wordpress.org/support/topic/automatic-permalink-regeneration/)
 * Not sure if this is the correct forum, if not, please let me know where to post…
 * I’m running a WordPress site with WooCommerce and in order to improve performance,
   I’ve written a MU plugin that unloads the WooCommerce plugin on non-WooCommerce
   pages.
 * The problem I’m running into is that after some amount of time (on the order 
   of a couple times per day), the permalinks to my WooCommerce products “disappear.”
 * I can fix this (regenerate the WooCommerce permalinks/rewrite rules) by navigating
   to the WP Permalinks page and clicking the Save Permalinks button. Unfortunately,
   that only works for half a day or so.
 * I assume this happens because (another plugin?) makes a call to flush_rewrite_rules()
   at some point, and because I’ve explicitly unloaded the WooCommerce Plugin, it
   is not registered to update its rules, thus resulting in no rules for anything
   under /product/.
 * So, a couple questions:
    1. Is there a way to force loading the WooCommerce plugin when these rewrite rules
       are regenerated? (I assume there probably isn’t.)
    2. What’s the best way to go about debugging what URI request is being made when
       the rewrite rules are regenerated? If I can figure that out, I’m totally happy
       to enable the WooCommerce plugin for any requests to those URIs.
 * Thanks,
   Dan

Viewing 5 replies - 1 through 5 (of 5 total)

 *  Moderator [bcworkz](https://wordpress.org/support/users/bcworkz/)
 * (@bcworkz)
 * [3 years, 2 months ago](https://wordpress.org/support/topic/automatic-permalink-regeneration/#post-16558745)
 * 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.
 *  Thread Starter [turbodb](https://wordpress.org/support/users/turbodb/)
 * (@turbodb)
 * [3 years, 2 months ago](https://wordpress.org/support/topic/automatic-permalink-regeneration/#post-16558821)
 * Thanks [@bcworkz](https://wordpress.org/support/users/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.
 *  Moderator [bcworkz](https://wordpress.org/support/users/bcworkz/)
 * (@bcworkz)
 * [3 years, 2 months ago](https://wordpress.org/support/topic/automatic-permalink-regeneration/#post-16561772)
 * 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?
 *  Thread Starter [turbodb](https://wordpress.org/support/users/turbodb/)
 * (@turbodb)
 * [3 years, 2 months ago](https://wordpress.org/support/topic/automatic-permalink-regeneration/#post-16562703)
 * 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.
 *  Moderator [bcworkz](https://wordpress.org/support/users/bcworkz/)
 * (@bcworkz)
 * [3 years, 2 months ago](https://wordpress.org/support/topic/automatic-permalink-regeneration/#post-16567464)
 * > 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.

Viewing 5 replies - 1 through 5 (of 5 total)

The topic ‘Automatic Permalink regeneration’ is closed to new replies.

## Tags

 * [permalinks](https://wordpress.org/support/topic-tag/permalinks/)
 * [rewrite rules](https://wordpress.org/support/topic-tag/rewrite-rules/)

 * In: [Developing with WordPress](https://wordpress.org/support/forum/wp-advanced/)
 * 5 replies
 * 2 participants
 * Last reply from: [bcworkz](https://wordpress.org/support/users/bcworkz/)
 * Last activity: [3 years, 2 months ago](https://wordpress.org/support/topic/automatic-permalink-regeneration/#post-16567464)
 * Status: not resolved

## Topics

### Topics with no replies

### Non-support topics

### Resolved topics

### Unresolved topics

### All topics