#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.
- It's a little more secure if wp-config.php happens to also be outside the webroot
- 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)
- Removes direct calls to wp-config.php, which allows more control of it's loading through wp-load.php in the future
- 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)
Change History (29)
#3
in reply to:
↑ 2
@
17 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.
#4
in reply to:
↑ 1
@
17 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.
#6
@
17 years ago
Also see #6938, which completes potential for full separation of user content from core files.
#7
follow-up:
↓ 8
@
17 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.
#8
in reply to:
↑ 7
@
17 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.
#9
@
17 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.
#10
@
17 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.
#14
@
16 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.
#15
@
16 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.
#16
@
16 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.
#17
@
16 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.
#18
@
16 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.
#19
@
16 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.
#21
@
16 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.
#22
@
16 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.
#23
@
16 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.
#25
follow-up:
↓ 26
@
16 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' );
#26
in reply to:
↑ 25
@
16 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.
#27
@
16 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.
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.)