Switching Travelfish to https: A quick walkthru

We recently switched the Travelfish website over from http to https and it appears to have run very smoothly (touch wood!). As Chris at TravelHappy asked, here is a quick wrap on what I did and a few heads up to potential issues.

Primarily because of moronic telecom companies here in Indonesia (Hello Telkomsel!) who hijack sites which do not use https to inject their own ads and popups into the website. I have written about this previously here – it is an absolutely bottom-feeding parasitical practise, but, currently, is not illegal in Indonesia.

The site
Travelfish is a travel content site of give or take about 25,000 pages. These pages are served via 100 templates (again give or take) and serve around a couple of million impressions per month. It runs off of PHP and MySQL. Pretty bog standard stuff.

While we have a handful of WordPress installations tacked on the side, the vast majority of the CMS is custom.

Some are hosted on the server but most are on S3 with Amazon Cloudfront.

Embedded content
We use Mapbox for almost all of our mapping, and Vimeo for nearly all videos (which are primarily on just the one page). Otherwise there were a few Youtube embeds and so on scattered around the joint.

We don’t run any third party served ads (Google Adsense for example). This made the whole task considerably easier.

The process
I’m not going to bother covering getting an SSL certificate and setting that up, as there are a bazillion tutorials already online about that. In our case it was already set up as we were already using it for login stuff.

Going through the templates
The main headache is “mixed content” where you have a https page that is calling an item (say an image or icon) from a non https source. This mixed content causes browser warnings and, in some cases the page won’t load.

What this meant was that we had to change every single link in the site that pointed to http://www.travelfish.org/ to https://www.travelfish.org. So, there’s no shortcut route here, we needed to go through every template and check that every url was https.

That was a fun day.

At the same time, we had to check that all our support files (javascript, css, icon files, font files etc) were both hosted on https and called by their https address. Same went for third party content like mapping. Not complicated to fix – just tedious.

This was another fun day.

As we make heavy use of templates and PHP functions to generate chunks of standard content, the above was a lot less painful than if it was all vanilla HTML, but, well, your mileage will vary. It all needs to be changed — every bleeding line.

Aside from the tedium, there are a couple of things to watch out that are worth mentioning.

Hardcoded http in 3rd party files
http:// addresses that are hardcoded into Javascript and css files are a hassle. In one notable case, if you’re using Google Sitesearch as we do, there is a problem as the search JS script is hosted with Google (at //www.google.com/afsonline/show_afs_search.js), but the JS file contains a hardcoded http:// reference which creates a mixed content warning

This meant I had to pull down the script, change the http: to https: and host it on our server (as obv I can’t change the code Google is hosting). The downside of this is of course is if Google changes something the script breaks — so far so good 😉

Images at S3
This was one of the main reasons we had delayed the switch to https because of the complexity is getting a SSL certificate that would cover all the images there. To be honest, I still don’t really understand all this, but this explainer at the aptly named Delicious Brains (their blog has lots of interesting stuff too), worked a dream and made all of our images and other stuff secure with a minimum of effort (and zero cost).

Once all the images and all the support files had had their references updated, we moved on to the content.

The database
Plenty of our content in the database (accommodation reviews etc) has links hardcoded into it. Rather than doing search and replace through the database to fix this, we took the more gradual approach of:

a) On the public template pages we replaced the old url with the correct ones as a part of the process of querying the database and formatting the output with PHP.

b) We adjusted our CMS to do the same, so any time we open a record in the CMS any baked in links are updated permanently when the record is saved. Over time, all the records will be updated.

The forum
One issue here was members being able to post images that were hosted elsewhere. The problem was that people may not always post images from a https source so we’d end up with a mixed content warning. We dealt with this by forcing the image to https (again by replacing the url with the PHP str_replace function as in (a) above). What this did was if the image wasn’t hosted on https the image broke — but no mixed content warning. That was preferable result to our mind.

As an aside, if you’re built on WordPress, you’ll want to avail yourself of the following plug-ins to make your life easier. Both should be self explanatory.

Search and replace
SSL Insecure Content Fixer

WordPress’ new image handing with srcset can be an added complicating factor. The easiest approach is to just disable srcset by adding the following to your functions.php file:

function disable_srcset( $sources ) {
return false;
add_filter( ‘wp_calculate_image_srcset’, ‘disable_srcset’ );

Once all this was done, mix yourself a major gin and tonic then:

1) Upload all the files
2) Add a sitewide 301 redirect in the .htaccess file sending all traffic from the http:// to the https:// (this should catch any hardcoded links I missed plus deals with all inbound traffic)

And see what happens.

In our case (SO FAR) it ran smoothly. No noticeable traffic budge (in either direction) and no Webmaster Tools freak out warnings. Note you will need to register the new domain in Webmaster Tools if you want to busy yourself with their beyond pointless 404 reports.

And, that’s a wrap.