As promised in a recent announcement, I was going to provide some tips on serving MODX sites over SSL based on my move to a complete SSL-based website. Here they are!

SSL Tip 1: Using protocol insensitive URLs for assets from the get go

You can apply this tip, even if you are not going to be serving anything over SSL soon! If you, like me, point to assets complete with the domain, you will risk serving non-secure content when making the switch. This is easy to prevent by not specifying the protocol, which is the "http" or "https" part.

An example before:

<link rel="shortcut icon" type="image/x-icon" 
href="http://www.markhamstra.com/favicon.png" />

and after:

<link rel="shortcut icon" type="image/x-icon" 
href="//www.markhamstra.com/favicon.png" />

So basically you take a full URL, and instead of specifying "http://" or "https://", you simply specify "//" which will make it relative to the protocol in use.

SSL Tip 2: Generating HTTPS urls with MODX by default

When using the url syntax (like [[~1]]), this is usually relative to the site_url, the default. However it's easy to change this to use any other scheme both on a per case basis, and across the entire site through a system setting.

To change one link, pass &scheme=`https` to the link tag. Wait, you can add properties to link tags too? Yeah! For example, this is completely valid: [[~1? &scheme=`full`]].

To change all links to use https, find the link_tag_scheme system setting and change its value to "https". When not using https, I like to change this setting to "http" so all urls are absolute. All possible values for the &scheme property or link_tag_scheme setting can be found in the makeUrl documentation

Now, there are some Extras that don't neccessarily follow suit here and use their own defaults. Wayfinder, for example, has its own &scheme property you will want to change. And when Wayfinder points to the homepage of a context, it points directly to the contexts' site_url, so make sure that has https as well.

SSL Tip 3: Telling Quip to use secure Gravatar URLs

If you're using Quip for comments (like me!), you will usually use Gravatar for comments which usually serves over http. Luckily, Gravatar does offer a secure link to avatar images but Quip isn't aware of that by default. But it does give you the opportunity to change the link to the gravatar images. This allows you to use a proxy on your own server, or to point to the secure Gravatar url instead! :) This is the &gravatarUrl property. As the secure url for Gravatar is https://secure.gravatar.com/avatar/_MD5_of_email_h..., that's what we set the property to.

Before

  <div class="content topborder">
    <h2>Here's what other Visitors said</h2>
    [[!Quip?
    &thread=`post-[[*context_key]]-[[*id]]`
    &maxDepth=`2`
    &closeAfter=`0`
    &nameField=`name`
    &idPrefix=`comments`
    &tplComment=`mh.comments.tpl`
    &tplComments=`mh.comments.wrapper`
    &useCss=`0`
    &replyResourceId=`39`
    ]]
  </div>  

After

  <div class="content topborder">
    <h2>Here's what other Visitors said</h2>
    [[!Quip?
    &thread=`post-[[*context_key]]-[[*id]]`
    &maxDepth=`2`
    &closeAfter=`0`
    &nameField=`name`
    &idPrefix=`comments`
    &tplComment=`mh.comments.tpl`
    &tplComments=`mh.comments.wrapper`
    &useCss=`0`
    &replyResourceId=`39`
    &gravatarUrl=`https://secure.gravatar.com/avatar/`
    ]]
  </div>  

That concludes this list for now. Do you have any good other ideas? Let me and other readers know in the comments below.

If you are going to serve resources from a subdomain, you might consider making a new system value, perhaps [[++asset_url]]? This also works well if you are going to implement a CDN.

You can serve SSL content on a non-SSL page without an error, so when possible consider deploying sites with SSL on by default (such as Gravatar images).

Two things: Firstly, gravatar email addresses seem to be case sensitive, not much a developer can do about that I don't think.

Also, what is the point of SSL for gravatar images? Why would I want to do that?

If you're using gravatar images on a site served over SSL (which is why I wrote this post), you will definitely need to have gravatar served over SSL as well to prevent getting insecure content warnings.

DOH! Of course...didn't think of it from that angle. Thanks

Comments are closed :(

While I would prefer to keep comments open indefinitely, the amount of spam that old articles attract is becoming a strain to keep up with and I can't always answer questions about ancient blog postings. If you have valuable feedback or important questions, please feel free to get in touch.