Opened 4 months ago
#23269 new enhancement
.maintenance location issue on symlinked install
| Reported by: |
|
Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | Awaiting Review |
| Component: | Upgrade/Install | Version: | 3.5 |
| Severity: | normal | Keywords: | |
| Cc: |
Description
I've started to symlink some of our WordPress installs using a folder structure as follows:
.htaccess
index.php
wp -> /var/www/wordpress/WordPress-latest
wp-config.php
wp-content
The wp folder is a symlink to either the latest version of WordPress, trunk or a specific version and the WordPress core files are all read only by the web server (WordPress core file installs are taken care of by Chef)
I thought creating a .maintenance file in the root or the wp-content folder would trigger maintenance mode but it looks like the .maintenance file is only detected if it lives in the same folder as the WordPress core files ($wp_filesystem->abspath()) which is read only so it's never going to be created there.
Having a shared core codebase even if I did override the write only permissions and set a .maintenance file in the WordPress directory that would mean every single site using that codebase would go into maintenance mode. (which sometimes might be useful since wordpress-latest might need updating)
What about having WordPress look for the .maintenance file in the directory above similar to what we can do with the wp-config.php file? This would then mean with a symlinked install and shared codebase you could trigger .maintenance mode for a single install or all installs using the codebase.
Or relocating the .maintenance file into the wp-content folder. This is after all where most web servers usually have write permission and where created files are meant to go.
