Redesign: Lessons learned from migrating to a secure server

14 February 2020 | 8th Edition

To be fair the migration itself went smoothly and was handled very speedily by my hosting company HostingUK.net, so there are no complaints at all there.

However, imagine my disappointemnt on viewing the site after the migration and pretty much everything had broken or wouldn’t work. What had gone wrong? Well there are a few important things to watch out for when switching to a secure set up. It's fair to say that in order to overcome any potential problems you need a certain degree of knowledge to work out why things (might) fail, and more importantly how to fix them, or how to articulate the issue clearly so that someone else can fix them. This might well take a few people out of their comfort zones. So this is a small primer on what went wrong for me and how I fixed it.

Problem #1: htm pages served as php.

The first issue is one based on how this legacy site was set up and has subsequently been developed over the years.

All pages were originally simply htm files, but for added functionality, php code was added in the last major site overhaul back in 2010 to enable content to be injected dynamically (one off site-wide items such as headers, navigation panels, footers, side panels for example). In order for this to work, you need to add a few lines of code to the .htaccess file on the server to tell browsers to parse html files as php files, like this:

AddType application/x-httpd-php5 .php .htm .html

Now this worked fine on the unsecured server but not the secure. None of the php functionality was working as it should have been, all the vital added content was missing. The only thing remaining was the bare-bones content section, in other words, only the htm element.

Despite hours of research, head scratching and multiple edits of the .htaccess file, nothing worked. So I happily handed this over to my hosting company to look at. Eventually they came up with a fix on the server configuration.

But in the meantime, I had already decided that this htm-to-php trick was a bit dirty. I took the plunge and decided to fix this once and for all. I opted to change all file endings to .php and be done with it. With this came the need to change all internal site links too. And this is what I did, problem now fixed.

Problem #2. Javascript not working

Another serious fail that rendered drop down menus and other script-run features totally non-functioning.

As it is this is a fairly simple fix. You need to remember that cannot link to non-secure (http) dependencies from within a secure (https) environment. All links to third-party scripts need to change to https protocol prefixes — hoping of course that that crucial bit of code is available on a secure server. Or failing that, download the script and run it locally on your server, linking to it using relative links. In my case: the fault was linking to a non-secure jquery external source. Doh.

Those were the two major headaches I've encountered thus far — neither of which were mentioned as potential hiccups before the migration. I suppose it could have been a lot worse, but the reality is going https isn't as easy as flicking a switch as many hosting companies make it out to be.

As it was there was six frustratiing days of things not working as they should. Luckily I could eventually figure out and had the necessary confidence to change code where necessary. I do recommend you do your pre-https switchover research more thoroughly than I did.

I hope this is useful for someone.

Ends