WordPress.org

Make WordPress Core

Opened 8 months ago

Closed 8 months ago

Last modified 8 months ago

#25153 closed defect (bug) (wontfix)

Temporary directory (for installs, updates, etc.) is hard-coded instead of configurable

Reported by: Synetech Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.6
Component: Upgrade/Install Keywords:
Focuses: Cc:

Description

Whenever WordPress installs or updates a theme, plugin, itself, etc. it always puts the temporary files (.zip, extracted, etc.) in the wp-content/upgrade directory.

This is not ideal and it should be configurable. Theoretically it can be changed in at least a few ways (php.ini, WP_TEMP_DIR, etc.), but WordPress seems to ignore all of them and always puts the temp files in there.

I asked about this at the WordPress StackExchange site and it was revealed that this happens because the path is hard-coded.

I can confirm that WordPress does not use the correct/specified temporary directory because the following chunk of code does not display the expected temp directory when run from WordPress:

echo "<br/><br/><br/><br/><hr /><pre style='background-color:#fff;color:#000;'>\n";
echo "<br/>---------- WP_TEMP_DIR       :\t".  WP_TEMP_DIR                ." ---------\n";
echo "<br/>---------- upload_tmp_dir    :\t".  ini_get('upload_tmp_dir')  ." ---------\n";
echo "<br/>---------- sys_get_temp_dir  :\t".  sys_get_temp_dir()         ." ---------\n";
echo "<br/>---------- get_temp_dir      :\t".  get_temp_dir()             ." ---------\n";
echo "<br/>---------- getenv temp       :\t".  getenv('temp')             ." ---------\n";
echo "<br/>---------- getenv tmp        :\t".  getenv('tmp')              ." ---------\n";
echo "<br/>---------- getenv tempdir    :\t".  getenv('TEMPDIR')          ." ---------\n";
echo "<br/>---------- getenv tmpdir     :\t".  getenv('TMPDIR')           ." ---------\n";
echo "</pre><hr /><br/><br/><br/><br/>\n";

Change History (11)

comment:1 toscho8 months ago

  • Cc info@… added

comment:2 nacin8 months ago

get_temp_dir() is used for streaming files or working with images, but WordPress has always used wp-content/upgrade. They were introduced around the same time, in [7058] and [6779].

dd32 would be able to speak to this, but if I had to guess, this has to do with file permissions, and that unzipping to wp-content/upgrade (a folder we create) ensures the files get the right owner?

comment:3 dd328 months ago

WP_TEMP_DIR is used as a temporary writable-by-server location, it's basically area that's "this location is accessable by all users of the server, and as a result, is shared by all PHP scripts on this server".

wp-content/upgrade is hard-coded, only to the extent that it's within the sites WP_CONTENT_DIR folder.

These two differ in that, WP_TEMP_DIR (and get_temp_dir() as a result) is a physical location on disk, (ie. /tmp/) and the upgrades directory is accessed via the filesystem abstraction, which results in it being a FTP location (ie. /public_html/, which is actually /home/dd32/domains/dd32.id.au/public_html)

We save the downloaded zip file to the shared area, for the simple reason that we don't have a reliable method to save it over FTP (and that would be wasteful if we have a writable location on disk).
The reason we extract to the upgrade directory, has no real purpose, it's actually a step that causes some performance issues (it results in twice as much FTP traffic on updates), but, it means that we're quite sure that the Web server is not going to allow other users to alter the files which we've extracted (ie. They won't delete them, or alter them).

Can we change the code to extract to WP_TEMP_DIR and then use those files to overwrite the WordPress files? We completely could, I fear it would have several issues though..

  1. Harder to verify that all the files haven't been modified by another user of a shared host
  2. By the time that we get half way through writing the new WordPress files over FTP, the host may sever the connection - This can happen at present too, but most hosts sever the connection during the initial copy to the upgrades dir, not the following copy from upgrades to the real location. This is a side effect mostly, it's a timeout thing, if a host has a low timeout, we hit it during the start, if we dont hit a timeout there, chances are it's a good configured server that doesn't have a nasty timeout. So this actually results in some safety margins.
  3. I'm not sure if we COULD change it at this stage, since we rely on both the files of version of WordPress being upgraded AND the new version of WordPress's files to perform an upgrade, they have to work in sync with each other, changing this feels so drastic that it might be actually completely impossible.

comment:4 toscho8 months ago

I think, we don’t need to change the current way if it works good enough. But it would be nice, if we could get a little bit more control.
If I set a constant WP_UPGRADE_DIR in my wp-config.php I am responsible for the tests. WordPress could then use this path if the constant is defined or fall back to the current default.

Something like this:

function wp_upgrade_dir() {

	if ( defined( 'WP_UPGRADE_DIR' ) && is_writable( WP_UPGRADE_DIR ) )
		return WP_UPGRADE_DIR;

	return WP_CONTENT_DIR . '/upgrade';
}
Last edited 8 months ago by toscho (previous) (diff)

comment:5 follow-up: dd328 months ago

Perhaps the question that needs to be answered is - What is the purpose of needing to change the directory?

comment:6 toscho8 months ago

Getting rid of the wp-content directory. In most installations I use a separate domain for themes, uploads and (mu-)plugins to save unnecessary cookie headers and to share these directories with multiple installations. The upgrader is only reason to keep an equivalent of wp-content. Not a big deal, I can use the uploads directory for that. But it would be nice to control this without hacks, and it this the last hard coded piece here.

comment:7 follow-up: nacin8 months ago

But it would be nice to control this without hacks, and it this the last hard coded piece here.

I don't think we should support getting rid of the wp-content directory. What if we need it for some future thing? If not making this movable (which, really, there is no reason to do so) also enforces the need for a wp-content directory somewhere, then so be it, I think.

I do wonder, if you're doing all of this, why are you using the upgrader? Why not version control and proper deployment?

comment:8 in reply to: ↑ 7 toscho8 months ago

Replying to nacin:

I don't think we should support getting rid of the wp-content directory. What if we need it for some future thing?

wp-content/libraries? :) Good point, I haven’t thought of that.

I do wonder, if you're doing all of this, why are you using the upgrader? Why not version control and proper deployment?

I am not the maintainer for all the sites I set up, so I try not to create more dependencies.

comment:9 nacin8 months ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

Based on dd32's comment.

comment:10 in reply to: ↑ 5 Synetech8 months ago

Replying to dd32:

Perhaps the question that needs to be answered is - What is the purpose of needing to change the directory?


What ever purpose the user sees fit. If they choose to change the default behavior, then obviously they have a good reason (especially since it requires making a concerted effort to figure out how).

One increasingly common reason is that as portable programs become more popular, putting temporary files on flash-media (when avoidable) is a poor design choice.

comment:11 dd328 months ago

What ever purpose the user sees fit.

And in order to allow for something which fits users expectations, we need to be able to look at it from a distance and cover EVERY users uses.

Based on the above, we have two options for the location of the upgrades folder - ABSPATH, or WP_CONTENT_DIR, because it's limited by users who upgrade via FTP, and limited by existing WordPress code which can't be changed retrospectively. Adding a constant won't allow for the flexibility you expect (Since it'd probably have to be relative to ABSPATH).

putting temporary files on flash-media (when avoidable) is a poor design choice.

This I agree with, but since WordPress is a web application primarily, and portable applications is a extreme edge case, it isn't one we can fully support to match the expectations there.
A Portable application is a good use-case where a 3rd-party versioning and deployment system would be advisable.

Note: See TracTickets for help on using tickets.