WordPress.org

Make WordPress Core

Opened 7 months ago

Last modified 7 days ago

#49440 new feature request

Allow configuring the upgrade directory

Reported by: natesymer Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: Upgrade/Install Keywords:
Focuses: administration, performance Cc:

Description

wp-content/upgrade is not application code, and it's not data. WordPress shouldn't hardcode where this directory is (especially to a location under the webroot).

Instead, the upgrade directory should be user-configurable & transient. This would allow things to continue as they are - but if someone wants to host their WordPress on a slow disk (HDD, NFS), they could.

The problem is when you have a slow disk, updates can fail because of HTTP timeouts. For example, an NFS volume containing a wordpress install is mounted in the webroot. Moving files across a network to unzip them is insane! It would make so much more sense to use a location like /tmp, which is already optimized for such a use case as unzipping files. Often, /tmp is a tempfs, which actually lives in memory.

Change History (6)

This ticket was mentioned in Slack in #core-auto-updates by pbiron. View the logs.


8 days ago

This ticket was mentioned in Slack in #hosting-community by pbiron. View the logs.


8 days ago

#3 @pbiron
8 days ago

Related: #50797

This ticket was mentioned in Slack in #hosting-community by crixu. View the logs.


7 days ago

This ticket was mentioned in Slack in #hosting-community by jadonn. View the logs.


7 days ago

#6 @wpe_bdurette
7 days ago

At WP Engine we lock down most of the filesystem outside of the webroot (though /tmp is available). This makes me worry a little bit about the customer experience of sites migrating onto our platform that have settings/code to override this directory to a path that's not usable on our system. For this not to cause breakage, we would have to override that setting with a value that works on our platform. This isn't a problem per se, but having some lead time what filter needs to be put in place ahead of a rollout so that we can pre-deploy such a filter in an mu-plugin would be appreciated and reduce customer pain.

Also, the security implications of allowing writes to /tmp for this purpose are interesting from the perspective of shared hosting. If the subpaths under /tmp are fixed/guessable, then this opens the possibility of two tenants attempting to write in the same location concurrently. This could cause undefined behavior in the innocent case or open up a vector for malicious actors to inject malicious code into updates, resulting in that code being injected into all tenants using the same path. Again, not a problem if hosting companies pre-deploy filters for customer-specific paths with sufficient entropy, but common default implementations could leave sites vulnerable.

Note: See TracTickets for help on using tickets.