[wp-trac] [WordPress Trac] #29118: Registering rewrite rules is hard, so let's introduce remove_rewrite_rule.

[WordPress Trac]

#29118: Registering rewrite rules is hard, so let's introduce remove_rewrite_rule.
---------------------------+------------------------------
 Reporter:  ericlewis      |       Owner:
     Type:  enhancement    |      Status:  new
 Priority:  normal         |   Milestone:  Awaiting Review
Component:  Rewrite Rules  |     Version:
 Severity:  normal         |  Resolution:
 Keywords:  has-patch      |     Focuses:
---------------------------+------------------------------

Comment (by rmccue):

 It was [https://github.com/humanmade/hm-rewrite/pull/13 integrated into
 the Human Made rewrite helper] (alternatively,
 [https://gist.github.com/rmccue/667e8d35a2d6ef32eacb this gist]).

 Here's my description from the pull request (and the crux of how it
 works):

 > This automatically flushes rewrite rules when they need to be. It does
 this by "generating" them on every request, which could potentially
 theoretically be slow.
 >
 > In practice, the slowest part of rewrite rules is deleting the option,
 and then saving it again, which WP does every time you call
 `flush_rewrite_rules`. If your rewrites haven't changed, deleting the
 option is unnecessary, as `update_option` can work out whether it needs to
 actually update the DB/object cache.

 I'm not entirely sure on whether we can integrate this, as it may be
 tricky with backwards compatibility. Let's say you have a filter that's
 adding one-rule-per-tag (I hope not, but who knows). It'll now go from
 only being regenerated when needed (rare) to on-load. This isn't a break
 of backwards compatibility, but could cause extreme performance
 degradation with poorly coded plugins.

 I've been running it personally on my own projects and on Happytables for
 a while now, and haven't seen any brokenness. There's negligible
 additional load (since internally, all you're doing is creating an array,
 which isn't a slow process) and extra time.

 Happy to create a patch (and a new ticket if this one isn't suitable), but
 there is a bit of developer education and evangelism we'd need to do here.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/29118#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform