This is the second installment in a series about the design and development behind what is now Pixel & Tonic. Yesterday we looked at the origin of the name and logo, and a bit of the design process. Today I’m going to focus on how the site is structured.

One of the great, horrifying things about ExpressionEngine is that your website’s structure is completely up to you. EE makes no assumptions whatsoever, which makes it a fantastic tool for everything from simple blogs to full-blown portals like iLounge. And the best part is that, should you decide to scale your website into something bigger, you can do it without starting from scratch. Your content is already sitting in non-assuming weblogs / channels / sections / buckets, ready to be presented in any variety of new ways.

This was essentially the story with my previous site. It began as a simple Movable Type-based blog, whose content was a mix of blog posts, portfolio entries, and a couple downloadable goods. Once I started releasing ExpressionEngine add-ons, I attempted to restructure things a bit by applying categories to entries. But it didn’t take long before the site started showing its seams, so in December of 2008 I decided to do the right thing, and migrate to EE.

The migration was simple enough – I used the Movable Type Import Utility to get the content into EE, and then I distributed my entries into separate weblogs: Sites, EE Add-ons, Mint Pepper, Mac Apps, and Posts. I came up with a basic design that only consisted of a homepage and a single entry page, and called it a day. Since then, I’ve revamped the homepage to focus solely on EE add-ons (only giving other content a small home in the global footer), revamped the blog, introduced documentation sections for FieldFrame and Playa, created the Playa in Action page and Fieldtype Showcase, and made a few other iterative enhancements.

URL Routing

While that site is a testament to ExpressionEngine’s malleability, I’ve never been very happy with its structural implementation. A prime example of that is how I’m handling URL routing. I wanted all product URLs to begin at the first URL segment, e.g., http://brandon-kelly.com/playa, rather than http://brandon-kelly.com/ee/playa. I accomplished that using segment conditionals:

{if segment_1 == ""}
   {embed="site/_home"}
{if:else}
   {embed="site/_apps"}
{/if}

In this case, if the site/index template gets called (and thus, the request hasn’t already been routed to an existing template group, like “blog”), I’m assuming that either the homepage or a product of some sort should be displayed.

While this approach works, it’s not ideal, since things like template caching go out the window, not to mention the performance hit from loading and parsing an additional template. So when I set out to make pixelandtonic.com, I decided to try something new.

I started with a simple and straightforward template structure. The “site” group is for the homepage and globally-embedded templates, like the site header and footer. Then there’s an “ee” group for ExpressionEngine add-ons, which includes the templates “index”, “releasenotes”, and “docs”. The ee/index template checks {segment_2} for the add-on’s URL Title, and the other two check {segment_3}.

When you visit an EE add-on’s section on pixelandtonic.com, the first step in URL routing takes place not in a template, but in the site’s .htaccess file:

RewriteRule ^index.php/(playa|wygwam|fieldframe|ffmatrix)(/[^\/]+)?(/.+)?$ /index.php/ee$2/$1/$3 [NC,L]

This little redirect (coupled with a standard index.php redirect) will take an incoming URI like /playa, and turn it into /index.php/ee/playa behind the scenes. Sub-pages like /playa/releasenotes become /index.php/ee/releasenotes/playa. Now, the first template EE loads is also the last (well, besides the site header and footer embeds). No template segment conditionals required!

My only caveat is that it will require manually adding new URL Titles to the regular expression as I introduce new products, but that’s certainly an acceptable tradeoff.

Trailing Slashes

While on the subject of .htaccess redirects, there’s another little tidbit probably worth sharing: how I’m handling trailing slashes in the URI. While EE doesn’t know the difference between URIs like /playa versus /playa/, web analytics apps and search engines may consider these separate web pages. If you’re developing a static website, this isn’t a big deal, because if you attempt to go to the former URI (sans trailing slash), Apache will automatically redirect the client to the latter (with trailing slash).

But for a web application like EE, where everything in the URI after “index.php” is handled by the application rather than Apache, this redirection is left up to you. Just like the decision to use or not use a “www” subdomain, it doesn’t matter whether you choose to force a trailing slash or vise-versa; it just matters that you force one or the other.

I decided to force URIs without trailing slashes, if only because they look a little cleaner, and in this 140-char world, every character counts. Here’s the rewrite rule I’m using to do it:

RewriteCond %{REQUEST_METHOD} !=POST
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.+)/$ /$1 [R=301,L]

If you decide to force URIs with trailing slashes instead, simply change that last line to:

RewriteRule ^(.+[^/])$ /$1/ [R=301,L]

For this redirect to be applied, it must first pass a couple conditions that make sure that this isn’t a POST request, and the URI does not map to an existing file or directory. (They’re the same conditions I’m using for index.php redirection.) The rule must be placed before your index.php rule, since by that point, your request has already been redirected to an existing file (index.php).

SSL

Being that I’m handling payments now, SSL was crucial. But I only wanted it on certain pages (anything in members/, and store/checkout). So after getting my SSL certificate up and running, I set a new redirect in place to force SSL on these pages:

RewriteCond %{ENV:SECURE_REDIRECT} !=on
RewriteRule ^(members|store/checkout) https://%{HTTP_HOST}%{REQUEST_URI} [NC,R=301,L]

Note that %{ENV:SECURE_REDIRECT} is a custom environment variable set by EngineHosting. Due to the way their servers are set up, the normal %{HTTPS} variable doesn’t reflect the actual SSL status of the request. If you’re not on EngineHosting, use %{HTTPS} instead.

Then there was the problem of forcing forms living on SSL pages to also post to SSL pages. (Since most forms on P&T are generated from EE modules which just use the Site URL as the form action’s prefix, this wasn’t as simple as remembering to type “https://”.) For that I wrote a simple plugin that converts all instances of “http://” into “https://”:

function https()
{
	$tagdata = $this->EE->TMPL->tagdata;
	return str_replace('http://', 'https://', $tagdata);
}

Wrapping module form tags with {exp:pt:https} and {/exp:pt:https} then did the trick.

So that covers the initial HTML response, but not the in-page elements (CSS, JS, images). And unfortunately, some browsers make a big fuss when HTML is transferred over SSL, but not the in-page elements.

To force all elements to load over the same protocol the HTML was being sent in, I opened up index.php, and added a couple new global variables:

$assign_to_config['site_url'] = 'http://'.$_SERVER['HTTP_HOST'].'/';
$assign_to_config['global_vars']['site_ssl_url'] = str_replace('http://', 'https://', $assign_to_config['site_url']);
$assign_to_config['global_vars']['site_proto_url'] = ($_SERVER['HTTPS'] == 'on' ? $assign_to_config['global_vars']['site_ssl_url'] : $assign_to_config['site_url']);

Now, {site_url} is being defined right in index.php, {site_ssl_url} will always be the same as {site_url} except with an https:// prefix, and {site_proto_url} is either set to the {site_url} or {site_ssl_url}, depending on whether or not the current request is coming over SSL.

From there, it was just a matter of plugging these new tags in where appropriate. Links to members/* (which would be redirected to https:// anyway) are now created using {site_ssl_url}:

<li><a id="sitenav-signin" href="{site_ssl_url}members/signin">Sign In</a></li>
<li><a id="sitenav-register" href="{site_ssl_url}members/register">Register</a></li>

And page resources are pulled in using {site_proto_url}:

<link rel="stylesheet" type="text/css" href="{site_proto_url}global/styles/pt.css" />

The end result is that pages which don’t require SSL don’t get SSL; links going to pages that should be served with SSL have appropriate href attributes; pages that should be on SSL are forced to be served over SSL as well as their resources, and forms living on those pages will submit over SSL. All bases covered.

And that’s it for today; thanks for tuning in! This series will continue tomorrow with a look into how I’m handling product documentation, so make sure you’re following @pixelandtonic or subscribed to our RSS feed to be notified about that.