By Darshan - 1/22/2020
This was not the post I planned to write. In fact, I had a draft I was about to publish - How to run Wordpress+SSL on AWS Lightsail SSL for Cheap.
But what happened instead was, after a couple weeks of configuring Wordpress, investing in some plugins, and tweaking the deployment process & caching system, I threw it all out the door - I abandoned Wordpress.
We initially chose Wordpress because we assumed it was easy. At my former company, I was often the person saying Why don't we just use Wordpress? And for good reason - having our engineering team spend time on content management and marketing pages just seemed like a waste. With Wordpress's robust ecosystem that had a lot of SEO and social media plugins, most of the needs of our marketing team were handled perfectly.
In the event something catastrophic happened, loading up the previous day's backup wasn't a big deal - there was minimal risk, minimal updating. So generally speaking, Wordpress was a common answer that was often effective.
Therefore, a simple app + lots of content made it seem like Wordpress should be the way to go. I found Amazon Lightsail (AWS's Digital Ocean knockoff) for $3.50/mo and said here we go.
After a couple of weeks of plugging away, the Wordpress site was up. The stack:
That's when things started to go awry.
Here are some of the issues I faced:
SITE_URLdrove me crazy.
If you want SSL for your site, you either need to install the SSL certificates right on the app server directly, or you do so on the load balancer or CDN in front of your app servers.
If you expect any amount of traffic, the general recommendation is the latter choice - you get the benefits of scale with load balancers and CDNs, as well as speed & lower server requirements if you have a full CDN in front.
Our setup was:
Route 53 aliased to Cloudfront -> Cloudfront force upgrade to HTTPS (443) -> App server via HTTP (port 80)
The problem was that Wordpress has a
SITE_URL setting in its
wp-config.php file. When I set it to
https://solitaired.com, it would go into a big redirect loop. Basically, the app server thought we were on HTTP (since it's seeing traffic from port 80) whereas the user wants to go to HTTPS (due to the HTTPS upgrade from Cloudfront). I'll spare you the steps I took to figure this out, but here's the solution:
SITE_URL, use the
httpversion. In our case, this meant we used
Wordpress has a funny way of combining configuration, code, and database data that also includes config settings into one inextricable mass. I don't know if there's a Better Way (tm) to do this, but have fun transferring all the settings and changes you make each time you make changes on local or staging or production.
Suggestions to make life slightly less painful:
This is a screenshot of a settings page of Wordpress's most popular caching plugin, W3 Total Cache.
That's a lot of settings! Once you configure it, have fun figuring out whether something isn't updating because you forgot to upload, your update didn't work, or one of many caching layers is in place. Or maybe you edited a file in production but you overwrote it when you synced your local code with SFTP.
I decided to not use one of these plugins - instead, I set up Cloudfront to use my Origin headers and used the following cache settings in Apache's config (in Bitnami's image it is located at
Q: Why is XYZ not working?
A: I am not sure. Let's check the UI Plugin settings. Nope, everything seems good there. Let's SFTP in and look at
wp-config.php. Looks fine. Maybe it's
.htaccess? Let's look there - oh and let me check the other http conf settings while we're here. No, that's fine too. Ah, maybe it's easier to see in the
You get the point.
To be frank, all of these issues are battles that can be won for those of us with enough grit. But the tedium eventually overcame me and I spent 1.5 days rewriting the entire app in node.js. Now the stack is:
As for the original goals - scalable (check), content management (semi-check), easy to update (check).
The biggest shortcoming is the main core of WP, which is the CMS, doesn't have an analog in Node. But at this point I'll take the simple tradeoff we made to post new pages in Node to being forced to scroll through endless UI config pages, SSH grepping, or database querying to figure out what's going on. The power of Wordpress also turned out to be my biggest frustration.
If you're not worried about modifying your Wordpress app often, or only use WP for solely CMS functionality on one portion of your site, keep going. Wordpress powers 35% of the Web apparently, so maybe I'm just ranting. But the pain feels real.
Now, life isn't perfect. What still seems missing with Node: