Fix for WordPress Plugin Update Issues on Windows Azure Web Sites

Good News!

In a recent service update to Windows Azure Web Sites, the Windows Azure Web Sites team has updated the version of Wincache for PHP 5.3 sites to WinCache 1.3.4, which resolves this issue!

Screen Shot 2013-04-04 at 8.58.48 AM

Screen Shot 2013-04-04 at 8.58.19 AM

A while back I posted an article called Workaround for deleted folder still exists in Windows Azure Web Sites, which talks about how to get around an issue specifically with WordPress plugin upgrading. Recently, on twitter there have been a few people running into this issue, so I thought I would go into a little bit more detail on the issue and how to work around it, permanently.

The Cause of the WP Plugin Issue

In order to dig to the root of the problem, let’s take a few steps back here and get a little bit better of an understanding of the different pieces at play.

PHP

PHP is an interpreted language, simply put it is not compiled into machine code, but instead read and executed step-by-step by an interpreter in this instance, the PHP runtime.

This means that every line would need to be read, interpreted and executed on each request. Which in computer science we understand is not very efficient. For this reason PHP can employ caching to avoid parsing every instruction on each request, instead it stores a certain amount of interpreted instructions in shared memory.

IIS

It’s no secret that Windows Azure Web Sites leverages IIS as it’s Web Server. IIS uses FastCGI to interact with the PHP Interpreter. With the Web Server being able to interact with an interpreter, we have the means to serve up PHP code on IIS. As stated above, PHP can leverage a cache in order to avoid parsing each line of a script, enter WinCache.

WinCache

WinCache is installed and enabled by default for PHP Runtimes maintained by the Windows Azure Web Sites team.

WinCache is a caching system which can be enabled for PHP application which run on Windows  leveraging IIS. This is done by Installing WinCache, then adding a reference to php_wincache.dll from within your php.ini file.

 

By default, Windows Azure Web Sites has PHP 5.3 installed with WinCache 1.1.

Now that we have a better understanding of the different pieces involved, let’s take a closer look at the issue at hand.

There is a bug in WinCache 1.1 [Bug #59352] which causes a lock on a folder which isn’t released until IIS is restarted, which is why this workaround is effective at fixing the issue.

How to Resolve the Plugin Updating Issue

The resolution is fairly simple. The bug has been fixed in a newer release of WinCache (version 1.3 which works with PHP 5.4).

Recently, PHP 5.4 was enabled in Windows Azure Web Sites making the fix as simple as following these steps to Enable PHP 5.4 in Windows Azure Web Sites.

Happy Coding!

  • Pingback: Blog Posting Wordpress Fix for WordPress Plugin Update Issues on Windows Azure Web Sites | Blog Posting Wordpress

  • Paul Patterson

    Whew! Thanks. I was banging my head against the wall trying to figure this one out, and all but give up on running WP in Azure.

    Thanks a bunch for this!

    Cheers,

    Paul

  • Nicholas Petersen

    Unfortunately, the problem still persists, as I posted on this forum:

    I cannot update plugins, on multiple azure websites (as of Nov 24, 2013, and for the last couple months), getting this error:

    Downloading update from https://downloads.wordpress.org/plugin/si-captcha-for-wordpress.zip…

    Unpacking the update…

    Installing the latest version…

    Removing the old version of the plugin…

    Could not copy file. C:/DWASFiles/Sites/mycoolsite/VirtualDirectory0/site/wwwroot/wp-content/plugins/si-captcha-for-wordpress/captcha/backgrounds/1.gif

    Plugin update failed.

    [the copy failed path seems to always be the first file within the first directory it encounters, like the file you see here has 1.gif through 23.gif]

    It furthermore terribly deletes all or most of the contents of the current plugin, which is just really bad. I did not have this problem some months ago. I have tried everything, going back to 3.6 from 3.7 for instance. I have even installed a bran new wordpress site from scratch and immediately tried to update a old plugin, and get the same error. I have changed on the Azure dashpanel version of PHP from 5.3 to 5.5, etc, to no avail.

    So has this problem popped up again? What can be done? I would like to stay on Azure, but this kindof problem threatens the stability of a site. Also, oddly, an installation of wordpress on a separate account in Azure (our business’, these others were mine personally) for some reason doesn’t have this problem, even after upgrading WP to 3.7, etc.