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

[ryan]

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

[ryan]

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

[hakre]

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"?

[Denis-de-Bernardy]

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

[Denis-de-Bernardy]

Use as follows:

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

[DD32]

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.

[Denis-de-Bernardy]

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.

[DD32]

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.. :()

[Denis-de-Bernardy]

Changing the title accordingly.

[hakre]

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

[hakre]

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; 

[Denis-de-Bernardy]

Yawn. Can you update the patch? ;-)

[DD32]

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.

[hakre]

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.

[hakre]

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

[DD32]

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 :(

[Denis-de-Bernardy]

commit? wontfix?

[westi]

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.

[hakre]

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.

[azaozz]

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.

[rpayne7264]

Six years later and it still is not possible to load the database config settings without loading the entire WP installation?? That's ridiculous!! I need to be able to do that so I can push session data into the database during oAuth operations on hosting systems that disallow session variables and cookies, WPEngine in particular. Requiring users to mess with core WP files is a lazy and unacceptable solution.

[jeremyfelt]

Hi @rpayne7264, I think Westi's comment from above still sums this up well:

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.

A common approach for local/staging/production environments is to use wp-config.php to include a local-config.php or other file. The same can be done with a wp-db-config.php file that could be read by your other application when DB access is needed. Another option would be for wp-config.php to bail early if a specific environment was detected.

The history of wp-config.php is so great, it would be hard to justify a refactor of how it is loaded. Even then, we would then be supporting multiple methods to maintain backward compatibility.

[rpayne7264]

That is unacceptable. I am writing plug-ins that deal with oAuth. I can't instruct users of my plug-in to modify/create core php files. And because I am having to call the core wp_load.php file to get access to the database so my plug-in works correctly on WPEngine, it is not being accepted into the plug-in repository.

I have a possible solution that will require loading wp_includes/wp-db.php & wp-includes/option.php so I can get the database access I need. But, I don't know if that will cause another decline of my plug-in being accepted into the repository.

I can use something like the following code to gather the necessary credentials to instantiate an wpdb class and assign it to global variable $wpdb, and then use the WP Transient API, I think.

$array = file("wp-config.php");
$dbArray = array();
$x = array('DB_NAME','DB_USER','DB_PASSWORD','DB_HOST');
foreach ( $array as $line ) {
	$matches=array();
    if (preg_match('/DEFINE\(\'(.*?)\',\s*\'(.*)\'\);/i', $line, $matches)) {
        $name=$matches[1];
        $value=$matches[2];
	if(in_array( $name, $x ))$dbArray[$name]= $value;
    }
}

[jasonhendriks]

Replying to rpayne7264:

That is unacceptable. I am writing plug-ins that deal with oAuth. I can't instruct users of my plug-in to modify/create core php files.

My plugin uses OAuth. May I ask what part of OAuth requires this behaviour? To read/write to the DB outside of WordPress?

​https://wordpress.org/plugins/postman-smtp/

[rpayne7264]

The part of oAuth where I need to maintain state between the token request and the authentication request.

[jasonhendriks]

Replying to rpayne7264:

The part of oAuth where I need to maintain state between the token request and the authentication request.

And you've already stated you can't use store state in the http session. But isn't an alternative as simple as storing the state in the database? Let's say it's Google we're dealing with..

-> User makes permission request to Google. WordPress loads.
.... store 'authenticating mode flag' in db
.... store unique Google state code in db
.... redirect to Google
-> Google redirects back to us. WordPress loads.
.... remove 'authenticating mode flag' from db
.... remove and verify unique Google state code from db
.... retrieve code from http request
.... ask Google to exchange code for auth token
.... store token in DB

WordPress is already running each time we require a load/save of state.. no?

[rpayne7264]

I am storing the state in the database.
I am using a popup window to host the LinkedIn sign-in form.
It then sends a response back to my pop-up form with the id required for a second call to get the access token.
Currently, I am loading Wordpress with my pop-up form so I have access to the DB and Transient API.
But, when I submit my plug-in to the WP repo, they say I shouldn't call core WP files directly.
Session doesn't work on WPEngine.
Cookies don't work on WPEngine.
I am at a loss of how maintain state without loading WP inside my pop-up window and using the DB.
But in fact, I do not like the fact that I have to load the entire WP process. It's overkill.

[jasonhendriks]

I am at a loss of how maintain state without loading WP inside my pop-up window and using the DB.

Admittedly, I'm not doing Javascript authentication. But I can only imagine it would be easier than having to manage all the redirects between servers as I described above. But I'm afraid we've hi-jacked this thread. If you'd like to open a new post on your plugin forum or mine, I'd be happy to help you work out a solution. I don't see any reason to load the WP files directly.

[SergeyBiryukov]

Replying to rpayne7264:

And because I am having to call the core wp_load.php file to get access to the database so my plug-in works correctly on WPEngine, it is not being accepted into the plug-in repository.

There's no need to include wp-load.php directly, you should be able to use a custom query variable to interact with the pop-up: ​http://ottopress.com/2010/dont-include-wp-load-please/.

[rpayne7264]

You are incorrect Sergey. That method does not work well when I am sending off a request to LinkedIn and awaiting a reply from LinkedIn, because the LinkedIn process is out of my control.

[SergeyBiryukov]

If you can control the URL LinkedIn sends reply to, and it currently points to a PHP file that includes wp-load.php directly, you should be able to replace it with something like http://example.com/?my_oauth_plugin, which would open the pop-up with access to WordPress environment.

[rpayne7264]

That's what I am doing. My PHP pop-up loads WP, sends off a request, and then awaits the reply. Closing the pop-up in between the request and the reply, just to open it again with something like ​http://example.com/?my_oauth_plugin, doesn't make a lot of sense.

But the issue still remains: how to store state before I make that first call in the LinkedIn oAuth process flow.

Assume that:
-session variables are not available
-cookies are not available
-intra-site API or web service calls are not available

I have run into all of the above situations.
That leaves only two choices, that I can think of:
1) loading core WP files in one way or another, within my pop-up
2) implement some sort of convoluted JavaScript scheme between the pop-up and the opener

[JPry]

Hey Robert,

If you're using Javascript, then cookies are in fact available on WP Engine's environment. It is only the PHP code that doesn't receive them when caching is in play.

Your Javascript can capture data from a cookie, send it to the WordPress backend using admin-ajax.php, and then interface with WordPress that way. Unless I'm misunderstanding what you're doing, that should be a lot simpler than what you're currently describing.

[rpayne7264]

I am only using JavaScript to open my pop-up form and pass data to it. All of the oAuth stuff uses PHP code.

[scottmas]

It's not elegant, and may potentially break in some future Wordpress release, but it is possible to load just the configuration information without bootstrapping all of Wordpress.

Simply read the config file as a string and get rid of the offending require_once and then eval it.

$configString = file_get_contents('some/path/to/wp-config.php');
$configString = preg_replace('/require_once\(.*?\);/', , $configString);
$configString = str_replace(['<?php', '<?', '?>'], , $configString);
eval($configString);