Allow to read wp-config.php without loading WP

[hakre]

Normaly WordPress is configured by it's configuration file. It contains a bare minimum of configuration values and there are a lot of additional configuration values that help to properly use WordPress.

One compontent of WordPress, namely the load-scripts.php file, does not reflect these settings.

Because wp-config.php (the configuration file) includes wp-settings.php which bootstraps nearly the whole wordpress frontend, seperation is hard to achieve.

it should be vice-versa. wp-config.php should contain the config values (as it is) and that file should be included. if additional includes should be needed by the main program flow, those can be included afterwards. there is no need that the config file includes further program code.

this should not be so hard to achieve because there because as far as I've seen there is only one place where wp-settings.php is actually included (wp-load.php).

removing the include command from wp-settings.php and putting it into wp-load.php directly after the include of wp-settings.php should create the base to include wp-settings.php in other files like wp-admin/load-scripts.php.

load-scripts.php can then reflect the setting of configuration constants like SCRIPT_DEBUG

We would already be doing that if not for the fact that every existing wp-config.php requires wp-settings.php. wp-config.php is not part of the WP distribution and is not overwritten when upgrading.

Related: #6938

Also, there are lots of plugins and external integrations that require wp-config.php expecting it to load everything.

Plugins and External Integrations: Those can update theirself if they want to incorportate the new codebase. This can (and must) not be the key argument for a new version release (but good to have that in mind anyway).

The first point, that the file is not overwritten, is a key-point to solve the issue. Because when making such changes, this is really a point, every user needs to know when upgrading. Gladly it is not the first time. The secret-keys in settings for example are a good example, that it is possible to teach the users out there in the wild that they need take over their old values into a new settings raster.

Maybe this should be tagged with "architectural-changes"?

add a means to stop the wp_settings.php file on its first line

Use as follows:

define('WP_CONFIG_ONLY', true);
include '/path/to/wp-config.php';
// do stuff

What functionalities in the script loader requires wp-config.php to be loaded?

Plugins are not loaded for the script loader(Well.. nothing database related is), Its designed for core-usage only.

It would still be convenient to have this around, though. I've lost count of the number of times where I'd have needed to fetch the db config without loading WP in its entirety. :-)

I added dev-feedback because I vaguely recall a conversation about adding such a define in the wp-settings.php file in 2006 or 2007. I can't recall if it never moved forward from lack of a patch of from a very good reason. Maybe a core dev might.

It would still be convenient to have this around, though. I've lost count of the number of times where I'd have needed to fetch the db config without loading WP in its entirety. :-)

I do agree there, But still.. the title/tickets a bit misleading in that case..

In the end, The constant isnt really needed, If your plugin requires it, You need to get the user to update their config file.. You'd do the same if you needed them to add it :) (Mind you, Many plugins still call wp-config directly.. :()

Changing the title accordingly.

Replying to DD32:

What functionalities in the script loader requires wp-config.php to be loaded?
[...] Its designed for core-usage only.

"Functionalities" are the configuration variables. script loader (wp-admin/load-scripts.php) is using a library (wp-includes/script-loader.php) that reads configuration variables (for example SCRIPT_DEBUG, but others as well) that you normally set in wp-config.php (see function wp_default_scripts() in there).

Replying to Denis-de-Bernardy:

Use as follows:

define('WP_CONFIG_ONLY', true);
include '/path/to/wp-config.php';
// do stuff

simple and snatch - love that patch!

tests went out very well!. maybe adding a comment there and giving an <example> on how to use?

one thing that comes into my mind is, that while in this request, wp-config.php will not loaded any longer. so degrading to a global variable might be more flexible then using a constant.

/**
 * wp-settings.php is auto-loaded when the wp-config.php
 * is included.
 * defining WP_CONFIG_ONLY prevents that.
 */
if ( defined('WP_CONFIG_ONLY') ) return; 

Yawn. Can you update the patch? ;-)

Replying to hakre:

"Functionalities" are the configuration variables. script loader (wp-admin/load-scripts.php) is using a library (wp-includes/script-loader.php) that reads configuration variables (for example SCRIPT_DEBUG, but others as well) that you normally set in wp-config.php (see function wp_default_scripts() in there).

Thats all i needed to know :)

Its a good thing for the time-being, But i think we also need to encourage people who use >2.7 to remove the require from the wp-config.php file, the sooner thatsdone, the sooner plugins will change to stop using t, the sooner the constant wont even be needed.

Partly realted: #9461 I stumbeled over it while working on this ticket.

@denis: getting tired. let's wait for some core-dev-feedback on this.

Replying to DD32:

Its a good thing for the time-being, But i think we also need to encourage people who use >2.7 to remove the require from the wp-config.php file, the sooner thatsdone, the sooner plugins will change to stop using t, the sooner the constant wont even be needed.

as far as I see, this is not possible, isn't it? i commented the include and wordpress does not find core functions any longer (get_option here in admin e.g.).

as far as I see, this is not possible, isn't it? i commented the include and wordpress does not find core functions any longer (get_option here in admin e.g.).

Argh. I could've sworn that was changed with the addition of wp-load :(

commit? wontfix?

As Ryan wrote lots of plugins rely on wp-config.php pulling in WordPress as do external integrations.

If you want to create something that just contains the config data for use is an external codebase then just dump your config in a seperate php file which gets included by wp-config.php and just include that from your external app.

does load-scripts.php now handle javascript related constants (e.g. SCRIPT_DEBUG in wp-config.php) properly in trunk?

@westi: the feedback given by ryan: the suggested implementation does not hinder those. all third party code should work as expected afterwards. and it is not about having me something but for core functionality upfront.

Replying to hakre:

does load-scripts.php now handle javascript related constants (e.g. SCRIPT_DEBUG in wp-config.php) properly in trunk?

load-scripts.php is only used when scripts are concatenated, i.e. SCRIPT_DEBUG is not set.