Make WordPress Core

Opened 5 years ago

Last modified 5 years ago

#37646 new enhancement

Make wp-settings.php a series of do_actions() — at Version 1

Reported by: johnjamesjacoby Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: Bootstrap/Load Keywords: 2nd-opinion dev-feedback
Focuses: Cc:

Description (last modified by johnjamesjacoby)

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


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.


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...


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

Change History (1)

#1 @johnjamesjacoby
5 years ago

  • Description modified (diff)

I used the incorrect formatting for the code block.

Note: See TracTickets for help on using tickets.