Back in my original article WordPress and AWS Elastic Beanstalk – getting set up I discussed how to setup a WordPress website using Elastic Beanstalk. The main advantages being the auto-scaling infrastructure and general coolness of using a lot of AWS infrastructure via an interface. In this follow up article I’ll cover a few of the little hurdles that presented themselves since writing that article and how we overcame them.

Centralising the media library to use S3 rather than the local file system.

We’re using a centralised filesystem already for each of the instances so if the site runs off multiple instances they are referencing the same disk. This is cool and works great until you need to deploy a new version of the application. At this point all the stuff uploaded to wp-content/ is lost and reset back to whatever is in your application zip. So we needed to find a centralised file system and S3 seemed the obvious choice.

After some searching around and testing of plugins, we found S3 Uploads was the perfect fit. Whilst installing it was a little more involved than a normal plugin as it’s not listed in the plugin directory (you need to install using composer), once setup and variables configured in the wp-config.php file, it worked perfectly and we were storing our media library assets in an S3 bucket.

Running the site over HTTPS

All sites need to run over https these days, so we followed the AWS guide for enabling HTTPs on your Elastic Beanstalk environment. This covered the main points, however we then found we had a redirect loop so we had to add the following to our .htaccess file.

SetEnvIfNoCase X-FORWARDED-PROTO “^https$” HTTPS

Source: https://serverfault.com/questions/304621/endless-redirect-loop-with-aws-elb-and-wordpress-site-using-wordpress-https-plug

Carrying out WordPress updates

It’s very important to stay up to date with WordPress updates both for the core application but also the theme and all the plugins you’re using. Updates can’t be run through WordPress admin, they need to be done locally and packaged up in a new version of the application. It’s important the application itself is updated with the latest code so it’s a case of running the updates locally and then re-packaging up new version of the application and re-uploading.

For anything other than a minor change (or when database changes are required) it would probably be wise to create a clone of the current environment within Elastic Beanstalk and run the updates / changes on there. Remembering of course that you’re still probably linked up to the live RDS instance, so you may also want to make a duplicate staging database also to test out updates in advance, before ultimately changing the CNAME record to point at the new Elastic Beanstalk environment. But that’s an article for another day.

How to make changes to the application

The process for making changes to the application is as follows:

  1. Download a copy of the currently running application zip file. This can be found in the Elastic Beanstalk -> Environments screen. Just click the ‘Upload and deploy’ button and it will show you a link to the Applications versions interface where you can download the currently running .zip package from S3. Alternatively you can browse directly to S3 to find it.
  2. Make the necessary changes to the zip file locally and re-package up as a .zip again. It’s important to check the zip file after you’ve created it to make sure you don’t have a top level folder in there. This tripped me up a few times as I was making a zip with a top level folder, rather than the files and subfolders themselves. Just compare the newly created archive with the original one once you’ve made it.
  3. You should then be able to ‘Upload and deploy’ your newly packaged up application via the same interface referenced above (in Elastic Beanstalk -> Environment).