WordPress.org

Make WordPress Core

Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#6933 closed enhancement (fixed)

Allow wp-config.php to exist one level up from WordPress root directory

Reported by: sambauers Owned by:
Milestone: 2.6 Priority: normal
Severity: normal Version: 2.5.1
Component: General Keywords: has-patch
Focuses: Cc:

Description

For a while in bbPress we have allowed users to keep their bb-config.php file one level below the root directory. It's helpful for a few reasons.

  1. It's a little more secure if wp-config.php happens to also be outside the webroot
  2. It allows us to add WordPress as an external repository in other projects with a config file that sits outside that external repository (we do this with bbPress a lot)
  3. Removes direct calls to wp-config.php, which allows more control of it's loading through wp-load.php in the future
  4. Removes some duplicate code in some places for detecting wp-config.php

WordPress requires a few more changes to get it to do this as there are a few hard-coded include paths to wp-config.php

This patch adds a new file called wp-load.php in the root which allows the places that statically include wp-config.php to include wp-load.php instead

I'm pretty sure this patch won't break backward compatibility for people who directly include wp-blog-header.php elsewhere either. wp-blog-header.php calls wp-load.php in this patch.

Attachments (2)

allow-config-file-outside-of-webroot.patch (15.4 KB) - added by sambauers 7 years ago.
no_notices_during_config_load.diff (414 bytes) - added by ryan 7 years ago.

Download all attachments as: .zip

Change History (29)

comment:1 follow-up: @DD327 years ago

I'm pretty sure this patch won't break backward compatibility for people who directly include wp-blog-header.php elsewhere either. wp-blog-header.php calls wp-load.php in this patch.

However, You need to keep in mind that most people do not do the correct thing and include wp-blog-header.php, Instead, Most people simply include wp-config.php as it does the job.

Afterall, Half of the WordPress files used to simply do that too. (Regardless of if its the "right" way or not.)

comment:2 follow-up: @thee177 years ago

Is it me or is wp-load.php not in this patch?

comment:3 in reply to: ↑ 2 @sambauers7 years ago

Replying to thee17:

Is it me or is wp-load.php not in this patch?

It's not just you...

Patch re-added.

comment:4 in reply to: ↑ 1 @sambauers7 years ago

Replying to DD32:

However, You need to keep in mind that most people do not do the correct thing and include wp-blog-header.php, Instead, Most people simply include wp-config.php as it does the job.

Well, that will only break where people do move their config file one level up. People doing it "normally" will not be affected.

Afterall, Half of the WordPress files used to simply do that too. (Regardless of if its the "right" way or not.)

It was "right" in those instances to avoid loading everything. This patch removes those.

comment:5 @sambauers7 years ago

  • Keywords has-patch added

comment:6 @sambauers7 years ago

Also see #6938, which completes potential for full separation of user content from core files.

comment:7 follow-up: @westi7 years ago

-1

I am not sure how much benefit this provides for end users.

And doesn't this break any plugins that pull in wp-config.php.

Surely the best solution for the enduser is to just pull in the config settings from another file within the stock wp-config.php instead of specifing them directly.

This is something we could document for the enduser.

comment:8 in reply to: ↑ 7 @sambauers7 years ago

Replying to westi:

I am not sure how much benefit this provides for end users.

It depends on the level of user. If I want to create my own SVN repository of my WordPress install (and at the moment I do) which includes all my plugins and themes and my wp-config, within which there is an external repository containing WordPress, then I can't do it at the moment without keeping local modifications.

People have also asked for the ability to keep configs/plugins outside of the webroot previously.

(I'm combining here into my argument the application of #6938 as well)

And doesn't this break any plugins that pull in wp-config.php.

If they refer to it directly then yes. The fix is to replace inclusion of wp-config.php with wp-load.php. For the small number of people who take advantage of this option, that is a trivial fix, even if the plugin authors don't fix it themselves.

Surely the best solution for the enduser is to just pull in the config settings from another file within the stock wp-config.php instead of specifing them directly.

This still requires keeping a file inside the WordPress root directory, which can't be kept in an a Subversion repository.

comment:9 @sambauers7 years ago

Basically I want to do this... (when this enhancement is combined with #6938)

webroot
 |
 +- .htaccess (for rewrites)
 |
 +- index.php (copied from wordpress/index.php)
 |
 +- wordpress (svn:external)
 |
 +- wp-content
 |    |
 |    +- plugins
 |    |
 |    +- themes
 |
 +- wp-config.php

And throw the lot into my own SVN repository.

comment:10 @mdawaffe7 years ago

+1. Clean checkouts are awesome.

It doesn't cause any problems for anyone who wants to keep wp-config.php where it is.

The only hassle it generates is for the people who do want to move wp-config.php up a directory since some plugins call wp-config.php directly (with varying degrees of success even at the moment, I might add), as has been noted.

comment:11 @war593127 years ago

+1 sounds good to me too!

comment:13 @ryan7 years ago

  • Resolution set to fixed
  • Status changed from new to closed

(In [7971]) Allow wp-config.php to exist one level up from WordPress root directory. Props sambauers. fixes #6933

comment:14 @ryan7 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened
PHP Notice:  Constant ABSPATH already defined in /Applications/MAMP/htdocs/trunk/wp-config.php on line 25

There's not much we can do with existing wp-config.php files, but wp-config-sample.php should have the ABSPATH define removed. Let's also consider removing the require_once of wp-settings.php out of the sample config and into wp-load.php. Since require_once is used, the double include that would be caused by the old wp-config.php files shouldn't hurt.

comment:15 @DD327 years ago

There's not much we can do with existing wp-config.php files,

Why not just wrap the ABSPATH define in a if( ! defined() ) ?

It'll not break for existing users, and will work in future too.

comment:16 @ryan7 years ago

wp-config.php is not part of the WP distribution. People would have to update it themselves. If they're gonna change it they might as well just remove that line.

comment:17 @DD327 years ago

wp-config.php is not part of the WP distribution. People would have to update it themselves. If they're gonna change it they might as well just remove that line.

My bad, I meant wrapping it in wp-load.php

Suddenly having a fatal error occur after a svn up or copying of new files is rather disturbing for some people, esp those who have used the same config for a few versions(..Those people will be missing things in the default config though, like the secret key..) and do not understand PHP.

comment:18 @sambauers7 years ago

The ABSPATH define in wp-load.php comes before the define in wp-config.php so wrapping it in a conditional won't help.

The reason ABSPATH and the include are still at the bottom of conifg.php is to allow backwards compatibility for plugins that might directly include wp-config.php and expect that definition and the loading of WordPress would occur. I think it should be in wp-load.php exclusively too. Subsequent plugin breakage could possibly be assessed, but not known for sure. None of this would help with the problem of old configs needing to be edited like in your situation. They would just have to be edited differently instead.

I agree it isn't nice breaking things for people on SVN up, but the audience using SVN aren't generally the audience who couldn't troubleshoot that error.

comment:19 @DD327 years ago

The ABSPATH define in wp-load.php comes before the define in wp-config.php so wrapping it in a conditional won't help.

'Doh.. I missed that. I admit i didnt pay much attention to the error when i saw it, Just went straight off and fixed it.

comment:20 @ryan7 years ago

Silence notices while loading wp-config.php?

comment:21 @ryan7 years ago

Patches suppresses notices at the top of wp-load.php, before wp-config.php is loaded. wp-settings.php will later adjust error reporting according to WP_DEBUG.

comment:22 @sambauers7 years ago

We've never had a problem in bbPress with having the second define in the config file, but it's been there from the start I think. I think it's only going to be a problem for those transitioning via SVN. Suppressing the error might just stop those people actually fixing their configs. Although less support traffic is a good motivation.

comment:23 @sambauers7 years ago

I guess many people do try to apply old configs when they upgrade the "normal" way.

We recently forced people to build new config files from scratch with bbPress 0.9 without causing too much ruckus.

comment:24 @ryan7 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

(In [8070]) Suppress notices while loading config. fixes #6933 see #7087

comment:25 follow-up: @auirshadow7 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

One problem still exists. If you move wp-config.php out of web root, but also give WordPress it's own directory then technically wp-config.php is now two levels below ABSPATH and WordPress can't find wp-config.php.

I propose adding the following lines to wp-load.php between lines 33 and 34

} elseif ( file_exists( dirname( dirname(ABSPATH) ) . '/wp-config.php' ) ) {

	/** The config file resides two levels below ABSPATH */
	require_once( dirname( dirname(ABSPATH) ) . '/wp-config.php' );

comment:26 in reply to: ↑ 25 @sambauers7 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

Replying to auirshadow:

One problem still exists. If you move wp-config.php out of web root, but also give WordPress it's own directory then technically wp-config.php is now two levels below ABSPATH and WordPress can't find wp-config.php.

The intention is for wp-config.php to be able to exist outside of the WordPress root, not necessarily outside of the webroot.

comment:27 @DD327 years ago

then technically wp-config.php is now two levels below ABSPATH

I could technically put it 3 or 4 levels below root. should WordPress work in those cases too? :)

A solution for that if you're wanting to use that method, Is simply to create the wp-config.php and have it include the real file which is however many levels furthur down.

Note: See TracTickets for help on using tickets.