WordPress on IIS 7 – plugin update problem

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.

Thanks

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.

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.

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.

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 ??

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

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

Hi,

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 – https://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 – https://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 – https://sourceforge.net/projects/wincache/files/development/wincache-1.1-dev-md5.txt/download

SHA1 hash for both the downloads are available at – https://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.

Regards,

Don.

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.

Sorry I meant I upgraded to wincache *1.2.924.0*.

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.

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' );

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

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:
https://forums.iis.net/t/1169832.aspx

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

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 https://sourceforge.net/projects/wincache/files/development/wincache-1.2.0-dev-5.3-nts-vc9-x86.exe/download

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