[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:  needs-patch 2nd-opinion  |     Focuses:
-------------------------------------+------------------------------

Old description:

> Now that #36819 is in, my master plan for `wp-settings.php` can begin.
>
> ----
>
> '''Problem'''
>
> `wp-settings.php` makes many assumptions, many on purpose, others by
> necessity, some on consequence, and a few by accident. It is somewhat
> poorly named for what it is, and it's a mishmash of globals, function
> calls, class instantiations, and do_action() calls.
>
> ----
>
> '''Solution'''
>
> `do_action()` all of the things.
>
> Make `wp-settings.php` a series of action calls. One for setting
> versions, one for initial constants, one for environmental setup,
> translations, database, plugins, themes, users, template output, and so
> on...
>
> Introduce a file named `wp-includes/default-actions.php` that serves 2
> purposes:
> * Includes a bunch of new functions that wrap up sections of what's
> already in `wp-settings.php`
> * Hooks those new functions into the new actions in `wp-settings.php`
>
> ----
>
> '''Why do we do this?'''
>
> As more robust and sophisticated plugins, themes, APIs, and systems start
> to use, rely on, and bend WordPress to their will, the need to override
> more & more pieces becomes apparent. While WordPress comes with a very
> handy set of default post types, taxonomies, APIs, helpers, wrappers, and
> tools, it may be desirable to unhook (or never load) certain pieces so
> that other pieces can take their place.
>
> In the past, this is done only with great intent, with strategic actions
> & filters in places where specific needs are being addressed. This is
> good in that it's predictable, but bad in that it's impossible for anyone
> to truly know what action or hook is *best* to perform any given
> subsequent action.
>
> By breaking `wp-settings.php` up into many clearly named `do_action()`
> calls, it becomes clearly obvious what actions perform what duties, while
> also introducing literally maximum flexibility in the entire system for
> new and exciting things to happen around WordPress itself.
>
> Imagine something like:
>
> ```
> // Load versions
> do_action( 'wp_settings_load_versions' );
>
> // Load constants
> do_action( 'wp_settings_load_constants' );
>
> // Load translations
> do_action( 'wp_settings_load_translations' );
>
> // Load environment
> do_action( 'wp_settings_load_environment' );
>
> // Load early WordPress settings
> do_action( 'wp_settings_load_early' );
>
> // Load database
> do_action( 'wp_settings_load_database' );
>
> // and on, and on...
> ```
>
> ----
>
> '''Epilogue'''
>
> This is a huge idea, easily scoffed at, and introduces code-churn like
> whoa. It would mean doubling down on WordPress's actions API, trusting it
> implicitly to load all of WordPress's core pieces & parts. It would open
> many doors to many unforeseen oddities while developers start dissecting
> all the ways things are tied together. It would also enable really cool
> external tools, like REST API drop-ins that can `SHORTINIT` WordPress if
> auth is missing, or WP CLI commands that can `die()` literally anywhere
> in the stack after they've done what they need to do.
>
> This is something I've wanted in WordPress since 2006 having seen similar
> in other libraries, and even old BackPress & bbPress gave nods and hints
> to back in the day.
>
> I'm also happy to give this a first patch if it's helpful to see visually
> the destruction it causes, or guide someone else along my vision for this
> if someone is willing and able to see it through before I am. <3

New description:

 Now that #36819 is in, my master plan for `wp-settings.php` can begin.

 ----

 '''Problem'''

 `wp-settings.php` makes many assumptions, many on purpose, others by
 necessity, some on consequence, and a few by accident. It is somewhat
 poorly named for what it is, and it's a mishmash of globals, function
 calls, class instantiations, and do_action() calls.

 ----

 '''Solution'''

 `do_action()` all of the things.

 Make `wp-settings.php` a series of action calls. One for setting versions,
 one for initial constants, one for environmental setup, translations,
 database, plugins, themes, users, template output, and so on...

 Introduce a file named `wp-includes/default-actions.php` that serves 2
 purposes:
 * Includes a bunch of new functions that wrap up sections of what's
 already in `wp-settings.php`
 * Hooks those new functions into the new actions in `wp-settings.php`

 ----

 '''Why do we do this?'''

 As more robust and sophisticated plugins, themes, APIs, and systems start
 to use, rely on, and bend WordPress to their will, the need to override
 more & more pieces becomes apparent. While WordPress comes with a very
 handy set of default post types, taxonomies, APIs, helpers, wrappers, and
 tools, it may be desirable to unhook (or never load) certain pieces so
 that other pieces can take their place.

 In the past, this is done only with great intent, with strategic actions &
 filters in places where specific needs are being addressed. This is good
 in that it's predictable, but bad in that it's impossible for anyone to
 truly know what action or hook is *best* to perform any given subsequent
 action.

 By breaking `wp-settings.php` up into many clearly named `do_action()`
 calls, it becomes clearly obvious what actions perform what duties, while
 also introducing literally maximum flexibility in the entire system for
 new and exciting things to happen around WordPress itself.

 Imagine something like:


 {{{
 // Load versions
 do_action( 'wp_settings_load_versions' );

 // Load constants
 do_action( 'wp_settings_load_constants' );

 // Load translations
 do_action( 'wp_settings_load_translations' );

 // Load environment
 do_action( 'wp_settings_load_environment' );

 // Load early WordPress settings
 do_action( 'wp_settings_load_early' );

 // Load database
 do_action( 'wp_settings_load_database' );

 // and on, and on...
 }}}

 ----

 '''Epilogue'''

 This is a huge idea, easily scoffed at, and introduces code-churn like
 whoa. It would mean doubling down on WordPress's actions API, trusting it
 implicitly to load all of WordPress's core pieces & parts. It would open
 many doors to many unforeseen oddities while developers start dissecting
 all the ways things are tied together. It would also enable really cool
 external tools, like REST API drop-ins that can `SHORTINIT` WordPress if
 auth is missing, or WP CLI commands that can `die()` literally anywhere in
 the stack after they've done what they need to do.

 This is something I've wanted in WordPress since 2006 having seen similar
 in other libraries, and even old BackPress & bbPress gave nods and hints
 to back in the day.

 I'm also happy to give this a first patch if it's helpful to see visually
 the destruction it causes, or guide someone else along my vision for this
 if someone is willing and able to see it through before I am. <3

--

Comment (by johnjamesjacoby):

 I used the incorrect formatting for the code block.

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