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

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

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

Replying to thee17:

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

It's not just you...

Patch re-added.

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.

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

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

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.

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.

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

+1 sounds good to me too!

+1

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

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.

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.

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.

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.

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.

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.

Silence notices while loading wp-config.php?

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.

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.

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.

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

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

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.

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.