Plugin upgrades fail after update to WP 3.5

The error seems to indicate a permissions issue, but I haven’t changed permissions. I can upload and activate plugins manually.

I have disabled all plugins, and retried. no luck.
I have switched themes, and retried. no luck.
No messages from debug mode.
No related errors in php53_errors.log

For now, I am stopping just short of redeploying 3.5 from a fresh download.

When WordPress downloads a plugin ZIP file, then it has to be able to write that file somewhere. To do this, it uses the “temp” directory.

If WP detects that it cannot write files to this temp directory, then you get the error message you are now getting. WP tries to find a valid temp directory, but sometimes servers are configured poorly.

You can work around this by specifying a temp directory on your server with a place that you know WordPress is allowed to write files to. You can do this by adding this line of code into the wp-config.php file.

define('WP_TEMP_DIR','/path/to/a/temp/dir');

That will tell WP where to write the temporary files.

Spot on Samuel!
I added this to my wordpress wp-config.php and the problem is resolved.
define('WP_TEMP_DIR','C:\Inetpub\wwwroot\wordpress\tmp');

Now, to figure out what is causing PHP to think it can’t use the same temp directory it was in 3.4? Perhaps this dev ticket will shed some light?

Probably. If the host is configured to have a system defined temp directory that isn’t actually writable, then, well, that sucks.

Yes, the host configuration was performed by Microsoft Web Platform Installer 4.0 on IIS6 (ya, I know) WebPI 4.0 sets the host temp directory by adding these lines to the php.ini out-of-the-box.

[WebPIChanges]
error_log=C:\WINDOWS\temp\php53_errors.log
upload_tmp_dir=C:\WINDOWS\temp
session.save_path=C:\WINDOWS\temp

Might want to warn others using the WebPi. They are either going to have to redefine their temp directory via wp-config.php, php.ini, or give IUSR right to the Windows temp directory (yikes!)

Thanks for help. I will mark resolved later this evening.

I put in a ticket for the problem:
https://core.trac.www.ads-software.com/ticket/22900

Hey, since you have the system with the problem, if you want to test something for me, that might help.

Instead of doing the WP_TEMP_DIR workaround, try this:

In /wp-includes/class-http.php, you’ll find this code around line 145:

if ( ! is_writable( dirname( $r['filename'] ) ) )
	return new WP_Error( 'http_request_failed', __( 'Destination directory for file streaming does not exist or is not writable.' ) );

Try simply removing or commenting out those two lines. Only those two lines, mind you. Then see if the process works without that error and without the WP_TEMP_DIR workaround.

I’m thinking that maybe the process actually can write to the temp directory, but just thinks it can’t. I dunno. I might be wrong.

I wasn’t sure how to unset the WP_TEMP_DIR. Removing the entry didn’t seem to unset it. So I redefined it as
define('WP_TEMP_DIR','C:\Inetpub\wwwroot\wordpress\tmp\notarealdirectory');
This re-introduced the error.
Then I commented out lines 144 and 145 of class-http.php
This yielded a different error.

Download failed. Could not open handle for fopen() to C:\Inetpub\wwwroot\wordpress\tmp\notarealdirectory/bcd-upcoming-posts.tmp

I am back in a working state by reinstating rights to and redefining my new WP_TEMP_DIR.

Just removing the entry will work and unset it (it’s not saved anywhere). You may need to restart the webserver if it caches PHP opcodes.

Setting it to something invalid just will cause it to fail in a different and somewhat meaningless way.

That setting is a forced override, as long as it is there, you can’t test properly.

I have removed the WP_TEMP_DIR entry. Tested both ways. With and without 144 and 145 commented out… plugin installs work both ways.

How can I verify where my WP_TEMP_DIR is actually set?

There is no easy way to verify it, but if you have a test setup, then you can add something like echo get_temp_dir(); to your theme to see what WordPress is using as the temp dir.

Also, thanks for checking this for me! That helps a lot. ??

php echo shows my temp dir is set to
C:\Inetpub\wwwroot\wordpress/wp-content/
for which IUSR has rights.

How to test?

Just to add to this…i’m on a windows box with IIS 7.5 and PHP 5.3.6

Regardless of what I set the php upload_tmp_dir to
get_temp_dir() replys with C:\Windows\TEMP/

(even after restarting IIS)

Runamok81: Thanks for the help. We’ve sort of worked out what the problem is. You can follow the progress on the topic here:
https://core.trac.www.ads-software.com/ticket/22900

A fix will likely be in 3.5.1. The WP_TEMP_DIR workaround will work for now though.

Samuel,
Thanks for the quick fix for my server. I’ll move to 22900 to follow progress.
-Troy