So you want to try installing WordPress on Windows Azure? You want to store your media files in Azure Storage? Good idea. It’s certainly more work than paying a 3rd party to host it for you, but let’s give it a go. First off, let’s set some ground rules. This is not an advanced troubleshooter. This is a guide that helps to clear up some of the confusing parts of the existing documentation for the absolute Azure newb.
The go to guide for setting up WordPress on Azure is located at http://azurephp.interoperabilitybridges.com/articles/how-to-deploy-wordpress-using-the-windows-azure-sdk-for-php-wordpress-scaffold. There’s a few prerequisites so make sure you read the entire document first before getting to work. It’s like a food recipe with a few sub-recipes. Essentially here are the steps flattened into a single list:
- Install PHP
- Install Azure Dev Environment
- Update your PATH to point to the PHP folders
- Setup Windows Azure SDK for PHP
- Create an Azure Hosted Service
- Create an Azure Storage Account
- Setup your SQL Azure DB
- Download WordPress scaffold
- Run the scaffolder
- Create the project
- Package WordPress project
- Deploy to Azure
- Setup your WordPress installation.
- Configure Windows Azure Storage Plugin
Those are the main steps smashed together into one list. However, there can be a few gotchas in going through the documentation.
3. Update your PATH to point to the PHP folders:
I had to do more than what the documentation said. Here are the two locations I needed to add to my path:
C:\Program Files\Windows Azure SDK for PHP\bin
C:\Program Files (x86)\PHP\v5.3
9. Run the scaffolder
Here the directions can confuse. Under the “Parameters” section, “sync_account” and “sync_key” are listed as required for the scaffolder. As far as I can tell, putting the data in here does nothing. You still need to put them in during step 14. So, try leaving it out. I put mine in there, but I don’t think it did any good.
There is one more caveat. The directions say, “NOTE: Inside of this storage account you will need to create a public container called ‘wpsync’“. Unfortunately, the directions do not say HOW to do this. If you are brand new to this, this will keep you hung up for a bit.
What you want to do is download Azure Storage Explorer and install that. Put in your storage account name and the primary access key. Using that tool, create a container called ‘wpsync’. That’s all you need to do in this tool.
That being said, the screenshot provided in the guide shows a different container name in use. So, who knows. Just create the wpsync container. It works.
At this point, I got all the way through step 14. But then, as I tried to upload media to the blog, I got an error that caused a few days of trouble:
The uploaded file could not be moved to E:\sitesroot/wp-content/uploads/2012/04
You can follow the discussion on this problem on the codeplex discussions site: http://phpazure.codeplex.com/discussions/349701
Essentially this problem comes down to permissions on the virtual machine. The recommendation by the guide author is to enable remote desktop on your WebRole and check permissions. I’m not sure you need to do this, which is why I didn’t include it in the steps list above. If you want to, here is a good documention on how to enable remote desktop:
I did this and found a couple things. First, when I reuploaded the deployment package over the top of the existing one, my E drive would be replaced with an F drive. Yet WordPress was still looking to drop temporary files into an E drive. For me, the way around it was to make sure that I deleted and recreated the deployment when updating. This clearly has issues for production instances, so I’m not sure what to recommend in a production setting. If you’re running the recommended 2 instances, simply restarting each instance individually may solve it.
Through that discussion, the recommendation came to update your install-php-impl.cmd file (located at “WordPress\WebRole\bin\install-php-impl.cmd” wherever you ran the scaffolder). Change the line:
CALL icacls ..\wp-content /grant "NETWORK SERVICE":F /T
CALL icacls %RoleRoot% /grant "NETWORK SERVICE":F /T
After redeploying the package with this change, my uploads worked. BE WARNED: I have no idea how this change affects proper security on your instance. Overall, I’m unsure of how the permissions for WordPress need to be set, so don’t complain to me if you end up with a security gap.
If you’re moving a blog from wordpress.com to Azure, you probably want to import your content. I wanted to give this a go and it sort-of worked for me. Here are the steps:
- Download the importer plug-in
- Place it in the plug-ins folder on your machine
- Repackage and redeploy
- Activate the importer in the plug-in folder and give it a go.
My blog isn’t that big yet, so I was surprised when even I had problems importing. Essentially, I think the connection timed out before the import had completely succeeded. I ended up running the importer again and all the content seemed to get moved over the second time. YMMV.
Like this post? Be sure to comment or follow me on Twitter @kenstone