Wordpress TLS

Background

I needed to get a Wordpress site working for my side project. The installation process is all fine and dandy, until you want to do the right thing and enforce TLS for your site. I ran in to issues with mixed-content errors. Wordpress was requesting jQuery and some CSS files over the insecure routes to my domain.

Attempted Solutions

I had a redirect block in my nginx configuration, but that did not seem to solve the issue. Somehow these requests circumvented the server level redirection. My guess is that I do not understand that code block as well as I should.

I want to say that there is some issue with PHP templating files, and that the requests in templated files to http://* fail and do not respond to 301 redirection. Things like <img src="http://crap.jpg> just fail? Does that make sense? #ToDo

I also tried changing the “WordPress Address (URL)” setting to https directly. That broke the whole site. Login would not work. To fix this, I had to modify the wordpress database directly. I’m thankful that the DB is intuitively organized. The command might be useful for me later:

update wp_options set option_value="http://www.flowmojo.com" where option_id=1;

ALSO, enabling debug logging in wp-config.php does not work like the internet says it does. I just couldn’t get that to work. #ToDo

Solution

Replace everything in wp-content with https

By this I mean recursively find every reference in the wp-content directory and replace it with https. This is not a great solution, but it is a chance to work on your one-handed bash skill. bash increased to 12

find . -type f -iname "*" -exec sed -i 's/http\:\/\//https:\/\//g' "{}" +;

Use this Wordpress plugin

Really Simple SSL

The impetus for the brute force replacement was the friendly warnings from this plugin. The plugin worked like a charm and I am very thankful to Rogier Lankhorst

Key Article

This was the article that led me to the solution.

Troubleshooting Mixed Content Warnings with HTTPS by Tony Perez

Update

This answer on ServerFault backs up what I thought. Requests in templates for insecure content will just be bounced. The migration path for TLS includes editing templates. In the future, it is best to make template routes request //[resource] to ensure that they use the same protocol from the loading page.