Make WordPress Core

Opened 11 years ago

Closed 8 years ago

#23269 closed enhancement (wontfix)

.maintenance location issue on symlinked install

Reported by: wpsites's profile WPsites Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.5
Component: Upgrade/Install Keywords:
Focuses: Cc:


I've started to symlink some of our WordPress installs using a folder structure as follows:

wp -> /var/www/wordpress/WordPress-latest

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.

Change History (4)

This ticket was mentioned in IRC in #wordpress-dev by DH-Shredder. View the logs.

10 years ago

#2 @kirasong
10 years ago

  • Keywords dev-feedback added

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.

#3 @dd32
10 years ago

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

#4 @chriscct7
8 years ago

  • Keywords dev-feedback removed
  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

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

Note: See TracTickets for help on using tickets.