WordPress.org

Support

Support » How-To and Troubleshooting » Cannot automatically upgrade plugins

Cannot automatically upgrade plugins

Viewing 15 replies - 1 through 15 (of 35 total)
  • Yeah, just in case anyone was wondering–still not working. However, the error message is different since the upgrade to 2.6.2:

    Downloading update from http://downloads.wordpress.org/plugin/user-photo.zip

    Download failed.: Could not create Temporary file

    Installation Failed

    Maybe the problem is just with this particular plugin? I had one plugin that wouldn’t auto upgrade and it was due to an error (since corrected) by the plugin maker.

    I don’t think that’s the case. It has the appearance to suggest a permissions issue, but I’m really just guessing.

    I have kept an old version of a plug-in I’m not actually using around for this (User Photo 0.8.0.2).

    Does anyone have an old version of a plug-in I could test this with, test an auto-upgrade? I don’t keep the old ones.

    If other plugins auto upgrade and one doesn’t, then it is likely a problem with the plugin or the plugin .zip archive.

    I don’t have any others which require an update. I manually updated all the others (because they would not). But I admit that was before moving to .2 at which point the error message changed. As I have no other plugins requiring update I am unable to re-test this theory. I can only say with certainty that prior to upgrading to .2 this problem was effecting all plugins.

    I am having this problem with other plugins not upgrading. I am getting the following errors:

    ——-
    Warning: unlink() has been disabled for security reasons in /home/mishelle/public_html/blog/wp-admin/includes/file.php on line 453

    Warning: unlink() has been disabled for security reasons in /home/mishelle/public_html/blog/wp-admin/includes/file.php on line 453

    Upgrade Plugin

    Downloading update from http://downloads.wordpress.org/plugin/akismet.zip

    Download failed.: Could not create Temporary file

    Installation Failed
    ——-

    This problem was discovered today when I noticed WP-SUPER-CACHE was not writing new files in its cache. WP-CONTENTS folder’s permissions are 755 and .htaccess has the following:

    # BEGIN WordPress
    
    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /blog/
    AddDefaultCharset UTF-8
    RewriteCond %{REQUEST_METHOD} !=POST
    RewriteCond %{QUERY_STRING} !.*s=.*
    RewriteCond %{QUERY_STRING} !.*p=.*
    RewriteCond %{QUERY_STRING} !.*attachment_id=.*
    RewriteCond %{QUERY_STRING} !.*wp-subscription-manager=.*
    RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress|wp-postpass_).*$
    RewriteCond %{HTTP:Accept-Encoding} gzip
    RewriteCond %{DOCUMENT_ROOT}/blog/wp-content/cache/supercache/%{HTTP_HOST}/blog/$1/index.html.gz -f
    RewriteRule ^(.*) /blog/wp-content/cache/supercache/%{HTTP_HOST}/blog/$1/index.html.gz [L]
    
    RewriteCond %{REQUEST_METHOD} !=POST
    RewriteCond %{QUERY_STRING} !.*s=.*
    RewriteCond %{QUERY_STRING} !.*p=.*
    RewriteCond %{QUERY_STRING} !.*attachment_id=.*
    RewriteCond %{QUERY_STRING} !.*wp-subscription-manager=.*
    RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress|wp-postpass_).*$
    RewriteCond %{DOCUMENT_ROOT}/blog/wp-content/cache/supercache/%{HTTP_HOST}/blog/$1/index.html -f
    RewriteRule ^(.*) /blog/wp-content/cache/supercache/%{HTTP_HOST}/blog/$1/index.html [L]
    
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /blog/index.php [L]
    </IfModule>
    
    # END WordPress

    So, no automatic upgrade and no super cache operation because nothing can be written to WP-CONTENTS.

    Any ideas?

    I know what I just did was probably terrible from a security perspective, but I had this problem and I fixed it on a server I’m managing. I changed the permissions of all the directories in the WordPress installation to 0777. It was a bit of a brute force approach and it’d probably be better just to change the permission son the relevant directories (my guess is wp-content?), but the problem definitely seems to be an issue of the web server not having permission to write to the directory where it wants to create the temporary file (wherever that is).

    Hope that helps.

    I tried a bit safer thing – I changed the permissions for wp-content to 777 (with no recursion), and the automatic update created a subdirectory ‘upgrade’ with permissions 775 – so my guess is if you just create the subdirectory ‘upgrade’ with permissions 775 it should work (I’ll test it when I need a new upgrade).

    I tried the 775 approach to the wp-content directory and didn’t have any luck. Still got the same error “Download failed.: Could not create Temporary file”.

    I changed the permissions to 777 to wp-content and the upgrade went fine. When it was done, I reverted back to 755 for the directory.

    There has to be a better way right?

    It worked for me to change wp-content to 777 and then do the upgrade. However, changing it back to 755 after the upgrade folder is created stops it from working again. Had to keep wp-content at 777 until all of the plugins that needed upgrading were changed.

    Is this the way everyone has it or is there a solution?

    I had a similar issue, and the solution was the IIS equivalent of chmoding the wp-content directory to 777. Essentially, I had to give the web user account Modify permissions on the wp-content folder.

    Just thought I’d share a solution.

    Well, I just don’t see myself giving my Internet Guest account modify rights on my WP content folder. That sounds like a train-wreck premonition.

    I tried a number of shallower permissions settings to no avail.

    I’m really annoyed that none of the WP folks have chimed in on this one with some official instructions, because this is now the only way in which plugins can be upgraded using the site itself. That is to say, both links in my blog now bring me to the same end.

    Instead I have to manually search for the new version on the WP site. Can I have the old link back? This is a little stupid: take away the old link when the new upgrade process isn’t working.

    Current error message reads:

    Upgrade Plugin

    Downloading update from http://downloads.wordpress.org/plugin/add-to-any.0.9.8.7.1.zip

    Download failed.: Could not create Temporary file

    Plugin upgrade Failed

    On the matter of CHMOD permissions

    Could I point out that CHMOD does not exist on Windows servers? It is SOLELY a unix/linux permsissions script. If someone is on a HOSTED Windows Server system that runs Plesk, Parallels or another Control Panel, there may be a ‘control’ that says ‘CHMOD’ – BUT that’s not what is happening at the File System/OS level – its a ‘for Unix administrators’ kludge. If you are using an FTP program, you can set permissions all you want to in it, Windows had no idea what you are doing. This is because the two file systems are inherently different, so there is no one-to-one correspondence to be made.

    http://computingtech.blogspot.com/2008/05/windows-server-2008-ntfs-file-and.html

    James is on IIS, and if its his own system – then permissions are set in the MMC snap-in “IIS” which should be on the desktop.

    I’ll be back, with a few answers/look-fors tomorrow on this problem. I have worked on module issues with other cross-platform software. I’m pretty sure this one is because there is no native support on Windows servers for ‘zip’ decompression. I ran into the same thing working on Yabb where restore packages were in Zip format.

    Good Luck all

    Sounds intriguing. I’m looking forward to it.

Viewing 15 replies - 1 through 15 (of 35 total)
  • The topic ‘Cannot automatically upgrade plugins’ is closed to new replies.
Skip to toolbar