WordPress.org

Make WordPress Core

Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#5276 closed enhancement (wontfix)

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

Reported by: mastermind Owned by:
Milestone: Priority: normal
Severity: normal Version: 2.5
Component: General Keywords: wp-config.php standalone
Focuses: Cc:

Description

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.

Change History (17)

comment:1 @mastermind7 years ago

The text

(e.g. an AJAX of a plugin)

is supposed to read:

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

comment:2 @Viper007Bond7 years ago

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

comment:3 @ryan7 years ago

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

comment:4 @Viper007Bond7 years ago

Or even better!

comment:5 @DD327 years ago

-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');

comment:6 @Viper007Bond7 years ago

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

comment:7 @westi7 years ago

relates to #3057

comment:8 @westi7 years ago

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

It doesn't work well for upgrades.

comment:9 @DD327 years ago

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.

comment:10 follow-up: @DD327 years ago

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 ?

comment:11 in reply to: ↑ 10 @mastermind7 years ago

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?

comment:12 follow-up: @DD327 years ago

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.

comment:13 in reply to: ↑ 12 @mastermind7 years ago

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.

comment:14 @Viper007Bond7 years ago

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.

comment:15 @DD327 years ago

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.

comment:16 @jacobsantos7 years ago

  • Milestone 2.9 deleted
  • Resolution set to wontfix
  • Status changed from new to closed
  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.

comment:17 @DD327 years ago

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)

Note: See TracTickets for help on using tickets.