WordPress on IIS 7 - plugin update problem (35 posts)

  1. cherrythomas
    Posted 5 years ago #


    I've moved my WP blog a IIS machine. Everything is running perfect except one thing - auto-updates for plugins. When I click the auto-update option in the plugins menu WP gives me a message saying:

    Unpacking the update.
    Installing the latest version.
    Deactivating the plugin.
    Removing the old version of the plugin.
    Could not create directory. DIRECTORY\wwwroot/wp-content/plugins/akismet/
    Plugin upgrade Failed.

    And whats even stranger it removes the plugin enteirely and the plugins directory is not even avaiable in Windows Directory.

    Any suggestions how can this be fixed?

  2. benskolnick
    Posted 4 years ago #

    I am having the same issues. Fresh install of Windows Server 2008 SP2 fully patched running IIS7. I used the Microsoft Platform Installer to install PHP MySQL and the wordpress blog. Then I restored a previous blog from backup that I made before I re-insalled the OS to try and fix this issue.

    IIS seems to be caching something because I can updated the plugins if I restart IIS right before I do the upgrade. If the site has been active for a while trying to upgrade the plugins gives me the same error you have above. Checking the directory shows a phatom folder that cannot be taken over or name changed or anything. Cycling IIS will release these resources and the folders completely disappear and then I can install the plugin again.

    It seems like IIS is holding some sort of cache on the plugin resources so when they are deleted by WP IIS doesn't know what to do and just locks those resource names so you cannot finish the update.

    I never ran into this in previous versions of WP but the platform installer also adds other items like cache dependencies so it might not be a WP issue at all and could be some other piece installed by Microsoft that is causing this blockage.

    I have a feeling more people will start running into this and I hope someone out there is listening.


  3. cherrythomas
    Posted 4 years ago #

    I don't think its Web Platfrom Installer issue. I've tried installing WordPress via Web App gallery on my hosting and also a clean install from files downloaded from WP site - the result is exactly the same.

  4. benskolnick
    Posted 4 years ago #

    I think it might have to do with Windows Cache Extension for PHP

    I had a second server running WP 3.0 from an upgrade on 2.9.2 that had no problems. When I did a fresh install of WP 3.0 on the other server it had a few dependencies and one of them was the cache extensions. Now the fresh WP 3.0 has the same issue and my brand new OS box.

    Because IIS is caching the resources the deletion/creation process WP uses fails when it tries to recreate the resources that are still in the cache. Cycling IIS clears this up and the install works.

    I have a feeling a lot of Sites will get hosed because of this when WP releases a 3.0.1 patch if this doesn't get resolved before then. I recommend patching manually or cycling IIS before any patching needs to be done.

  5. benskolnick
    Posted 4 years ago #

    Forgot to mention during the upgrade I also installed the latest FastCGI for IIS and upgraded PHP from 5.2.9 to 5.2.13. I guess it could be possible that one of these other items is causing this behavior but it seems most likely that it has to do with the Cache since I can recreate the problem reliably, as well as remedy it.

  6. david steadson
    Posted 4 years ago #

    I've been encountering the exact same problem and also suspected wincache as the culprit still happening with the wincache 1.1 release from a few days ago :(

  7. ruslany
    Posted 4 years ago #

    Thanks for reporting this. WinCache development team is looking into this and will update this thread with any findings.

  8. cherrythomas
    Posted 4 years ago #

    And how is looking into the issue going on? :)

  9. donraman
    Posted 4 years ago #


    We believe we have a fix for this. We tested this on our end and the problem seems to go away. I would like everyone reporting this problem to test the private bits. Here is the link to private bits:

    If you are using PHP5.2 use the link - http://sourceforge.net/projects/wincache/files/development/wincache-1.1.1-dev-5.2-nts-vc6-x86.exe/download

    If you are using PHP5.3 use the link - http://sourceforge.net/projects/wincache/files/development/wincache-1.1.1-dev-5.3-nts-vc9-x86.exe/download

    MD5 hash for the both the downloads are available at - http://sourceforge.net/projects/wincache/files/development/wincache-1.1-dev-md5.txt/download

    SHA1 hash for both the downloads are available at - http://sourceforge.net/projects/wincache/files/development/wincache-1.1-dev-sha1.txt/download

    I would strongly encourage all of you to try this out and leave the feedback here or email me at [ email redacted ].

    Thanks for helping us in making WINCACHE a better caching solution on Windows.



  10. iDope
    Posted 4 years ago #

    I have just installed wincache 1.1.0630.0 (dev) and I am facing the same problem. The plugin folder doesn't get deleted and then the create folder fails. If you recycle the app pool the plugin folder dissapears, which leads me to beleive that wincache keeps the plugin folder open somehow and does not allow it to be deleted. I never had this problem with php ISAPI.

  11. iDope
    Posted 4 years ago #

    Sorry I meant I upgraded to wincache *1.2.924.0*.

  12. pdoteam
    Posted 4 years ago #

    I think I have this problem on IIS 6.0. I tried upgrading the wincache dll, but I still have a problem. I had to resolve it by not using WinCache.

  13. KerberosX
    Posted 4 years ago #

    I faced this problem too. First I was troubleshooting possible NTFS permission problems. But even when giving full control permission to Everyone on the root of the drive I still had this problem.

    So I started thinking exploring other possible causes. In our setup it was because for some reason WordPress didn't properly detect the (absolute) path to the plugin directory.

    So I used the option in wp-config.php to manually set the path. You can do so with following parameter:
    define( 'WP_PLUGIN_DIR', $_SERVER['DOCUMENT_ROOT'] . 'c:\path\to\your\wp-config\folder' );

  14. KerberosX
    Posted 4 years ago #

    Made a little post on my blog about it: WordPress automatic plugin upgrade on IIS 7 fails

  15. mosco
    Posted 4 years ago #

    Adding the plugin directory to the wp-config doesn't fix the problem

    I think it's due to a wincache bug, see this discussion:

    there's a fix coming up, hopefully in the next version

  16. ruslany
    Posted 4 years ago #

    The version of WinCache 1.2.924.0 had an incomplete fix for this problem. Pleas try the latest development build (version 1.2.1010.0) from here:

    For PHP 5.3 http://sourceforge.net/projects/wincache/files/development/wincache-1.2.0-dev-5.3-nts-vc9-x86.exe/download

    For PHP 5.2 http://sourceforge.net/projects/wincache/files/development/wincache-1.2.0-dev-5.2-nts-vc6-x86.exe/download

  17. pdoteam
    Posted 4 years ago #

    I was still unable to do delete an inactive plugin through the admin side with wincache enabled.

  18. ruslany
    Posted 4 years ago #

    I am able to consistently repro this bug on PHP 5.2. I am not able to reproduce this with PHP 5.3. It looks to me that this is a problem specific to PHP 5.2. Has anybody run into this with PHP 5.3?

  19. zonknz
    Posted 4 years ago #

    Why is anyone granting IIS write permissions to their core wordpress files?

    This is security madness!

    Create a separate FTP only account with write priviliges such that you need to "elevate priviliges", you can do so.

  20. pdoteam
    Posted 4 years ago #

    Zonkz, are you talking about me or someone else? Are the plugins considered core wordpress files? I don't know much about security stuff, so any articles that you think are worth reading, I'd love to hear about.

    ruslany, I have PHP 5.3.1 installed.
    Build Date Nov 19 2009 09:48:59

  21. ruslany
    Posted 4 years ago #

    @pdoteam: are you seeing this bug even with the latest build of WinCache for PHP 5.3 (file version 1.2.1010.0)?

  22. pdoteam
    Posted 4 years ago #

    Yes I tested 1.2.1010.0 yesterday.

  23. ruslany
    Posted 4 years ago #

    You are right, I am able to repro this with PHP 5.3 as well now.

  24. Kip Kniskern
    Posted 4 years ago #

    Just to clarify:
    a) this is an issue with WinCache for PHP
    b) it's not fixed yet
    c) setting the WP App Pool as a separate user does not fix it

    I am running WP 3.0.5 on Windows Server 2008/IIS 7.0 using PHP 5.2. I tried the solution at:
    ..but it didn't work.

    It doesn't appear that upgrading from PHP 5.2 to 5.3 will fix it, either, and I'm not eager to make such a major updgrade to our production blog (I'm much more of a webmaster than a dev) in "hopes" it will work.

    Has anyone been able to get auto updates to work in IIS?

  25. pdoteam
    Posted 4 years ago #

    I have the issue on Windows Server 2003/IIS 6.0, with php 5.3. I had to stop using WinCache.

  26. ruslany
    Posted 4 years ago #

    Note that you do not have to stop using WinCache because of this. Just disable it temporarily while upgrading your plugins and then enable it back.

    The bug is not yet fixed in wincache. The fix turned out to be much more involved than originally anticipated.

  27. mobilejohn
    Posted 4 years ago #

    Hello all, great info here. As far as I know, WinCache has never been used on this box, but I'm still having the issue of not being able to update plugins.

    Win2003 SP2
    IIS 6.0
    PHP 5.2.3
    MySQL 4.1.11-nt
    Wordpress 3.1

    Any ideas on this?

  28. Vaclav Elias
    Posted 4 years ago #

    Hi there,

    I have experienced also the same problem. I am running my wordpress websites on:
    Windows Web Server 2008 R2
    IIS 7.5
    PHP 5.2.17
    MySQL 5.1
    Application Pools (shit, so many options) I have got this one:
    Managed Pipeline Mode: Classic
    Itentity: LocalSystem

    What I did and helped to fix my updates is:
    I checked my plugins folder Security tab and added IUSR and ticked Allow Modify. This helped to install all plugins. My friend set IUSR on a whole wordpress application so he could update also to 3.1 with no problem.

    I cannot recommend this as I don't know if it is safe to use IUSR on these folders. Yes, the IUSR user wasn't automatically installed/added when the wordpress was installed. Should it be there or not? WordPress was working without that, also adding new plugins was working. The only problem was update...

    Can anybody advise if this is safe???

  29. AlphaMouth
    Posted 4 years ago #


    I have a new install of WP on IIS7 like you. I used the Web Platform Installer to deploy both the initial WP/PHP/MySQL install as well as the site.

    The IUSR account was already set with Modify rights on the plugins dir for me. Si I would say it's safe.

    I also have this problem when trying to upgrade both plugins or WP (to 3.1). I'm using the latest WinCache version (Version 1.1.0630.0 Build Date Jun 29 2010 10:58:05). Disabling it do not correct the issue for me for updating WP or plugins.

    This looks like an NTFS permission issue to me but PHP is all new to me too and I'm not sure what permissions are granted through the related services.

    I'm going to use some monitoring tools to see what credentials are trying to write to the wp-content directories during the upgrade. I'll keep you all posted.

  30. iDope
    Posted 4 years ago #

    When is a new version of WinCache that fixes this expected to be out?

Topic Closed

This topic has been closed to new replies.

About this Topic


No tags yet.