[wp-trac] [WordPress Trac] #25153: Temporary directory (for installs, updates, etc.) is hard-coded instead of configurable

[WordPress Trac]

#25153: Temporary directory (for installs, updates, etc.) is hard-coded instead of
configurable
-----------------------------+------------------------------
 Reporter:  Synetech         |       Owner:
     Type:  defect (bug)     |      Status:  new
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  Upgrade/Install  |     Version:  3.6
 Severity:  normal           |  Resolution:
 Keywords:                   |
-----------------------------+------------------------------

Comment (by dd32):

 `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
 1. 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.
 1. 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.

--
Ticket URL: <http://core.trac.wordpress.org/ticket/25153#comment:3>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software