Optimising WordPress for Running in Azure

Now that you have WordPress running in Azure there are a few housekeeping tasks that you may want to look at prior to switching over from your existing site.

Managing Storage

In a previous post we discussed the different types of deployment available in Azure. One thing to be aware of is that storage is managed differently with these and if you decide to scale-out then things change again. If you deploy WordPress in PaaS or a container then scaling is easy but each new web service needs to be able to access both the database and the file repository.

You may have noticed that our instructions on how to deploy WordPress using hybrid containers that we also deployed a storage service. This is what we will be using to store all of those objects so that any web server can access them. Luckily WordPress has a plugin that makes this functionality easy as well. This should be one of the first plugins that you install. No point in having any data saved to the wrong place after all.

Once this is added you need to configure the storage account that it will use. In order to do this you need to create a storage account key, which will be used by the plugin to access the blob storage. Log in to the Azure portal and open the storage account that you want to use. Under Blobs you need to create a new container then go to Access Keys to get one of the API keys. This information can then be put into the plugin configuration. In the WordPress admin go to settings|Microsoft Azure and copy in the name of the storage account and the API key. If the authentication is successful you will then see the container that you created.

Make sure that Azure Storage is then selected as the default upload source and save the settings. At this point you can restore your old site into WordPress. When you do this you will see that all of the images are automatically saved in the Azure storage account and when you go to upload a file it will automatically save to the Azure storage account.

Stopping the spam

When we stood up the site it took 4 hours before some spammer noticed that they could use a bot to send spam to the contact form. Luckily email wasn’t configured so no one really got spammed but still it was a lesson that we are running our own WordPress site and need to do some things ourselves now. So first up let’s make it harder to spam the contact form. I settled on installing the Contact Form 7 plugin. This has an integration with reCAPTCHA which is a free google service. You will need to sign up for an account at https://google.com/recaptcha whic will give you a site key and secret key. Put these into the Integration page for the contact plugin and then create a new contact form. We simply added the recaptcha to the bottom of the form.

Once you’re happy with the form you can copy the short code for the form directly onto your page. Have a play with it and make sure that it’s working before you fix the email integration. For this we used the WP Mail SMTP plugin. This allows a way to modify the SMTP settings for WordPress. Now WordPress is not an SMTP server so you need to have some external SMTP service that you can use. This plugin supports Google, Mailgun and Sendgrid, but you can also manually specify SMTP server settings. Since we have an Office 365 account we use that. For Office 365 the SMTP host will be your tenant name, which may be different from your domain name with .mail.protection.outlook.com at the end. For some reason the TLS option wasn’t working with Office 365 so we used SMTP on port 25 but enabled the Auto TLS option.

If you want to relay mail outside the organisation then it would be a good idea to set up an account in Office 365 and use authentication. If you don’t want to do this then remember that you will need to set up a receive connector in Exchange Online to authorise the web server to relay based on it’s IP address. If you just want to receive alerts yourself then no changes are required.

Configuring HTTPS

You really need to use HTTPS for your new site. The default site already has a valid SSL certificate but if you want to use a custom name this will require additional work. First you need to set up the custom domain name by going to the app service and opening the custom domain properties. The process for adding a custom name differs depending on whether the site is live or not. If it isn’t then you create a new CNAME pointing to the default Azure name. This is the sitename.azurewebsites.net that was assigned when you first created the site. If the site is already live then you don’t really want to redirect it to the new Azure site just to add the custom domain. You may still have more work to do before you’re ready to go live after all. To cater for this you need to create a txt record in your DNS which has the name awverify with the data containing your sitename.azurewebsites.net. If you want to have a host name for the site (eg www.sitename.com) then you will also need to create a record for this. (eg awverify.www) with the data referring to the Azure site. Once this is done you can upload a public certificate and bind it to the custom domain. If you went down the Windows PaaS route then you can use a Let’s Encrypt extension which will manage acquiring and renewing Let’s Encrypt certificates. This will result in a free cert associated with your custom domain. If you went down the container route then this is a little more difficult. There are solution out there which involves deploying multiple containers. The first container has a nginx reverse proxy which publishes the second container running WordPress. The nginx reverse proxy also has has the Let’s encrypt integration. In the end we went a different way. We use Cloudflare to publish our site. This already has SSL but things get a little funky with WordPress. If we configure the custom domain on CloudFlare but don’t use this name in WordPress then pages will break. If we set both to the same name and require SSL, well don’t do that. WordPress will stop responding. We added another plugin called CloudFlare Flexible SSL. This makes sure that all pages will display correctly to the end user. You then use CloudFlare to control the HTTPS configuration. You can then disable HTTP access from within CloudFlare if this is the route you want to go down.

Oh crap I changed the WordPress settings and now I can’t access my site!!!!

Yeah we’ve been there. Fortunately there is an easy way to fix this. You will need to change the setting on the database to get things back again. You can do this using the Azure cloud shell. Log on to it using the built in mysql command.

mysql -h wordpressdbserver.mysql.database.azure.com -u [email protected] -p

Then convert the site details back to using HTTP.

UPDATE wp_options SET option_value = replace(option_value, 'https://www.sitename.com', 'http://www.sitename.com') WHERE option_name = 'home' OR option_name = 'siteurl';

Reconnect to your site and breath.