[wp-trac] [WordPress Trac] #46087: Short-circuit `page_on_front` check during site creation

[WordPress Trac]

#46087: Short-circuit `page_on_front` check during site creation
---------------------------+-----------------------------
 Reporter:  boonebgorges   |      Owner:  (none)
     Type:  enhancement    |     Status:  new
 Priority:  normal         |  Milestone:  Awaiting Review
Component:  Rewrite Rules  |    Version:
 Severity:  normal         |   Keywords:  2nd-opinion
  Focuses:  multisite      |
---------------------------+-----------------------------
 During site initialization, `wp_installing()` is set to `true`. Among
 other things, this toggle disables all caching from `get_option()`. While
 I think that this behavior could use a general review (it's legacy
 behavior from MU that may have been an overly-broad fix for a narrow
 `alloptions` problem), there's one specific offender I'd like to consider
 addressing: `page_on_front`. `generate_rewrite_rules()` calls `get_option(
 'page_on_front' )` several times for each rewrite rule, and each of these
 calls requires a database read.

 Since `page_on_front` is set to 0 in the default schema, I propose that we
 short-circuit the check during site initialization
 (`wp_install_defaults()`). Something like:

 {{{
 add_filter( 'pre_option_page_on_front', '__return_empty_string' );
 $wp_rewrite->init();
 $wp_rewrite->flush_rules();
 remove_filter( 'pre_option_page_on_front', '__return_empty_string' );
 }}}

 Not terribly elegant, but it can reduce DB I/O by many dozens of reads.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/46087>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform