[wp-trac] [WordPress Trac] #29107: WP_Rewrite::flush_rules() should not delete 'rewrite_rules' option

[WordPress Trac]

#29107: WP_Rewrite::flush_rules() should not delete 'rewrite_rules' option
---------------------------------------------+-------------------------
 Reporter:  SergeyBiryukov                   |       Owner:  swissspidy
     Type:  defect (bug)                     |      Status:  closed
 Priority:  normal                           |   Milestone:  4.5
Component:  Rewrite Rules                    |     Version:  2.0.1
 Severity:  normal                           |  Resolution:  fixed
 Keywords:  has-patch has-unit-tests commit  |     Focuses:
---------------------------------------------+-------------------------

Comment (by johnjamesjacoby):

 `update_home_siteurl()` and `site-info.php` both continue to call
 `delete_option( 'rewrite_rules' )`.

 Is it possible to confirm whether those usages may cause this issue to
 reappear?

 Also, `delete_option( 'rewrite_rules' )` has been used for a very long
 time as ''the way'' for plugins to easily (and maybe poorly) queue up a
 rewrite rule flush on the subsequent page load. A
 [https://github.com/search?q=%22delete_option%28+%27rewrite_rules%27+%29%22&type=Code
 quick search on GitHub] shows over 47,000 usages across all repositories
 of people using it, mostly for this reason.

 Is that enough in the wild for core to provide a helper function (like
 `queue_rewrite_rule_updates()` or something) that everyone can change to
 using instead of incorrectly deleting the option and causing this extra
 query to reappear?

 Or... instead of caring if the option is empty vs. missing, is there a
 different approach core can take to tuck this concern under the rug, and
 internally add `rewrite_rules` to the `nooptions` array before it's
 queried independently, or something less sinister?

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