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!
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 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.
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 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).
The Windows Azure Store is available as part of the Windows Azure Management Portal, a convenient resource for all of your Windows Azure needs, which can be accessed from a variety of Devices including your favorite iDevice, Surface, Windows Phone, Mac or PC.
At the time of writing, the Windows Azure Store is currently only available in the US.
Click on the + New in the Windows Azure Management Portal Taskbar, then select STORE.
The Store opens in a modal dialogue, either scroll down or filter to APP SERVICES to find ClearDB MySQL Database, then click the [next] arrow.
Select an appropriate database size (or stay with the Free plan and upgrade later once the site is live) and select the Subscription to charge. Provide a name for the Database (can be left with the default, a name will be assigned for automatically), select the region to provision the database in (whenever possible, try to provision the Web Site and database in the same region to avoid latency). Click the [next] arrow.
After the Add-on has been provisioned, click on the Connection Info button in the Taskbar.
Copy the connection string for use in your application. Alternatively, a newly created database can be added as a Linked Resource to an existing Windows Azure Web Site, the credentials will be surfaced under the connection string section of the CONFIGURE tab.
A while back I wrote a blog post on Enabling PHP 5.4 in Windows Azure Web Sites, when we enabled the ability to bring-you-own-runtime to Windows Azure Web Sites. This is still a valid solution if you would like to manage your own PHP.ini file, or if you would like to ensure that you are using a specific build of PHP.
It’s exciting to announce that Windows Azure Web Sites now has PHP 5.4 ready to be enabled in your Web Sites.
Even though PHP 5.4 is available PHP 5.3 is still enabled by default.
Enable Native PHP 5.4 in Windows Azure Web Sites
After Creating a Windows Azure Web Site, navigate into the Web Site details page and select the CONFIGURE tab. Under the framework section you will see PHP VERSION, select the box containing 5.4, it will turn purple notifying that there is an unsaved change.
At the bottom of the browser viewport you will find the TASK DRAWER, which would have changed to include a SAVE button. Click the SAVE button to enable PHP 5.4 for your Windows Azure Web Site.
Once the change has been saved, you’ll be greeted by this nice little success notice.
Finally, you will also notice that the purple indicator has now changed back to blue on the PHP 5.4 box.
You are now ready to deploy PHP 5.4 applications to Windows Azure Web Sites.
Recently, I came across someone trying to figure out where their code was deployed between Windows Azure Web Sites and Windows Azure Cloud Services. There are many things that you may want to wrap discovery code around between deploying to Cloud Services and Web Sites. One such example that comes to mind is use of LocalStorage in Cloud Services over writing directly to disk in Web Sites.
Cloud Services also have a way to configure custom Environment Variables in the Service Definition (CSDEF) file which is packaged up with a Cloud Service Package (CSPKG). Considering both Cloud Services and Windows Azure Web Sites enable you to expose Environment Variables this is consistent way to share information in either deployment method.
Configuring Environment Variables in Web Sites Portal
Configuring Environment Variables in Cloud Services
Environment Variable in Action
ASP.NET Example using Web.config
In ASP.NET there is the concept of a web.config file. This is an xml based file which is used for storing configuration settings which are specific to a deployment. It is easy to pivot on environment by providing transforms of the web.config file. Let’s assume we have 3 environments Local, WebSites and CloudService.
This will yield three configuration transforms which upon build will roll up to the base web.config:
Creating an App Setting
An App Setting is a Key/Value pair configured in the <appsettings /> element within the web.config file.
Application Configuration File
We’ll set this appsettings to a value appropriate for debugging.
We will provide a replacement element for the appsettings for our local test environment.
We will provide a replacement element for the appsettings for Windows Azure Web Sites.
We will provide a replacement element for the appsettings for a Windows Azure Cloud Service.
AppSetting in Action
Depending on your development language or your scenario [as the Environment Variable route would work for ASP.NET as well] you can quickly and easily setup a way to verify which Environment you are deployed to be it Local Test, Windows Azure Web Sites,Windows Azure Cloud Services or any other environment you may have.
Much like many other developers, I like to live on the bleeding edge, learning new language features, using the latest tools so naturally one of the things I wanted to see in Windows Azure Web Sites is support for PHP 5.4. I’m pleased to be telling you today in this post that support for Bring-Your-Own-Runtime is now available in Windows Azure Web Sites.
Out of the box, Windows Azure Web Sites supports PHP 5.3 as you can see from the snapshot of the portal below. In this article I’ll explain how to enable PHP 5.4 in Windows Azure Web Sites.
Configure PHP 5.4 Handler Mapping in Web Sites
In order to enable support for PHP 5.4 in your Windows Azure Web Site, you will first need to create a Web Site.
I’ve created my Windows Azure Web Site, What’s Next?
To bring you up to speed, I’ve created a Web Site using Quick Create, using configphp54 as the dns prefix for my Web Site.
Click on the Name of the Web Site [in my case configphp54] to proceed to the Details page for your site. On the details page you will see top level navigation items [DASHBOARD, MONITOR, CONFIGURE, SCALE, LINKED RESOURCES] listed. Click on DASHBOARD.
In order to be able to deploy files to the site, we’ll need to create some deployment credentials, you can create [or reset] your deployment credentials from the quick glance section of the DASHBOARD.
Click on create [or reset] deployment credentials to be prompted with a dialog box to enter your credentials.
Fill out the user name, new password and confirm password to create your deployment credentials or simply the new password and confirm password to reset your password. Now your web site is ready for FTP or Git deployment.
Next, click on CONFIGURE.
At the bottom of the CONFIGURE page you will see a new section called Handler Mappings.
Handler Mappings are a way to map a Fast-CGI script processors to file extensions in IIS. These script processors are typically console applications which means they may be able to accept additional command line switches. To set up a custom handler mapping you are required to set at least 2 of the three values, let’s quickly go into some more details around Extension, Script Processor Path and Additional Arguments.
Extension: This is the file extension which should be mapped to the Script Processor.
Script Processor Path: This is the field which specifies the absolute path to a Script Processor [in our case this will be php-cgi.exe]. The script processor’s binary and configuration files can be located anywhere within the application root directory which can be accessed using the D:\home\site\wwwroot path.
Additional Arguments: If the script processor supports additional command line switches which you may require, you can configure them in the Additional Arguments input box.
We’re only going to fill out the Extension and Script Processor Path to configure PHP 5.4. Enter the following values into the handler mappings section.
After you type each line, click the checkmark at the end of the line to commit the value and add a new row. Clicking on the checkmark does not save the entries, a save button will show up in the command bar at the bottom of the portal.
Script Processor Path
wwwroot is publicly exposed to the internet which could potentially allow remote execution of executable files contained in wwwroot. By default IIS blocks access to the bin directory of any website or virtual directory, which is why it is safe to place the php runtime in the wwwroot/bin directory.
After you are finished, hit the save button that appears in the command bar to commit these settings.
Wait? Where do I get PHP 5.4 for Windows Azure Web Sites?
Before this site will actually work, we need to provide the php54 runtime in the path specified in our handler mappings settings. Download and extract the VC9 x86 Non Thread Safe zip file to the bin directory in your project
Note Your password is the password you typed while creating your deployment credentials above. This password is used for Git or FTP deployment. For WebMatrix, you can use the Publish Profile to load the configuration for a seamless publish experience.
Upload an index.php file which contains a call to phpinfo() to the wwwroot folder.
If you browse to the site you will see that the site is in fact running with the latest version of PHP (5.4.7 at time of writing).
PHP does auto-discovery of the php.ini file by looking in known locations where it is expected to be placed, the first such place it looks is the directory which contains the script processor. This means that you will have access to your own php.ini file.
By Default, the PHP runtime does not have a php.ini file, it is packed with php.ini-development and php.ini-production. Rename php.ini-production to php.ini, open the file and search for fastcgi.logging and remove the preceding semicolon (;) which will uncomment the line fastcgi.logging=0. FastCGI Logging needs to be disabled (0) in the pipeline or it will return a HTTP 500 when you attempt to execute a script.
With Great Power, Comes Great Responsibility
Now that you own the runtime, you essentially own the experience and the security of the application. Be sure to follow the guidance on iis.net Best Practices for Configuring FastCGI and PHP to ensure optimal performance and security.
Windows Azure Web Sites (WAWS) is a highly scalable cloud environment build for speed. Windows Azure Web Sites brings down the barriers of Cloud Deployment allowing you do deploy what you want (Support for ASP.NET, PHP & Node.js), how you want (FTP, Git, TFS, WebDeploy).
In this post I would like to highlight some simple optimizations for running a PHP Web Site within the Windows Azure Web Sites environment.
Strap on your Tool Belt…
There’s nothing a developer likes more than some a few tools to make the job a little easier. Windows Azure has simplified the process of getting the right tools for the job, to take this one step further, we provide installers for our tools for use on Linux, Mac and/or Windows.
You can manage your Windows Azure services all from the comfort of your favorite Command-Line. Visit the Manage downloads page to Get the tools you need. Fast.
In addition to providing Command-Line tools, Windows Azure services can also be managed directly from the Windows Azure Management Portal. The new Windows Azure Management Portal has been completely redesigned in HTML5 which enables it to be used in a variety of devices including Windows Phone and iPad. For Guides on how to navigate the Management Portal specifically related to WAWS, visit the Web Sites page of the Manage Services section on WindowsAzure.com.
Now for Something You’ll Really Enjoy…
In a world that demands instant gratification, performance is paramount, your Web Site needs to be able to deliver in a time of need. Even thought Windows Azure Web Sites has no issues being performing it’s still crucial that we think about optimizing for the best possible result. Luckily the team which built Windows Azure Web Sites has already done an amazing job delivering an environment which follows the Best Practices for running PHP on IIS.
Learning more about the Windows Azure Web Sites Environment
To better understand what is enabled by default in the PHP runtime on Windows Azure Web Sites, create a file called info.php which contains the following:
All of the Server Configuration Information you will need to understand what is capable in Windows Azure Web Sites in the context of PHP.
Installed PHP Modules
MySQL Driver for PHP
Improved MySQL Driver for PHP
Multibyte String [Encoding]
Image Processing and Creation Library
Native Language Support (Globalization & Localization)
Remote Procedure Call
PHP Data Objects for MySQL
PHP Data Objects for SQLite
Mail Server Support [IMAP, POP3, NNTP]
HTML Document Manipulation
Windows Cache [Caches: Opcode, Files, File Paths, User Caching and Session Handling]
MS SQL Server Driver for PHP (includes Windows Azure SQL Database Support)
PHP Data Objects for MS SQL Server
Some of those settings don’t suit my needs, what do I do now?
In the event that some of the settings in the php.ini don’t suit your needs DON’T PANIC.
Every developer will inevitably at some point need to debug some code, it’s just a fact of life. If you look at the output from phpinfo() you’ll notice that errors are logged, but not displayed in the browser, which would significantly slow down developer productivity. Not to worry, here is a .user.ini file which will help you with debugging your PHP applications.
Note: Remove the [debug] from the file name.
Important Setting for Accepting Content in Windows Azure Web Sites
If you take a look at this post by Maarten Balliauw on Tweaking Windows Azure Web Sites you will see the two files which provide IIS the base configuration applicationhost.config and webroot.config. Maarten was investigating how to turn on additional HTTP Verbs in Windows Azure Web Sites for a Custom WebDav server. Seeing how more and more applications are using REST, it seems fitting that we enable the majority of HTTP Verbs by default so our application can leverage them.
In addition to adding HTTP Verbs, limiting the list of Default Documents that IIS must rotate through will help optimize page load times. With these two optimizations I have started a web.config starting point for PHP applications on Windows Azure Web Sites.
Note: This post reflects the original state of this file, which is hosted on GitHub and may change overtime.
Migrating from Apache to Windows Azure Web Sites
If you are currently running an application Apache Web Server and would like to migrate your application Windows Azure Web Sites it’s completely possible, it’s even possible to translate your .htaccess file content to IIS web.config, or if you have a Windows machine, you can use the IIS Rewrite tool to Import mod_rewrite rules into IIS (then copied from the xml view into your web.config file).