Allow wp-config.php to be used without including wp-settings.php

[mastermind]

The way it is in WP now, wp-blog-header.php includes wp-config.php, and wp-config.php then includes wp-settings.php. This is unfortunate in situations where a script (e.g. an AJAX of a plugin) wants only the database constants, because it needs but a couple of database items. Today, if our mini-script would include wp-config.php, it would load the whole WP core and plugins, execute hooks, open dozens of files, etc.

I'd propose the following: Let wp-blog-header.php load wp-settings.php after loading wp-config.php, and allow wp-config.php to be used standalone.

[mastermind]

The text

(e.g. an AJAX of a plugin)

is supposed to read:

(e.g. an AJAX component of a plugin)

[Viper007Bond]

Big +1 for this. There's been many times where I've had custom written DB powered scripts and have wanted to just use the same config file, but can't due to that include.

There would be some breaking issues with this though (plugins and such that include wp-config.php to "start" WordPress), but we could break those if we give enough notice and do it at a major version (2.4 or 2.5).

[ryan]

Break the definitions out into wp-define.php and include them in wp-config.php.

[Viper007Bond]

Or even better!

[DD32]

-1 to that.

Look at what currently lives within wp-config.php, Defines, A Table prefix(Which i'm supprised isnt defined too, but there'd be reasons for that i'm sure), and then requiring the next file.

What is the point in having wp-config.php if it was split off to wp-defines.php?

I'd say +1 to wp-blog-header.php including wp-settings.php rather than wp-config.php doing so, OR
something like this in wp-config.php

if( !defined('WP_LOAD') || WP_LOAD != false )
     require_once(ABSPATH.'wp-settings.php');

[Viper007Bond]

Yeah, I take back my "Or even better" comment. Kinda defeats the whole purpose of wp-config.php.

A constant would probably be the best way to avoid breaking backwards compatibility, even though it is a tad messy (gotta set var before include).

[westi]

relates to #3057

[westi]

-1 we can't change wp-config.php easily.

It doesn't work well for upgrades.

[DD32]

we can't change wp-config.php easily.

Very true, However, Luckely at present its a require_once statement.

I'll suggest another method, add require_once( dirname(__FILE__) . '/wp-settings.php'); to wp-blog-header.php and remove it from the default sample wp-config.php.

If users still have the line in their wp-config.php, then it'll still work as expected, However, it'll mean that users can make their wp-config.php a stand alone file if a plugin requires it. (Who knows, If it was mentioned in a announcement, come a few releases down the track, it might be safe to assume that its no longer included).

It means it wont be useful in the immediate future, but overtime it'll become available.

[DD32]

Hm, Just noticed removing that line from wp-config breaks other parts of WP.

What should WP be including to kick-start itself? wp-config.php or wp-blog-header.php ?

[mastermind]

Replying to DD32:

What should WP be including to kick-start itself? wp-config.php or wp-blog-header.php ?

wp-blog-header.php makes much more sense. wp-config.php suggests that it only contains configuration data, and in cases like the one outlined in the first note, it's rather unfortunate that one can't cleanly load *only* the configuration.

DD32, could you possibly tell us what you found out about other parts of WP breaking without this line?

[DD32]

DD32, could you possibly tell us what you found out about other parts of WP breaking without this line?

I removed the line, and the login form broke :)

wp-login.php, wp-app.php, wp-atom.php just to name a few kick start WP by including wp-config.php. Once i realised others used it i havnt probed closer as i was after some direction from more seasoned developers.

[mastermind]

Replying to DD32:

wp-login.php, wp-app.php, wp-atom.php just to name a few kick start WP by including wp-config.php. Once i realised others used it i havnt probed closer as i was after some direction from more seasoned developers.

I see. But the cases you mention are then merely a matter of replacing calls to wp-config.php with calls to wp-blog-header.php.

[Viper007Bond]

That may work for internal files, but there are countless plugins and scripts that rely on including wp-config.php to kickstart WordPress. Not saying it'd be a bad thing if we changed it, just saying it'd be a breaker.

[DD32]

But the cases you mention are then merely a matter of replacing calls ...

True, Which was why i was asking which was the intended behaviour to be included.

[jacobsantos]

1. No traction in 8 months.
2. Including everything is the intentional behavior.
3. If you need to get the database contents, then it is easy to parse the wp-config.php file to get the values of the defines.

[DD32]

This was basically achieved when wp-load.php was implemented.

wp-config.php no longer includes the rest of WordPress by default, That being said, If a plugin needs remote access, it really should use the API (ie. admin-post.php, and admin-ajax.php)

[lev0]

WordPress has changed considerably since this ticket was opened, but the problem hasn't. It is currently impossible to include the main config file from one's own or third party code.

Replying to jacobsantos:

No traction in 8 months

I've always found this to be a deficiency in WP, and begrudgingly accepted it. At the time it seemed unfixable. I believe that's no longer the case, and backwards-compatible change is possible.

it is easy to parse the wp-config.php file to get the values of the defines.

This is false. Parsing PHP is non-trivial. Not all defines are simple scalar values. Popular plugins I use/have used stumble over const-style declarations, or redefine constants that already exist. The only reliable method to determine the values is execution, so why make it difficult to do so? What's the benefit to the WP ecosystem in general?

Replying to DD32:

This was basically achieved when wp-load.php was implemented.

Not as far I can tell. All sample and active config files I've seen, including the current source code, boot WP after the "stop editing!" line. wp-load.php mainly finds and loads the config file, or dies. The config file still plays an active role in the boot sequence

I can't see any advantage to do it this way, nothing else in core directly loads the config file. The front- and back-ends both boot through wp-load.php. If one visits the config file URL, WP boots but then gives a WSOD, because neither wp() nor any other code is called after that, so the result is effectively the same as the config file omitting the final require_once.

Is WP really expected to be bootable just by including the config file? All that would do is bypass the error_reporting() and cause a non-graceful failure in the event no config files exist. If so, is it too much to ask the few doing this to instead include the loader, or additionally include the settings file themselves, perhaps in version 7.0?

If I move the regular inclusion of wp-settings.php to the wp-load.php, I find WP operates normally, and is sufficient to 'free' the config. There exist other inclusions of the settings code, in tests, etc., but none that also use the loader.

Allow installations' main config files to used or analysed by external tools, by simple inclusion, without booting WP.

Trac ticket: https://core.trac.wordpress.org/ticket/5276

Could a dev with knowledge of your CI actions confirm whether this was an infra failure? It doesn't look like a failure from the patch, to me, because of all the previous passing checks, and tests within the failed check.