These days, everyone needs to have a secure website (one using the https protocol – https://en.wikipedia.org/wiki/HTTPS).
The next major version of Google Chrome will start marking HTTP pages containing forms as “Not Secure.” Is your site ready for this?

There are many reasons we need secure websites. If you have an eCommerce store, it’s critical that payments and details are being encrypted and not just going across the network in plain text. But that’s not the only reason. There are a host of them. It’s all about integrity, privacy and security. Have a look at this Google Post about Why HTTPS Matters. Even simple websites can also benefit from https, as Google is now using the protocol in their ranking algorithm. So even from an SEO point of view, it’s a sensible thing to do.

To achieve the https protocol, your website needs to use an SSL (Secure Sockets Layer) certificate. This protocol is now being phased out by the TLS protocol (Transport Layer Security) but that’s another story…

Basically, these protocols are the standard security technology for establishing an encrypted link between the browser and the server. in the last few years, SSL certificates have become cheaper and now there is a great FREE option that is suitable for most small websites.

Changing to https is not hard. But it is important it’s done correctly. Let’s look at the process.

In my examples, I’m using WordPress as the website CMS. If you use something else, there might well be different methods. I’d have no idea as I only use WordPress for my websites.

SECURITY

SSL protects your communication between your site and its visitors. It encrypts data transferred over the Internet, like form submissions and credit card transactions.

SEO

Google has declared it’s time everyone got SSL, and they are now giving a ranking boost to secure sites. Don’t be left behind. Make sure you get your SEO boost by being secure.

E-COMMERCE

If you are processing any kind of payments through and eCommerce store on your website, SSL is not negotiable. It’s an absolute must to ensure confidence and legality when selling online.

AFFORDABILITY

With the advent of FREE Let’s Encrypt certificates, there are no more excuses. Even paid certificates are getting cheaper. So now that excuse is out of the way, what are you waiting for?

For more information on SSL certificates in general and why you should care, read this excellent post at PixelPrivacy 

Continuing on, we will now look at HOW to install SSL!

STEP 1. Let’s Encrypt Certificate – This is a widely supported, FREE certificate. If you are not a big time eCommerce store, this will likely be good enough for you. Obviously, you need to do your research. Paid certificates can be had for around $150 a year. but here we are only looking at the free option, as it’s so easy to implement. Depending on your hosting company, it can be anything from fully automatic to easy-peasy to implement. Contact your host to find out how to enable that part.

STEP 2. Update the WordPress Address and Site Address URLS under Settings – General. Once you have your certificate installed, you need to change the website urls to use the secure protocol. You must change both the WordPress Address URL and the Site Address URL. These can be found in the General section of the WordPress settings.

STEP 3. Better Search Replace. This is an awesome little plugin that can do a search and replace in the website’s database. This is the most efficient method for finding any instances of mixed content, by finding all instances of http://mydomain.com/ and changing them to https://mydomain.com/ It is quick and you only need to do it once. Then, you can deactivate and delete the plugin.

STEP 4. Force https via .htaccess file. There are several ways to force https, but editing the .htaccess file is the best approach. Forcing the site to be served via https ensures that every page, every visit, people are on an encrypted page. This is good for security and also peace of mind for the end user. There are also technical benefits from forcing the https via the .htaccess file, as it is a more efficient and reliable method than WordPress redirects using PHP. There is also the situation of old http links out in the wild that would not be served via https unless forced. There are also plugins, like Really Simple SSL, which do all of the above steps, and are quite popular, but the way I see it, if you do it the manual way, itâ€s done, and you have no need of the plugin (and we can all do with fewer plugins on our sites). But if you are after a quick method, check it out.

STEP 5. Test the site and look for the padlock on every page. Generally, if you have followed the steps up to now, you will see the padlock on every page of your site. If there are issues, you can use a website like https://www.whynopadlock.com/ to troubleshoot. This website shows you in detail the mixed content or other issues that are causing the padlock not to show.

STEP 6. Update site in Google Analytics and Google Search Console. This is the most complex area, and needs to be done carefully. Google see a protocol change as a site move (see here for a google post on this), so you definitely need to update Google Search Console and Google Analytics. There are numerous guides and discussions around this part of the process. See HERE, HERE and HERE.

If this post doesn’t quite hold you hand enough, or you just want a more detailed overview of the whole process, this post from Cloud Living is awesome.

Also, this excellent post from infront.com goes over the importance of 301 redirects in some detail.

The basic code you need to force https is this:

RewriteEngine On
RewriteCond % off
RewriteRule (.*) https://%% [R=301,L]

Here is a snippet of code courtesy of Brian Hochstein of Hawk’s Design, that goes way past that default snippet. As a precaution, I would recommend talking to your hosting company to make sure this will work on your server. Many hosts seem to have their own preferred code for this process.

# BEGIN Force www & https
# This should be the first rule before other rules
# Redirects example.com and www.example.com to https://www.example.com
# [NC] flag makes it so the url is not case sensitive so example.com will be treated the same as EXamPLe.com
# [R=301,L] flag makes it do a 301 permanent redirect which is recommended


RewriteEngine On
RewriteCond % !^www\. [NC]
RewriteRule ^(.*)$ https://www.%/$1 [R=301,L]

RewriteCond % !on
RewriteRule ^(.*)$ https://%/$1 [R=301,L]

â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"

# BEGIN Redirect to non-www https
# Redirect www to non-www https

RewriteEngine on
RewriteCond % ^www\.(.*) [NC]
RewriteRule ^(.*) http://%1/$1 [R=301,L]

# Redirect http to https
RewriteCond % !on
RewriteRule ^(.*)$ https://%/$1 [R=301,L]

# END Redirect to non-www https

There are literally tens of thousands of WordPress templates out there, both free and paid. Very few stick their head above the crowd. But Avada, from ThemeFusion, is definitely one that does. It is the most sold WordPres theme ever on ThemeForest, and there are many good reasons for that.

I have been using Avada from almost the very start. I think I bought my first copy a few weeks after they launched. I liked the look of it, and I took the plunge. I now use it for virtually all of my sites, including this one. The last time I checked, I think they have sold over 350,000 copies, and it’s still #1 on ThemeForest after 5 years!

Choosing a theme for a new WordPress website is a difficult chore if you are not an experienced WordPress user. It’s hard to know what to try and evaluate. The overall design is important, yet you can (and should be able to) change the design enough to make the site unique anyway, regardless of the theme. No one wants their site to look like the demo site of the template…. More difficult things to evaluate are the back-end tools and admin section and the team behind the product. But these are probably more important than anything else.

What sort of customization options are there, is the admin panel laid out in a user-friendly way? What premium plugins are included? But even more important than this is the support available for the theme , and it’s a very difficult thing to evaluate before you have used it.

Avada absolutely shines in this regard. Made by Theme-Fusion, originally a partnership of an American designer and a Pakistani developer, this company had user support in mind from day one. Many themes get popular and then fall over when their client base is underwhelmed by the support offered. Avada has flourished because the team has both increased and improved the support in sync with the growth of the theme. Apart from the official support ticketing system, there is also the flourishing Avada User Group on Facebook, which currently has over 11,000 members (I am an admin there). In fact, I would go so far as to say that the reason for Avada’s phenomenal success lies almost equally between their great design and functionality, and their carefully considered approach to customer support.

Another thing you have to remember is that Avada is a multi-purpose WordPress theme. There is literally nothing you can’t do with it. But the flipside of this is that it means it’s not a pared back framework like Genesis. It’s designed for WordPress Designers and Consultants, and end users, NOT developers (though I know many developers using it). It’s a kitchen sink of a theme, designed to be able to swing the bat, but that doesn’t mean it’s a bloated mass of code. Quite the opposite. With the latest major release of 5.0, the theme was largely rewritten, and there are many options within the theme to turn off scripts and features you are not using. In the end, the proof of the pudding is load times, and a well configured Avada site loads very fast and scores very well indeed.

Another revolutionary feature that came with the latest release is the complete redevelopment of the built-in page builder, Fusion Builder. It is now a stand-alone plugin, and will shortly be available for use with any theme. This page builder has revolutionized the way I work and has cut my production time dramatically. It’s simply amazing. And Luke and the team never rest on their laurels. They already have an ambitious list of new features to implement, including adding front-end editing to the Fusion Builder.

But time and time again, I come back to the support and documentation. Not just the official website, and the community forum there, or the unbelievably extensive documentation for Avada itself and also the newly released Fusion Builder documentation. It’s the community around this theme that is truly amazing. I have been a member of the Facebook group from the start (I think I was member #7). I have seen it grow, in just over 5 years from a few keen users to over 15,000 people from around the world, developing a great community around the theme. Even if your official support has expired, there is still help to be had, 24 hours a day.

But really, the best reason to buy Avada is that it is an absolutely awesome theme. You can build ANYTHING with it, and the ecosystem and community around it is simply the best. I cannot recommend it enough! Go Avada!

This is a great starting point. Digital imaging capture devices (aka cameras, but also scanners) have a fixed number of pixels they can capture in one image. A Canon EOS 5D MkIII for example can capture an image at 5,760 x 3,840 pixels. If we multiply those together we get 22,118,400 pixels, which reflects that it is a 22 Megapixel camera (22 million pixels).

So before we look at images for the screen, it will be instructive to look quickly at Photoshop’s Image Size Dialog, to see how the resolution (ppi) of an image interacts with the pixel dimensions when printing an image.

As you can see here in the Photoshop Image Size dialog, Figure 1.1, digital image information is presented. The Dimensions section shows the aforementioned pixel dimensions of the image, in this case 3840 x 5760. This dialog can be used in many ways, but what I want you to take note of is the physical dimensions listed (12.8″ x 19.2″). This shows us the physical size of the image if it were to be printed, by taking the number of pixels, and dividing it by the number of pixels per inch. In this example, we have 5760 pixels on the longest length, and if we divide that by 300 (the PPI) we get an image of 19.2 inches.

What this shows us is that print size is simply a result of how tightly we squash together the pixels we have. If we increase the ppi, say to 400, without resampling the image (adding to or removing from the total number of pixels), the document size goes down to 14.4 inches. If we spread the pixels further and reduce the ppi to say 240, it becomes a 24 inch document. This what I mean when I say pixels have no fixed size.

Figure 1.1 (click for larger view)

You might have heard the suggestion that it’s important to save images for web at 72 ppi (or God forbid, dpi). The reasons for this are given as many:

• It reduces the file size – Absolute Rubbish. PPI doesn’t affect file size at all. Compression does.
• That’s what resolution screens are at – You don’t have to match the image ppi with the screen ppi. And besides, most modern monitors are more than 72 ppi anyway.
• It’s the industry standard – This is probably the best argument of the lot, as it is a sort of industry standard. It’s just that it’s an industry standard for no good reason.

Asher @ 72ppi, file size: 18.3kb

Asher @ 300ppi, file size: 18.3kb

Asher @ 1000 ppi, file size: 18.3kb

When you understand that there is no real need for setting the ppi in images destined for the web, resizing becomes a lot simpler. Basically, you resize the image in pixels at the size you want it to display. Did I say simple? Well unfortunately, here we enter a completely different world of pain, that of pixel based web design. But at least you don’t have to worry about ppi ;). If, for instance you had a WordPress or HTML template that you know is 1100 pixels in width and you wanted an image to fill the content area, then around 1100 pixels in width would be a good size. With resizing images for the web, the number of pixels is the only relevant detail. Forget the ppi of the image, and remember it’s website theme, the resolution of the screen and the number of pixels in the image that will determine the size of the presented image on screen (disregarding CSS and Retina and some JavaScript at this point). You could argue that it makes sense to set the ppi to 72 anyway. Fair enough, I suppose. It would give consistency. I only rail against the mistaken belief that it is important to do so. If you use Save for Web in Photoshop, you might find it doing it for you anyway. A quirk of the software is that if you save the image with metadata, it won’t change the ppi (as that’s in the metadata), but if you strip the metadata out when saving (by choosing None), and then open the image in Bridge or Photoshop again, you will see that it’s now set to 72 ppi. I believe this is because the field can’t be empty, and so Save for Web just puts in the default value (which Adobe has set at 72 ppi). I use Photoshop to resize my images, but you can use virtually any decent image editor. You can even do it online with services like http://www.shrinkpictures.com/ and http://www.picresize.com and many others.

Let’s come back to screen resolution, as it majorly affects how big or small we resize our images. One of the biggest difficulties for web designers over the last decade or so was always what size images should be. Web design is a mixture of rendered, flexible elements like text and fixed, pixel based elements like images. Screen resolutions come in all sorts of sizes, but to design a web site with pixel based elements, you have to determine how wide your content area is going to be. There’s no point putting a 2000 px wide image in a webpage if 90% of the population are using screens with a  maximum 1024px resolution. The image is just going to be too big to be seen on the screen. So determining your audience and designing to them was always a big part of the process. It has been changing a lot though in the last decade. You can define image size with CSS or HTML (i..e upload an image that’s 800px wide and tell the browser to display it at 400px wide), and there are also java scripts that can automatically resize an image to fit different screen resolutions and new vector based formats like svg are coming through. But designing for the most common resolution of the day is still a major consideration. The most common resolution today is 1366 x 768 (http://www.w3schools.com/browsers/browsers_display.asp) but with the explosion of different form factors, even that particular resolution has only 34% share. Obviously with responsive templates and the like, a lot of changes are going on in the web design space when it comes to images and how to deal with them. But the most basic part of getting started in this area is understanding that unless you have a technology at play that will repurpose images on the fly, you are best off resizing your images to fit your template and your audience. If you look at the current WordPress templates for example, most have a content container width of around 1100 – 12000px. This is to ensure that the content container will never exceed the resolution of the screen. As less than .5% of all desktop users have resolutions less than 1024px, this is a safe bet. In the next year or two, my guess is we’ll see a jump to 1300px or so, as 1024px resolutions now comprise only 2% of users, while Retina style resolutions are increasing quickly. For years I had a photoblog, and I uploaded photos several times a week. It was my practice to upload images at 800px width if they were landscape oriented, and 650px if they were portrait. At the time, that meant that the images would largely fill the screen of up to 95% of my audience. These days, an 800 px image on 27″ iMac looks rather small. But it would still look pretty good on most laptops and tablets. Retina displays have made things even more complex.

Another complexity I am going to very quickly touch on, is CSS and Javascript. With CSS you can tell an image to fit a certain percentage of the container, and with some javascript (Lightbox and the like) has the ability to dynamically increase or decrease the size of the image depending on the resolution of the screen. I don’t know a whole lot about this side of things, not being too much of a coder, but I can see a time when we just upload a large image and the code helps us display it in all all sorts of sizes, We’re pretty much there already, but not quite. You can also use HTML as I’ve said earlier to display an image at a size other than it’s original size. Trouble with this, is you often get artifacts (jagged lines) and lose quality in the image. You are also downloading a bigger file, only to present it at a smaller size. Responsive templates obviously do this sort of thing today, as images get squished down to fit on a  tablet or  mobile phone. All this sort of dynamic resizing is way beyond the scope of this article, and any knowledge I have, so I invite someone who knows about that side of images for the web to step up and educate us all with a similar article.

Compressing & Resizing images for the web

The recently renamed ‘Export As’ dialog (previously known as Save for Web) in Photoshop is a tool for compressing and resizing images for the web. It outputs to one of four file formats, gif, png and jpg, plus, most recently, svg. Let’s start with the most commonly used format, jpg. This is the best format for continuous tone images for the web. They can be heavily compressed, while still retaining a lot of their detail. As noted before, there are two main things that determine file size – the number of pixels in the image and the compression applied when saving as a jpg. ‘Export As’ is designed to be used on images that are already resized, as it is primarily a compression tool, but even if you load a full size image into it, it will load anyway after warning you it wasn’t designed to do so. You can then resize the image as well, but I prefer to resize the image first using the image size dialog and then compress for web using ‘Export As’.

The basic compression choice comes in the form a slider that you set anywhere from 0 to 100. In the example above, it took a 410.7kb image and reduced it  to only 74.1kb at 50% quality. How much you compress is up to you, but I find the best balance for size and quality to be around the 50 mark. The compression will also depend on the amount of detail in the image (the more detail, the less redundancy is possible). Gif used to be the traditional format for graphics, like logos and such, as they support transparency and a smaller colour palette, but these days png is the default format for those type of files. Png files support transparency, which is very useful in web design, but pngs are a bit large, even out of the ‘Export As’ dialog. That said, there are ways to further reduce the size of pngs, including a great little online tool https://tinypng.com/ which compresses the png file while retaining transparancy. As a basic rule of thumb, use jpgs for photographs on the web and png for graphics. For a much more in-depth look at these formats, check out this excellent  article on sixrevisions.com

This is another huge area, and one that my interests have never taken me to. I’m very interested in digital asset management, but colour management: yawn…. I’ll do my best to not make a fool of myself. In fact, to be safe, I will simply say that when saving images for the web, it is best to ensure they are saved with an sRGB colour profile, as this matches most closely the gamut of a monitor. Adobe RGB has a larger gamut, but images in this colour profile can look very flat and washed out on the web. Most cameras shooting jpgs are set to shoot in sRGB anyway, but if you are shooting RAW, you have to set the profile yourself when the data becomes an image. If you use Save for Web, you can get it to convert to sRGB when saving, which is probably the easiest way to go about it. It can also embed the colour profile as well, for those few browsers that actually check to see if an image has one.

This is a topic close to my heart. (OK, OK, I’m a nerd. Get over it). As I mentioned before, aspect ratio is inherent in the captured image, as it comes from the capture device. If you want a square image, you either have to shoot it with a 1:1 aspect ratio (Hasselblad anyone?) or you need to crop, which is totally different from resizing. Cropping is both resizing and changing the aspect ratio. Cropping is something to keep in mind when shooting. You might know you want a 1:1 shot, and so you compose a certain way in camera as if you were shooting with a 1:1 ratio. Or you can creatively crop after you have taken the image, finding new images in the image by selective cropping (as long as you have plenty of pixels to start with you won’t lose too much quality unless you crop away most of the image, and particularly not if you’re just going to web). Over the course of centuries, we have become used to certain aspect ratios in our two dimensional visual art. Many have their foundation in mathematics, or in that strange place where aesthetics and mathematics meet. The Golden Ratio is a good example of this (this is the “perfect” ratio). The beauty and simplicity of the square is of course another. Digital SLRs create images in a 3:2 ratio (close to the Golden Ratio but not exactly). TVs and computer monitors were commonly in the 4:3 ratio, as are most compact cameras and 16:9 is now a common wide screen ratio. The point of all this is that aspect ratios matter. When you crop, stick to an established aspect ratio than to just crop willy nilly. This is where some web designers, particularly WordPress template designers, could do a lot more work. Images in WordPress is another complex topic, as there are so many other things at play when dealing with templates and columns and forced resizing and WordPress image resizing etc, but personally I think it’s best to stick to a bunch of established aspect ratios so that if you have to crop an image to re-purpose it, you always do it in a consistent manner.

OK, that’s it. I hope you have learned a few things along the way. Thank you for reading. If you dispute anything, please bring it up in the comments. As long as you are reasonably polite, I will reply, and we might all learn something.

• My FREE e-book – How to Prepare images for use on the web
• http://www.w3schools.com/browsers/browsers_display.asp
• http://www.photoshopessentials.com/essentials/the-72-ppi-web-resolution-myth/
• http://en.wikipedia.org/wiki/Display_resolution
• http://www.makeuseof.com/tag/basics-properly-resizing-image-files-photoshop/
• http://computing.artsci.wustl.edu/resize-images-web
• http://www.luminous-landscape.com/tutorials/understanding-series/und_resolution.shtml
• http://www.digitaltrends.com/computing/are-high-resolution-displays-screwing-up-the-web/
• http://www.andrewdaceyphotography.com/articles/dpi/
• http://www.webdesignerdepot.com/2010/02/the-myth-of-dpi/ http://photo.net/learn/resize/
• http://en.wikipedia.org/wiki/Dots_per_inch#DPI_or_PPI_in_digital_image_files
• http://www.lightpreserve.com/info/in041126.htm
• http://sixrevisions.com/web_design/web-designers-guide-to-png-image-format/
• http://www.shrinkpictures.com/tutorials/web-sized-images.php
• http://stackoverflow.com/questions/10610714/jquery-lightbox-plugin-scaling-very-large-images-to-fit-screen
• https://www.stockphotosecrets.com/questions-answers/standard-photo-sizes.html