WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 5 years ago

#9444 closed defect (bug) (wontfix)

Allow to read wp-config.php without loading WP

Reported by: hakre Owned by:
Milestone: Priority: normal
Severity: normal Version: 2.7.1
Component: General Keywords: has-patch tested commit dev-feedback
Focuses: Cc:

Description

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

Attachments (1)

9444.diff (417 bytes) - added by Denis-de-Bernardy 5 years ago.
add a means to stop the wp_settings.php file on its first line

Download all attachments as: .zip

Change History (22)

comment:1 ryan5 years ago

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

comment:2 ryan5 years ago

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

comment:3 hakre5 years ago

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-Bernardy5 years ago

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

comment:4 Denis-de-Bernardy5 years ago

  • Keywords has-patch tested 2nd-opinion added

comment:5 Denis-de-Bernardy5 years ago

  • Keywords dev-feedback added; 2nd-opinion removed
  • Milestone changed from Unassigned to 2.8

comment:6 follow-up: Denis-de-Bernardy5 years ago

Use as follows:

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

comment:7 follow-up: DD325 years ago

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.

comment:8 Denis-de-Bernardy5 years ago

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.

comment:9 DD325 years ago

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

comment:10 Denis-de-Bernardy5 years ago

  • Summary changed from Problem: wp-admin/load-scripts.php can not use User-Configuration to Allow to read wp-config.php without loading WP

Changing the title accordingly.

comment:11 in reply to: ↑ 7 ; follow-up: hakre5 years ago

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

comment:12 in reply to: ↑ 6 hakre5 years ago

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; 

comment:13 Denis-de-Bernardy5 years ago

Yawn. Can you update the patch? ;-)

comment:14 in reply to: ↑ 11 ; follow-up: DD325 years ago

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.

comment:15 hakre5 years ago

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.

comment:16 in reply to: ↑ 14 hakre5 years ago

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

comment:17 DD325 years ago

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

comment:18 Denis-de-Bernardy5 years ago

  • Keywords commit added

commit? wontfix?

comment:19 follow-up: westi5 years ago

  • Milestone 2.8 deleted
  • Resolution set to wontfix
  • Status changed from new to closed

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.

comment:20 in reply to: ↑ 19 ; follow-up: hakre5 years ago

  • Milestone set to 2.8
  • Resolution wontfix deleted
  • Status changed from closed to reopened

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.

comment:21 in reply to: ↑ 20 azaozz5 years ago

  • Milestone 2.8 deleted
  • Resolution set to wontfix
  • Status changed from reopened to closed

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.

Note: See TracTickets for help on using tickets.