.maintenance location issue on symlinked install

[WPsites]

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.

[kirasong]

Hi there!

I'm sorry it took this long for you to get a reply.

I generally like this idea, since it would make it simpler to mark an install as in maintenance mode without disturbing core's directory, and would allow bulk plugin/theme upgrades a better chance of enabling maintenance mode on sites set up in the way you mention.

The trick here is knowing exactly which directories should be checked, since it's also possible that themes or plugins, for example, are pointing elsewhere, in a similar setup to the way you describe core being installed.

@nacin noted in the chat linked above that he suggests we don't change this for the meantime, due to complexity, but we're hoping @dd32 can weigh in.

[dd32]

ABSPATH really seems like the safest option to me.. but in a symlinked install, as noted, it's not ideal.

WP_CONTENT_DIR could be shared with another install, WP_PLUGINS_DIR could be shared, and it could even have a shared themes directory. As much as one might expect that to be rarer than ABSPATH being shared, I suspect it might actually happen more often than expected and may cause unintended side effects for some people.

Multisite also has issues with the .maintenance file as it can take down the entire instance while upgrading a theme active on only one site.

The other option, is that we store a maintenance file alongside the wp-config.php file, as that should be unique per site, or so you would think, but it's also possible to have a single wp-config.php file shared amongst multiple WordPress installs (in subdirectories).

So by this point, you're probably seeing what I'm thinking here, every option has a downside to it.

Another option is that we keep it in ABSPATH, but instead of just writing $upgrading = time() to the file (which I think is what we do) we also write a site-identifying string to it, for example, $site = DB_HOST . DB_NAME . $table_prefix; which we can then check on pageloads that find the file existing. I'm not sure this is a sure-way of doing it either, but it would also open the door to fixing the Multisite issue where we'd just define what's upgrading (core, plugin:akismet/akismet.php, theme:site-specific-theme).

[chriscct7]

No further requests in 2 years, and as @dd32 pointed out in comment:3, there's no good way to solve this. Closing as wontfix