WP_Rewrite::flush_rules() should not delete 'rewrite_rules' option

[SergeyBiryukov]

If permalinks are disabled, there's an extra query on each page load:

SELECT option_value FROM trunk_options WHERE option_name = 'rewrite_rules' LIMIT 1

It comes from WP::parse_request()​, which calls WP_Rewrite::wp_rewrite_rules()​.

Normally, it should be covered by wp_load_alloptions()​, but:

1. The rewrite_rules option is not created on installation.
2. If you enable permalinks and disable them again, WP_Rewrite::flush_rules()​ deletes the option.
3. WP_Rewrite::wp_rewrite_rules()​ attempts to recreate it, but fails due to the check in update_option()​.

I think we should replace rewrite_rules option with an empty value instead of deleting it.

Introduced in [3373].

[SergeyBiryukov]

Related: #11384, #27276.

[nacin]

Can we confirm (perhaps with a unit test) that an empty option gets updated to a populated option when a structure is set and rules are flushed?

[jesin]

Tests if rewrite_rules is an array and is not empty

[voldemortensen]

Refreshed patch and combined unit tests.

[swissspidy]

29107.2.diff​ is an updated patch that applies cleanly against trunk.

In what ways does this affect #11384?

[swissspidy]

In 36254:

Rewrite: Ensure WP_Rewrite::flush_rules() does not delete the 'rewrite_rules' option.

Instead, the option gets updated to an empty string.
Adds unit tests.

Props SergeyBiryukov, jesin, voldemortensen.
Fixes #29107.

[swissspidy]

#11384 was marked as a duplicate.

[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 ​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 notoptions array before it's queried independently, or something less sinister?