Workshop Security HTTPS

Not so much about the physical security of the workshop, which is of course important, but about the protocol change I have made to the website. Hyper Text Transfer Protocol Secure (HTTPS) is the secure version of HTTP, the protocol over which data is sent between your browser and the website that you are connected to. Google have for some time been promoting the use of HTTPS and give securely connected sites higher ranking.

The first thing you need is an SSL certificate, this has the encryption keys for the Secure Socket Layer communication setup. Fortunately even the cheapest 1&1 hosting package includes a basic SSL certificate and all I had to do to implement it was to activate it from the 1&1 control panel. The basic certificate is fine for a simple website but if you are implementing a world wide trading empire you will need to pay for something a bit more advanced.

That was the easy bit, getting the website in order is a little more tricky. To start with any internal links need either to be relative or non protocol specific that is they should look like //journeymans-workshop.uk/etc and not http//journeymans-workshop.uk/etc. Once this is done the website .htaccess file needs to redirect any calls to HTTPS this is so that all the old links scattered about the interweb end up in the right place. There are several different ways to do this and I just copied the code from the Apache site, the script conventions for these files is way outside my comfort zone! If you need to do this the code that needs to be added looks like this:-
<ifmodule mod_rewrite.c>
RewriteEngine on
# Begin Force HTTPS
RewriteCond %{HTTPS} !=on
RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI} [R,L]
# End Force HTTPS
</ifmodule>

What you should see in your browser
Browser View

With that done the next major job is to update the WordPress database so that the media links are right. WordPress stores all the links to photos as complete hyperlinks including the HTTP bit so these need changing. The easiest way to do this is with a plugin. I used Better Search Replace which is fairly simple to use and does a dry run before it alters the database. The image to the right shows the browser result when everything works but I put it in to test that the new images are stored with the correct protocol – it seems to work!

Next job is to sort out Google, as you can see I use their ads on the site and it just about pays for the hosting and domain fees. I had to re-write the XML sitemap with the new HTTPS addresses but also had to add the HTTPS version as a new site? I only have one set of files but for reasons best known to themselves Google want each version of the site shown separately. So you end up with:-
https://journeymans-workshop.uk/
https://www.journeymans-workshop.uk/
http://journeymans-workshop.uk/
http://www.journeymans-workshop.uk/
Which strikes me as a little odd but it seems to be what they want. Once this is done sit back and wait for Google to crawl everything. It is fairly difficult to check if all is working correctly and you need to keep clearing the browser cache to make sure you are looking at the latest version. Touch wood everything seems to be working. It is interesting to note the number of old links stored on the web, I was going to remove my old cign.org and cign.net sites but there are still loads of places that have these recorded.

Did I really need to do this – probably not but I learned a bit on the way and in theory my Google ranking should go up for what it′s worth.

Just a quick update, a few months after doing this I checked Google and there was absolutely nothing happening on any of the “sites” other than the https://journeymans-workshop.uk/ so I deleted the other three. Whether this was the right thing to do remains to be seen but I thought it was neater.

Fighting Apache

Not I hasten to add a passing Native American but the server software that empowers a good deal of the interweb. Well the new site has been up for a couple of weeks with no major problems detected. I have however had some trouble trying to implement some of the Google Page Insight suggestions to improve the site speed and efficiency. This is mainly aimed at getting the site in a suitable state to use Google Adsense. As you can see I have put ads on the site and the main hope is that these will generate enough income to pay for the hosting. I don’t anticipate much in the way of posh cars or exotic hoidays!

Cache Control

One of the things suggested is to “Leverage Caching”, what they mean is turn caching on. A bit of reading explains that pages cached locally by your browser make for quicker loading times. Unless told otherwise a browser like Firefox or Chrome will download the page and it’s content fresh every time you want to view it. If you set a few commands in your Apache .htaccess file you can tell browsers to save things locally and use them on subsequent visits to the page. There are a couple of different commands to do this one being Mod_Expires, which basically tells the browser how long to keep a file before downloading a fresh copy The other being Mod_Headers which does a similar job but with more options. I am a complete novice in this area and had to read a lot before I got a rough idea what to do. I think I have things set up with some fairly short term cache directives at the moment until I have finished playing with the site.

Whilst setting directives with the .htaccess file is OK for static files – images, css, script files and the like, it will not work for the php files which are of course generated dynamically. To affect caching for these files I discovered that you need to put a header directive at the top of each file that looks something like < ?php header('Cache-Control: max-age=604800'); ?> which must be the very first line on the page. This tells Apache to send HTML headers that allow caching for up to 7 days. In case you were wondering HTML headers are nothing to do with the page that appears in your browser window, they are rather part of the interchange that goes on transparently between your browser and the server (something else I learnt).

Compression
Script
Editing .htaccess in Notepad++

Having got caching sorted the next thing Google suggested was compressing pages using GZIP. Apparently all modern browsers are set up to ask for compressed pages, it’s in those HTML headers. The browser asks the server to send a page and says oh if you have it Gzipped I am quite happy to accept that, thankyou. Apache dutifully replies and if it can, squeezes the page before it goes, thus reducing the amount of data flying over the interweb. By this time I am an expert on rewriting the .htaccess file and duly add some Mod_Deflate instructions that are the standard way of telling Apache to GZIP everything it outputs. A quick test and… Nothing and definitely not ZIP. More reading and it transpires that my hosting company, 1 and 1, do not enable Mod_Deflate on their servers. Scratch head and send e-mail to Tech Support who reply quickly and apologetically saying I can use Zlib. Lots more reading.

Zlib is part of PHP and has, in my view, very poor documentation. Eventually I found out how to enable it using a php.ini file and switched it on. A quick check with Firefox Element Inspector showed that it was working. A more detailed look showed that it was working but the caching headers seemed to have switched themselves off. Now I am confused (it doesn’t take much), looking at Google Page Insights also showed I was getting 404 (page not found) errors, now I am really confused. Turn compression (Zlib) off and everything is working again. I did a few tests just to make sure I wasn’t seeing things but with Zlib on pages, except the home page, were still being served OK but with a 404 response and with the wrong HTML headers. I turned Zlib off and e-mailed Tech Support again, this time they seem to have headed for the hills! A couple of days reading, most of which was way over my head, I found one comment in the PHP documentation that suggested there was some vague bug where if you called Zlib with its standard zlib.output_compression = on it could corrupt headers but if you enabled zlib with a buffer size zlib.output_compression = 4096 it would work. I tried this without much hope but to my surprise it seems to have worked. I now have HTML headers with cache control set, Gzipped output for PHP and no 404 errors. Result!. I still need to sort out compressing CSS and JS but these files are already minified so they are not going to get much smaller.

Security

Whilst fighting Apache’s .htaccess I thought it would be a good idea to add some of the WordPress recommended security fixes. This meant playing with Mod_Rewrite. Now I have used this before and never understood it. as far as I can see Mod_Rewrite uses a language that is entirely written in punctuation marks and makes no sense whatsoever. I therefore resort to the time honoured method of finding something similar on the interweb and tweaking it until it works or explodes completely. This isn’t the best approach as Mod_Rewrite is very powerful and a slight error could have a myriad of unseen consequences. At this moment in time I seem fortuitously to have hit the right buttons. There are many articles regarding WordPress security so I wont go into detail save suggesting An article in Smashing Magazine and the WordPress Codex.

There is still a slight problem with Google having some spurious links recorded but I think these came about when I was in the process of changing the domain name and I had three seperate domain names all pointing at the same site. Not a good idea, hopefully the duff links will drop off soon. I have no doubt that there are still some gremlins lurking in the works somewhere but they will eventually be tamed as per the Apache.

New Look for Journeyman’s Workshop

The New Look Front Page
The New Look Front Page

If you have visited before, you will have noticed that the website has undergone a bit of a radical redesign. The old cign.org and journeymans-workshop.uk addresses have been relegated and the new address journeymans-workshop.uk is working for the whole site. No information has been lost during the changeover, well at least I don’t think I’ve lost anything and all the original pages and articles still exist. I have no doubt that there are some errors here and there with the CSS but I will track them down eventually. It is a bit tricky as the CSS is shared by both the static bit of the site and the WordPress bit.

The theme for WordPress is all my own work, alright I admit to using the Underscores starter theme but the rest is all mine! It has taken quite a few weeks to get everything working fairly smoothly, even though I am not using any of the complicated bits of WordPress. Knitting a static site and a blog together is not easy when the little grey cells are not used to thinking code.

The new layout is responsive and should work on phone, tablet, laptop or big screen desktop. Unfortunately to get the old pages to work they needed a bit of tweaking which took quite some time but all is now complete. Some of the original images look a bit small but changing those will take much longer! I have also made a switch from standard HTML pages to PHP which made the integration with WordPress a little easier.

Enjoy the new.

Here At Last

Grumpy Old ManWell the CIGN Workshop blog is up and running. It’s only taken me 3 years to get here! My excuse is that I had to find out how to integrate WordPress into the rest of the website and at my age things get forgotten quicker than they get learnt. Now of course the problem is to find engineering type things to blog about. I may of course just have the occasional grumpy old man moment. Please feel free to join in, no no not just the grumpy bit, all comments and ideas are welcome. Any general comments about the site, model engineering or anything else for that matter can be added to this post. If you would like to post something a little longer, contact me either here or there is an e-mail link off the home page menu. Cheers John