[wp-trac] [WordPress Trac] #37646: Make wp-settings.php a series of do_actions()

[WordPress Trac]

#37646: Make wp-settings.php a series of do_actions()
--------------------------------------+------------------------------
 Reporter:  johnjamesjacoby           |       Owner:
     Type:  enhancement               |      Status:  new
 Priority:  normal                    |   Milestone:  Awaiting Review
Component:  Bootstrap/Load            |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  2nd-opinion dev-feedback  |     Focuses:
--------------------------------------+------------------------------

Comment (by MikeSchinkel):

 Replying to [ticket:37646 johnjamesjacoby]:

 An interesting proposal.  On the surface I like it.

 OTOH I see several causes for concern that I don't think you covered.
 ''(If you did, blame my lack of reading comprehension on longish tickets.
 :-) )''

 1. '''The first problem is chicken-and-egg'''.  Assuming you are not
 talking about wholesale reorganization of `wp-settings.php` then most of
 your `do_action()` calls occur before `mu-plugins` are loaded, so where
 are you could to call `add_action()`? `advanced-cache.php` is called
 early, but not early enough for your example.

 And do we want to pollute `advanced-cache.php` with site-custom add-action
 calls?  Minially you'd need `bootstrap.php` file early, but even it could
 not be called before constants are defined unless it was to be placed in
 the site root where ABSPATH points, and not good if you moved WordPress
 core into a subfolder for Composer sake.

 2. While I do like the''' idea of hooking, your approach is problematic
 IMO'''. It is equivalent to approaches I have seen with some themes, like
 ''(early)'' Thesis ''(when I still used it)'' that caused emmense
 heartaches. And in `admin-filter.php`, not an approach I think we should
 emulate.

 Basically with approach you posted a reader of the code cannot know what
 '''default''' code will be executed without looking in another file, or
 they must run it under a debugger to be able to tell. That makes static
 analysis of the code more difficult and  makes it much harder to learn.

 Better would be something like this:

 {{{
 require WP_CONTENT_DIR . '/bootstrap.php';

 add_action( 'wp_settings_load_versions',     'wp_settings_load_versions'
 );
 add_action( 'wp_settings_load_constants',    'wp_settings_load_constants'
 );
 add_action( 'wp_settings_load_translations',
 'wp_settings_load_translations' );
 add_action( 'wp_settings_load_environment',
 'wp_settings_load_environment' );
 add_action( 'wp_settings_load_early',        'wp_settings_load_early' );
 add_action( 'wp_settings_load_database',     'wp_settings_load_database'
 );

 if ( apply_filters( 'do_bootstrap', true ) ) {
         do_action( 'wp_settings_load_versions' );
         do_action( 'wp_settings_load_constants' );
         do_action( 'wp_settings_load_translations' );
         do_action( 'wp_settings_load_environment' );
         do_action( 'wp_settings_load_early' );
         do_action( 'wp_settings_load_database' );
 }
 }}}

 Or even better:

 {{{
 require WP_CONTENT_DIR . '/bootstrap.php';

 $bootstraps = array(
         'wp_settings_load_versions',
         'wp_settings_load_constants',
         'wp_settings_load_translations',
         'wp_settings_load_environment',
         'wp_settings_load_early',
         'wp_settings_load_database',
 );
 foreach( $bootstraps as $bootstrap ) {
         add_action( $bootstrap, $bootstrap );
         if ( apply_filters( 'do_bootstrap', true, $bootstrap ) ) {
                 do_action( $bootstrap );
         }
 }
 }}}

 Then elsewhere:

 {{{
 function wp_settings_load_versions() {
         // Load versions
 }
 function wp_settings_load_constants() {
         // Load constants
 }
 function wp_settings_load_translations() {
         // Load translations
 }
 function wp_settings_load_environment() {
         // Load environment
 }
 function wp_settings_load_early() {
         // Load early
 }
 function wp_settings_load_database() {
         // Load database
 }
 }}}

 With the above any reader of WordPress core code could more easily
 determine what is being called by default during bootstrap rather than
 having to hope they have found all the appropriate needles in the haystack
 that is the WordPress core codebase.

 3. I assume you are aware of the <a
 href="http://becircle.com/drupal_7_line_by_line_part_2_bootstrap">prior
 art in Drupal</a> with it's bootstrap process?  Not saying their's is an
 approach to emulate but maybe they have learned some things we don't want
 to repeat that might be available to learn from their public writings on
 the topic?

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