CSS media queries. Good but not great

Initially for me, “adaptive” was all about showing, hiding and manipulating elements using CSS3 media queries for different resolutions. Definitely a step in the right direction. The big problem with this approach alone though is that end users (I’m thinking specifically of smart phone users on slow data connections) still have to download an entire page – including the hidden elements. Doesn’t sound very adaptive to me. We can do better right?

Global variables to the rescue

I use a device detection script to set a global variable of “full” or “mobile”. Try adding the following to your config.php:

global $assign_to_config;
if( ! isset($assign_to_config['global_vars']))
{
	$assign_to_config['global_vars'] = array();
}

$useragent = $_SERVER['HTTP_USER_AGENT']; // Let's do some device detection
if (preg_match('/android.+mobile|avantgo|bada\/|blackberry|blazer|compal|elaine|fennec|hiptop|iemobile|ip(hone|od)|iris|kindle|lge |maemo|midp|mmp|opera m(ob|in)i|palm( os)?|phone|p(ixi|re)\/|plucker|pocket|psp|symbian|treo|up\.(browser|link)|vodafone|wap|windows (ce|phone)|xda|xiino/i',$useragent)||preg_match('/1207|6310|6590|3gso|4thp|50[1-6]i|770s|802s|a wa|abac|ac(er|oo|s\-)|ai(ko|rn)|al(av|ca|co)|amoi|an(ex|ny|yw)|aptu|ar(ch|go)|as(te|us)|attw|au(di|\-m|r |s )|avan|be(ck|ll|nq)|bi(lb|rd)|bl(ac|az)|br(e|v)w|bumb|bw\-(n|u)|c55\/|capi|ccwa|cdm\-|cell|chtm|cldc|cmd\-|co(mp|nd)|craw|da(it|ll|ng)|dbte|dc\-s|devi|dica|dmob|do(c|p)o|ds(12|\-d)|el(49|ai)|em(l2|ul)|er(ic|k0)|esl8|ez([4-7]0|os|wa|ze)|fetc|fly(\-|_)|g1 u|g560|gene|gf\-5|g\-mo|go(\.w|od)|gr(ad|un)|haie|hcit|hd\-(m|p|t)|hei\-|hi(pt|ta)|hp( i|ip)|hs\-c|ht(c(\-| |_|a|g|p|s|t)|tp)|hu(aw|tc)|i\-(20|go|ma)|i230|iac( |\-|\/)|ibro|idea|ig01|ikom|im1k|inno|ipaq|iris|ja(t|v)a|jbro|jemu|jigs|kddi|keji|kgt( |\/)|klon|kpt |kwc\-|kyo(c|k)|le(no|xi)|lg( g|\/(k|l|u)|50|54|e\-|e\/|\-[a-w])|libw|lynx|m1\-w|m3ga|m50\/|ma(te|ui|xo)|mc(01|21|ca)|m\-cr|me(di|rc|ri)|mi(o8|oa|ts)|mmef|mo(01|02|bi|de|do|t(\-| |o|v)|zz)|mt(50|p1|v )|mwbp|mywa|n10[0-2]|n20[2-3]|n30(0|2)|n50(0|2|5)|n7(0(0|1)|10)|ne((c|m)\-|on|tf|wf|wg|wt)|nok(6|i)|nzph|o2im|op(ti|wv)|oran|owg1|p800|pan(a|d|t)|pdxg|pg(13|\-([1-8]|c))|phil|pire|pl(ay|uc)|pn\-2|po(ck|rt|se)|prox|psio|pt\-g|qa\-a|qc(07|12|21|32|60|\-[2-7]|i\-)|qtek|r380|r600|raks|rim9|ro(ve|zo)|s55\/|sa(ge|ma|mm|ms|ny|va)|sc(01|h\-|oo|p\-)|sdk\/|se(c(\-|0|1)|47|mc|nd|ri)|sgh\-|shar|sie(\-|m)|sk\-0|sl(45|id)|sm(al|ar|b3|it|t5)|so(ft|ny)|sp(01|h\-|v\-|v )|sy(01|mb)|t2(18|50)|t6(00|10|18)|ta(gt|lk)|tcl\-|tdg\-|tel(i|m)|tim\-|t\-mo|to(pl|sh)|ts(70|m\-|m3|m5)|tx\-9|up(\.b|g1|si)|utst|v400|v750|veri|vi(rg|te)|vk(40|5[0-3]|\-v)|vm40|voda|vulc|vx(52|53|60|61|70|80|81|83|85|98)|w3c(\-| )|webc|whit|wi(g |nc|nw)|wmlb|wonu|x700|xda(\-|2|g)|yas\-|your|zeto|zte\-/i',substr($useragent,0,4)))
$master_global = array(
	'global:site_version'      => 'mobile'
);
else
$master_global = array(
	'global:site_version'      => 'full'
);

$assign_to_config['global_vars'] = array_merge($assign_to_config['global_vars'], $master_global); // global var arrays
$config = array_merge($config); // config setting arrays

Learn more about config setup by downloading Focus Lab’s Master Config Setup.

Now we can get seriously adaptive. Instead of that long horizontal navigation menu you’re using for desktop users, how about a simple dropdown (select) form for mobile users? Create two snippets – {sn_menu_full} and {sn_menu_mobile} – and pop your horizontal menu in the first one; your dropdown in the second. Now, in your template just add:

{sn_menu_{global:site_version}}

Because global variables are parsed early, {global:site_version} will be replaced with either “full” or “mobile”, and your template will just display the appropriate snippet.

You can use conditionals too.

{if global:site_version=='full'}
Add some extra markup that you only want desktop users to see.
{/if}

These are just two examples, but you can probably begin to imagine all the adaptive fun you can have!

You don’t need a suite of devices to test your adaptiveness either. For a quick peek at your mobile site just resize your browser window, open config.php and change ‘global:site_version’ => ‘full’ to ‘global:site_version’ => ‘mobile’.

How do you roll?

As always, I’d love the community’s thoughts on this approach, and how they’re currently tackling the adaptive web. Please don’t think any of this applies to the DesignKarma website! As is always the case, this website languishes whilst I’m busy applying the latest technologies and techniques to client sites. I know, I know, poor excuse…

As a long-time EE Pro Network developer, I was proud (and a little nervous) to have organised and hosted it. I suppose it’s one way I can give back to a community and organisation (EllisLab) that have given me so much. Either way, here is my account of EEUK11.

Having thoroughly enjoyed trips out to EECI in The Netherlands the last two years, I was disappointed to hear there would be no European ExpressionEngine conference this autumn. Foolishly, I tweeted the idea of a UK EE meet-up this summer, and the response was immediate and very enthusiastic – along with cries of “let us know when you’ve sorted it out.” Ah. Oh dear.

Worse still, what I’d imagined as an informal meet-up in a pub somewhere over sausage rolls and sandwiches, was quickly becoming a full-blown conference, with people asking about guest speakers and posh venues. “Well, how hard can it be?” I thought (naively). I decided to plough on. EEUK was born.

I’ve spent more time than I’d bargained for this summer checking out venues, lining up sponsors, speakers and giveaways, and of course selling tickets. Would it all be worth it?

EEUK Week

EEUK week was a blur, with DesignKarma work taking a back seat. The whole thing only really became a reality at 08:30 on Wednesday morning, when I met guest speaker Leslie Flinger from Seattle. At that point it definitely sunk in. It was really actually happening.

The speakers and I were booked in the Arora Hotel for Thursday and Friday, but Leslie arrived a day early, so stayed with us Wednesday. I had strict instructions from my wife Ali to stall Leslie for an hour while she tidied up after a plumber who’d called that morning to fix our shower that had packed in the day before. Luckily, Leslie needed some breakfast so we headed for a cafe. Driving her around on the left-hand side of the road completely freaked her out! Still, I guess it woke her from her jet lag because she was soon installed at home working on her slides. Until of course, our phone line (and internet) went down. Unbelievable timing, and another bad omen for EEUK! We decamped to my office in Altrincham for the rest of the day. Then it was home for dinner and a few glasses of wine.

Leslie was still in bed Thursday morning as I met another guest speaker at the airport – EllisLab tech support guru John Henry Donovan from Cork. My dining room quickly turned into EEUK HQ with John Henry, Leslie and I working on slides, surrounded by boxes and luggage. My daughter popped in a few times to be nosy and wish me luck in my “assembly”.

After lunch we drove into Manchester and checked in at the Arora. EECI organiser Robert Eernart was waiting in reception, along with another of my speakers Stephen Lewis, plus Simon Cox. I transferred a ton of gear from car to room, and set off again for the airport. This time to pick up speaker Carl Crawley and Geoff Cowan. I dropped them both in Manchester, drove home to ditch the car, and then hopped on a tram back into town again.

Time for some pre-conference drinks and pizza at Dukes92. Joel Bradbury and Lodewijk Schutte (Low), two more of my speakers were there. Rather impressively, most of my speakers headed back to the hotel early to work on their slides that evening. Discipline, I thought. Either that or they were way behind! I stuck around till 10:30 before heading back and spending an hour or two in my hotel room assembling goodie bags and going over everything.

The Morning of EEUK

I slept pretty well, got up at 07:00, and headed for breakfast with Carl and Joel. Made the mistake of checking Twitter at around 08:00 and read a stream of tweets from attendees on their way, all excited. This thumped home the reality of it all and gave me a brief panic attack.

At 08:30 it was time to head over on foot to the EEUK venue. Thankfully, Carl and John Henry helped me cart a ton of gear over there, saving me 3 or 4 trips. I chose Manchester Town Hall’s Banqueting Room over other venues I’d looked at because of it’s obvious wow factor, but also its’ sense of history, size, shape and natural acoustics.

Ali arrived at about 09:15, with her friend Nic shortly after that. They helped out registering delegates who started arriving much earlier than expected, and we had to bring forward the catering a bit. My remaining speakers arrived, and by 10:15 the coffee room was buzzing, and so were my nerves. John Henry was having trouble with his slides on his MacBook, so we transferred to my MacBook Pro. Some more twiddling was needed, so we agreed to switch him in the running order with Leslie.

At 10:30 everyone started to take their seats in the Banqueting Room. Yikes. What a lot of people! This was all on me. If it bombed, there was no-one else to blame. I took to the stage and welcomed everyone before introducing our first guest speaker, Joel.

Watching Joel, I relaxed and just became part of the audience. I realised I had seven great speakers whom I knew would absolutely smash it. All I had to do was introduce them all and try not to trip up on the stage. Hey, I might even enjoy myself!

During Leslie’s talk I sat over on the side with John Henry, making sure his slides were coming together. I also got to look at the audience, who appeared to be enjoying it. Early tweets suggested that too.

Next up was John Henry’s talk on faceted navigation (using Solspace Super Search and AJAX). It left everyone with the same though: “Wow, I’ve got to use that on something.”

Then it was time for lunch. The morning session seemed to fly by. Whilst the buffet was being prepared, Malcolm Elsworth of EEUK sponsors Electric Putty demoed their latest EE add-on Better Workflow, and I deployed the BingoTron 2000 (a crummy little bingo machine I borrowed from my daughter!) to draw 5 random license winners. I dished out some more the same way after lunch.

The Final Push

It was great to see everyone back in their seats at 2pm on the dot, ready and raring. Stephen Lewis was first up after lunch, with some great add-on development tips. Next was a complex but revealing delve into EE’s parse order from Low, before it was time for some very welcome coffee and cakes. By this stage, I’d relaxed into it, worked out some technical kinks, and was getting some really great feedback from delegates.

After the break, Carl Crawley blew us all away with his talk on optimisation, as well as some bonus material on updating EE with an insane bash script he’d written. EEUK drew to a close with a hot-topic talk from Garret Winder on going mobile with EE. It was short but covered a lot of ground and drew some interesting questions from the audience on duplicate content.

Once Garrett wrapped up, I closed EEUK11 by thanking everyone once again, and directing them to the after-party at the wonderful Sam’s Chop House. Delegates practically ran there and I had to call Ali to tell her to get over there fast and let them know we were early. As it was, the area supposed to be roped off, wasn’t; and it apparently took a little while to clear the area. No harm done though, and everyone was soon in and tucking into the free bar – thanks to our gold sponsor (Pixel & Tonic).

I collected up any remaining gear at the Town Hall and took it back to the hotel with some of the speakers, before we all headed over to the Chop House ourselves. That first beer tasted great. The second wasn’t bad either.

I tried to talk with as many delegates as I could, but there wasn’t a great deal of time, and many had to catch trains etc… Those of us who were out for the night headed to Croma after the Chop House for some pizza, before then taking over The City Arms until last orders. From there, things went downhill. Or rather, downstairs… to The Tiger Lounge, where us hardcore EEUK’ers partied till about 4am. Highlight for me was watching Leslie and John Wells doing a hoe-down to “Dueling Banjos” (eclectic doesn’t even come close to describing that DJ’s playlist).

EEUK12?

So that was EEUK, and judging from the response I’ve had and read on Twitter, it went down pretty well. My seven guest speakers dropped some knowledge bombs, venue was great, food was great, after-party was great…

I was asked many times on Friday and over the weekend whether I’ll do an EEUK12. I must say, I’m in no great hurry to do it all again. It also depends on what happens with EECI Europe next year. I’m glad it went well and everyone enjoyed themselves and found it worthwhile, and that’s good enough for me I think. I’m a web designer, not an event organiser.

Having said that I did actually enjoy it, and the stress is already fading from my memory. Nah, definitely not doing it again. Well, almost definitely not. Well, possibly…

Thanks again to all who supported and attended! More information, photos and speakers slides can be found at the EEUK website.

EEUK is the UK’s first national ExpressionEngine conference, being organised by DesignKarma. Having recently worked with Mike on an EE project we’re thrilled that he’s supporting this event, along with Pixel & Tonic, Engine Summit, Creat//ee and Ellislab so far.

See you there!

The next EEUK registrant will get the free ticket, but the discount is available to all other registrants.

So whether you want to hone your ExpressionEngine skills, or you’re new to the platform, now would be a great time to register for the UK’s first national ExpressionEngine conference EEUK where you can learn from and mix with the cream of the UK EE community. You’ll also get the aforementioned free or discounted seat to the Creat//ee class.

We’ll pick the winner at random on Friday afternoon. All you need to do is register for EEUK, and you could be adding two EE conferences to your calendar. Good luck!

Special thanks to Christopher at Environments for Humans.

Having attended similar events in The Netherlands (EECI), DesignKarma thought it would be fun to gather a bunch of ExpressionEngineers to socialise, network and share. The community agreed, and now I wished I’d kept my mouth shut! Nonetheless, I’ll be attempting to organise a smaller, much more informal version of EECI sometime this summer. Maybe it will be the start of many such annual meet-ups.

For anyone interested in attending please visit: http://eeuk.org and register. Plus, you can join in the conversation following the hashtag #eeuk11 on Twitter. See you there!

The new site isn’t typical of our EE builds because it’s a little more hard-coded than content managed, and a little simpler overall than regular projects. However, it’s a chance to give a glimpse of how we power our sites using EE and invite feedback on how other folks do it!

Getting started

EE developers regularly talk about “chunking up” their pages into blocks of code. In some cases this may involve building a full static page or pages, before deciding on the best way to chunk certain elements. More often than not though, this chunking process happens fairly quickly in the developers head, before diving straight into markup.

That was certainly the case on a simple site like ours, where it’s obvious from the design which elements should be chunked as reusable code blocks, and which are page-specific. From there it was a case of creating our global variables, snippets and templates in EE and firing up our favourite HTML editor (TextMate).

Global variables

EE’s Global Variables are perfect for holding simple data like phone numbers and other information that will be repeated throughout a website. They parse ahead of everything else in EE, so they’re kind of limited— no EE tags or PHP allowed. They’re not particularly client-friendly either (we prefer Low Variables for that), so we tend not to use them all that much.

We recently took over a website built by another agency and it had about 50 global variables for things like {container_div_start_tag}. Abstracting your code to this degree has some advantages, but it’s way overboard in our opinion, making updates a real headache. We like simple.

There are only four global variables on our site, and I’m not going to spend a great deal of time detailing them because they don’t really do much! Briefly, they are:

• {doctype} contains our doctype declaration, in case we decide to change it
• {address} contains our street address, used in various places on the site
• {author} populates our meta author tags
• {modernizr} contains a link to the latest Modernizr script

Modernizr is a script that helps us take advantage of the latest web technologies used on our new site, whilst accommodating older browsers that haven’t caught up yet.

A note on naming conventions

On larger sites we like to prefix our global variables with “gv_”. We prefix other elements too, like path variables (pv_) and snippets (sn_), so it’s obvious what each element is in our code— useful not only during development, but also five years down the line when you come back to make changes. The DesignKarma website is pretty simple though, so we didn’t bother prefixing.

Snippets

New to EE2, snippets are a great way to reuse blocks of code. Like global variables, you can go a little overboard with these, but when used correctly they’re an important way of managing your code and improving performance. Unlike global variables, you can include EE tags and PHP to really make snippets super useful.

We have a number of repeated items on the site that we decided to turn into snippets.

{body_conditions}

We’ve been building some sites lately using HTML5 technologies, and we use a home brew of code distilled from Paul Irish’s popular HTML5 Boilerplate. Part of that codebase includes some HTML conditional comments to write classes on the <body> tag for Internet Explorer, so we can provide some CSS workarounds for common IE rendering issues. It’s a pity we still have to target workarounds for specific browsers in this day and age (I’m looking at you Microsoft), but having all this crap in a snippet means that one day hopefully we can just strip out the comments and go back to a simple <body> tag instantly across the entire site.

Aside from that, the other purpose of this snippet is so we can add a section class to our pages. Here’s how it all works:

{if segment_1 != ""}
	<!--[if lt IE 7 ]> <body class="ie6 {segment_1}"> <![endif]-->
	<!--[if IE 7 ]>    <body class="ie7 {segment_1}"> <![endif]-->
	<!--[if IE 8 ]>    <body class="ie8 {segment_1}"> <![endif]-->
	<!--[if IE 9 ]>    <body class="ie9 {segment_1}"> <![endif]-->
	<!--[if (gt IE 9)|!(IE)]><!--><body class="{segment_1}"><!--<![endif]-->
{if:else}
	<!--[if lt IE 7 ]> <body class="ie6"> <![endif]-->
	<!--[if IE 7 ]>    <body class="ie7"> <![endif]-->
	<!--[if IE 8 ]>    <body class="ie8"> <![endif]-->
	<!--[if IE 9 ]>    <body class="ie9"> <![endif]-->
	<!--[if (gt IE 9)|!(IE)]><!--><body><!--<![endif]-->
{/if}

So what’s going on here? We’ve got a mix of EE and HTML conditions that add classes to our <body> tag. Let’s start with the EE conditions. Firstly, we check to see if segment_1 is available, which means we’re in a section; not the homepage.

designkarma.co.uk/index.php/here_is_our_section_segment

If we’re in a section (e.g. About) we want to add that segment as a class to our body tag (e.g. body class=”about”) so we can add some section-specific CSS like repositioning the background image. If no segment is available then we’re on the homepage so no need for a section class.

The HTML comments inside our EE tags are borrowed from HTML5 Boilerplate, and add <body> classes for Internet Explorer browsers, so we can target any CSS workarounds.

{footer}

No prizes for guessing what this is. The footer is exactly the same on every page, so it makes an obvious snippet. There’s nothing of great interest in this snippet of mostly static HTML and a few EE tags, so let’s move on.

{masthead}

The masthead snippet includes our main menu. The {segment_1}}conditional comes in handy again, this time to add an “active” class so we can style the currently active menu item.

<header>
	<a href="#msg" class="visuallyhidden">Skip navigation</a>
	<nav>
		<ul class="clearfix">
			<li><a href="{homepage}" class="ir dk" title="Web Design Manchester">Web Design Manchester, {site_name}</a></li>
			<li><a href="{path='about'}"{if segment_1=="about"} class="active"{/if}>About</a></li>
			<li><a href="{path='what'}"{if segment_1=="what"} class="active"{/if}>What We Do</a></li>
			<li><a href="{path='folio'}"{if segment_1=="folio"} class="active"{/if}>Portfolio</a></li>
			<li><a href="{path='blog'}"{if segment_1=="blog"} class="active"{/if}>Blog</a></li>
			<li><a href="{path='contact'}"{if segment_1=="contact"} class="active"{/if}>Contact</a></li>
		</ul>
	</nav>
</header>

{scripts}

Generally speaking we like to keep all our scripts in one snippet, with conditions to load scripts and call functions depending on page (or {segment}). This snippet is always added before our template’s closing <body> tag, and in this instance includes:

• A link to the latest jQuery repository, hosted on Google
• Links to the the various jQuery plugins used on the website (Tooltip, Nivo Slider, and Validate), plus associated functions
• Our Google Analytics

{teasers}

Our final block of reusable code is for the teasers that appear on the Homepage and Portfolio pages. They give short intros to the “About”, “What We Do” and “Blog” sections. Most of this is hard-coded; only the blog entry is dynamic.

{exp:channel:entries 
	cache="yes" 
	channel="blog" 
	disable="categories|member_data|pagination" 
	dynamic="no" 
	limit="1" 
	orderby="date" 
	refresh="30" 
	sort="desc" 
	sticky="yes"
}
{if no_results}<p>Sorry, the blog is currently closed!</p>{/if}
<h2><a href="{title_permalink='blog/comments'}" title="Read “{title}”">{exp:trunchtml chars="28" exact="yes" inline="&hellip;"}{title}{/exp:trunchtml}</a></h2>
<p>{exp:trunchtml chars="115" exact="no" inline="_[&hellip;]"}{exp:tagstripper:stripAllTags}{summary}{/exp:tagstripper:stripAllTags}{/exp:trunchtml}</p>
<p><a href="{title_permalink='blog/comments'}" title="Read “{title}”">Continue reading</a></p>
{/exp:channel:entries}

We always like to use the cache/refresh and disable parameters in our channel entries tags to make sure our engine is running as efficiently as possible. You’ll also notice some 3rd-party plugin code ({exp:trunchtml} and {exp:tagstripper}). This is outlined in Chapter 2, but they basically exist to chop any long blog headings or summaries, so our Blog teaser lines up nicely with the other two teasers.

Bringing it all together with templates

With our code successfully chunked up into variables and snippets, it was time to start on our template groups and templates.

There’s no point going into detail on every single template here. Instead, we’ll illustrate how the bulk of our templates work, as well as picking out a couple items of interest.

Barebones

Pretty much every template on the site has the same basic outline:

{doctype}
<html lang="en" class="no-js">
<head>
	<meta charset="{charset}">
	<title>Web Design Manchester, Web Development, ExpressionEngine | {site_name}</title>
	<meta name="description" content="DesignKarma designs and develops ExpressionEngine websites, bringing over a decade of experience to your web project">
	<meta name="author" content="{author}">
	<link rel="alternate" type="application/atom+xml" href="{path='blog/atom'}">
	<link rel="alternate" type="application/rss+xml" href="{path='blog/rss'}">
	<link rel="stylesheet" href="{stylesheet='_css/index'}">
	{modernizr}
</head>

{body_conditions}

<div id="container">

	{masthead}

	…main content goes here…

{footer}

</div><!--/container-->
	
{scripts}
	
</body>
</html>

Our global variable ({doctype}) is first up, with a couple of EE’s standard global variables next ({charset} and {site_name}). The {author} global variable rounds out our metas, before we link to our Atom and RSS feed templates.

To minimise HTTP requests, we like to link to one stylesheet (_css/index) and use media queries in the stylesheet itself for print and (coming soon) smart phone styles.

All that’s left now is to add our {modernizr}, {body_conditions}, {masthead}, {footer} and {scripts}.

Taking it a step further

Where our basic outline gets slightly different is on single entry templates— for example a single project page or blog article. On these templates we want to throw some data into the <title> and <meta> tags, so we need our EE tags at the start.

{exp:channel:entries 
	channel="blog" 
	disable="category_fields|member_data|pagination" 
	dynamic="yes" 
	limit="1" 
	require_entry="yes"
}
{if no_results}{redirect='error'}{/if}
{doctype}
<html lang="en" class="no-js">
<head>
	<meta charset="{charset}">
	<title>{if browser_title}{browser_title}{if:else}{title}{/if} | {site_name}</title>
	<meta name="description" content="{meta_description}">

The example above shows our “comments” template—used to display the page you’re looking at right now. As usual we’re optimizing the engine by disabling stuff we don’t need with the disable= parameter. We’re also using the require_entry parameter to improve error handling on mistyped URLs. Without this, someone could type anything in segment_3 and EE would show our latest entry by default. Well, I don’t really want our latest article being linked to or indexed as:

designkarma.co.uk/index.php/blog/comments/the_most_boring_article_ever

So using the require_entry parameter is a nice save for mistyped (or mischievous) URLs.

Also in the above code, we’re using our custom fields aimed at improving SEO ({browser_title} and {meta_description}). Note, we’re checking to see if our {browser_title} field contains a value or not. If it doesn’t, we fall back to the entry {title}.

Marking up the blog with HTML5

Okay we may be going a little off-piste here but I thought it might be interesting to outline how we mark up our blog using HTML5 and EE.

HTML5 is a fairly new technology and there is still some discussion on how best to markup a blog, so we thought we’d chip in. Also, we haven’t seen any examples of HTML5 blog markup with EE tags yet so let’s add that in to the mix while we’re at it.

{exp:channel:entries 
	channel="blog" 
	disable="category_fields|member_data" 
	dynamic="yes" 
	limit="5"
}
{if no_results}<p>Well that's embarrassing! There are currently no blog entries available. Please check back soon.</p>{/if}
<section>
	<header>
		<hgroup class="clearfix">
			<h1><a href="{title_permalink='blog/comments'}" title="Read “{title}”">{title}</a></h1>
			<h2><time pubdate datetime="{gmt_entry_date format='{DATE_W3C}'}">{gmt_entry_date format="%d %M %y"}</time></h2>
		</hgroup>
	</header>
	<div class="details">
		<p class="author">Posted by {author}</p>
		<p>{if allow_comments}<a href="{title_permalink='blog/comments'}" title="Read “{title}”">{if comment_total==1}1 comment{if:else}{comment_total} comments{/if}</a>. {/if}Filed under {categories backspace="2" disable="category_fields" style="linear"}“<a href="{path='blog'}" title="View all entries in this category">{category_name}</a>”, {/categories}</p>
	</div>
	<div class="summary">
		{summary}
	</div>
</section>
{paginate}
{if {total_pages} > 1}
<p class="pagination">
	{if previous_page}<a href="{auto_path}" class="prv">Previous</a> / {/if}
	{if next_page}<a href="{auto_path}" class="nxt">Next</a>{/if}
</p>
{/if}
{/paginate}
{/exp:channel:entries}

The code block above outputs our last five blog entries in date order. HTML5 newbies will spot the new <header> and <time> tags right away. Note that we’re using EE’s handy {DATE_W3C} formatting variable to format the entry’s datetime attribute just how the W3C likes it.

One other point of interest is oftentimes we only want to show pagination links when needed rather than by default. To do this (and there are various other ways) we surround our pagination links with the condition:

{if {total_pages} > 1} …show our pagination links… {/if}

In other words, if the number of entries exceeds our limit (set as five in this case) and requires another page; show the links.

A bit of CSS trickery

One last thing it might be fun to share with you is how we built the three random screens feature on the homepage.

Grabbing three random entries from the folio is the easy bit:

{exp:channel:entries 
	channel="folio" 
	disable="categories|member_data|pagination" 
	dynamic="no" 
	limit="3" 
	orderby="random" 
	search:folio_show="=Yes"  
	sticky="yes"
}

Here, we’re being careful to only select entries with the custom field {folio_show} set to “Yes”. We created this field because we want to restrict which projects we display on the homepage.

Next, we need to output screens for the three projects in seperate <div>s with their own ids, so we can position and overlap them with CSS. To further complicate things, we need the first screen to be larger than the other two. So here goes:

<div id="screen_{count}">
	<a href="{path='folio'}" title="Check out the portfolio">
		{if count == "1"}
		{exp:ed_imageresizer 
			alt="{title}" 
			debug="yes" 
			forceWidth="yes" 
			image="{folio_img_1}" 
			maxHeight="319" 
			maxWidth="460"
		}
		{if:else}
		{exp:ed_imageresizer 
			alt="{title}" 
			debug="yes" 
			forceWidth="yes" 
			image="{folio_img_1}" 
			maxHeight="229" 
			maxWidth="330"
		}
		{/if}
	</a>
</div>

Here, we’re creating three <div>s with their own ids depending on result {count}— i.e. #screen_1, #screen_2, #screen_3. For the first screen (where {count} is 1) we use the ED Image Resizer plugin to resize and cache the screen image at the larger size of 460 x 319 pixels. Subsequent screens are re-sized and outputted at 330 x 229 pixels. Now we need to positioning and stack these layers with CSS to give us our three dimensions:

#screen_1, #screen_2, #screen_3{
	float: left;
	position:relative;
}
#screen_1{
	margin: -286px 0 0 219px;
	width: 462px;
	z-index: 98;
}
#screen_2{
	margin: -271px 0 0 0;
	width: 332px;
	z-index: 97;
}
#screen_3{
	margin: -271px 0 0 608px;
	width: 332px;
	z-index: 96;
}

On top of the three screens we’re floating the transparent PNG shown below.

This gives our browser chrome outlines and a nice bit of light and shade on top of our screens. We could’ve included the outlines and shading on the actual project screen images, but we preferred to keep these pure in case we wanted to apply a different treatment or decoration at a later date, if that makes sense.

So, before our <div id=”screen_1”> we have an empty <div id=”chrome”>. Not very semantic I’m afraid, but allow us some creative license here. To get this layer to sit on top of everything the CSS goes like this:

#chrome{
	background: transparent url(/images/cover.png) 50% 0 no-repeat;
	float: left;
	height: 301px;
	position:relative;
	width: 940px;
	z-index: 99;
}

To finish off, we added some borders to our screens…

#screen_1 img, #screen_2 img, #screen_3 img{
	border-bottom: 1px solid #999;
	border-left: 1px solid #999;
	border-right: 1px solid #999;
}

...and we’re done.

It’s a wrap

That about does it for this series. Maybe you’ve learnt something, maybe you haven’t. But I always find it fascinating to see how other EE developers work and thought it was about time DesignKarma contributed something. Hopefully we’ll continue to post more EE insight, tips and tricks when we can.

We’d love to hear your feedback on the above, and how you build your EE sites. Why not leave a comment below?

Setting up content management with ExpressionEngine 2

As part of the redesign, we wanted to move from EE1 to EE2 and take advantage of some of the new performance and code management features. We’ve learnt an enormous amount since we built the old site in EE1 and liked the idea of a fresh installation, rather than an upgrade. The only difficulty with starting from scratch rather than upgrading, was importing the old blog entries, but that’s another story.

Development environment

The DesignKarma website is much simpler than our usual EE projects, so I decided to just install locally in MAMP on my MacBook. That also meant I could continue to work on the site when out and about over Christmas and New Year, often without a web connection.

Once completed, I simply exported the database and recreated it on the live server. Then it was a case of deleting the old site and uploading the new one, changing some paths and hey presto! The switch took less than 30 minutes.

ExpressionEngine installation and preferences

It depends on the site but generally speaking there are a number of things we do right after every new EE installation. On complex high traffic sites, we like to turn on “Display Output Profiler” and “Display Template Debugging” (Admin > System Administration > Output and Debugging), so we can see how our templates are processing and optimize as much as possible during development.

On most of our sites we also turn off tracking (Admin > Security and Privacy > Tracking Preferences). Tracking is really for creating things like “most viewed entries” lists. Turning it off can greatly improve system speed, especially on higher traffic sites.

Last few quick changes we make concern security. We always enable throttling (Admin > Security and Privacy > Throttling Preferences), which is a great way to handle possible denial of service attacks. Next, we turn our attention to spammers – membership spam to be specific.

Fighting membership spam

Membership spam is an increasing problem on the web,and it’s by no means limited to ExpressionEngine. Greg Salt at Purple Dogfish gave a great talk on spam at last year’s EECI, and he shared a number of ways to combat and defeat it. An obvious one is – if there’s no front-end membership aspect to your website – just disable new member registrations altogether (Members > Preferences). If you are planning on allowing new member registrations then making one simple change can really help: Change your profile trigger word from “member” to, well… anything. Spam bots know that EE’s default member templates and registration form are at:

yourdomain.com/index.php/member/

So don’t make it easy for them. Change the trigger word to “community” or “fans”, or anything, helping to mask your registration form. For bonus points, why not Disallow your registration URL and/or member pages from search engine indexing altogether via your robots.txt file.

There are also some pretty good EE add-ons for combatting membership and comment spam, which I encourage you to track down on Devot-ee, but we’re getting a little off-topic now.

Save yourself the trouble

In reality we don’t always do fresh installations every time. Instead, we like to just deploy a “ready-rolled” empty installation we made earlier, with all our configs and preferences. It saves time and nobody likes repeating themselves.

One last thing: To keep our EE installations super-secure, we always like to install above the public webroot. That way, all our system folders are protected from HTTP attack. There are some instructions on how to do this for “Advanced Users”, but it’s actually pretty straightforward. Definitely worth thinking about if you’re an EE newbie.

Categories, custom fields and channels

Before we can start publishing in EE, we need to create our categories, fields and channels. At launch, the new DesignKarma site has just 2 channels, 3 categories and 19 custom fields – told you it was a simple site!

Now, ask 10 different EE developers and they’ll give you 10 different ways of building the same site. There is no right or wrong way. Actually, there are a few wrong ways, but my point is that there are many different ways to go about the same thing, and this is just my way on this website.

Creating our custom fields

We often like to create a “Default” custom field group, which can be used for a variety of instances (or channels). We’re using this group for the blog, and it consists of:

• Browser Title (Text Input)
• Meta Description (Text Input)
• Image (File)
• Summary (Textarea)
• Extended (Textarea)

The “Browser Title” field is used for the text that appears in the very top of the browser (inside our <title> tags) as well as in a search engine listing. It’s an SEO feature we like to build into our sites; and in our comments template (i.e. the one you’re looking at now) we’ve included a condition to fallback to the entry Title if our Browser Title field is left blank, like so:

<title>{if browser_title}{browser_title}{if:else}{title}{/if} | {site_name}</title>

Again, for SEO we’ve got a Meta Description field. No Meta Keywords? Well they tend not to be used much nowadays by search engines so we don’t really use them anymore in our sites. The remaining fields are self-explanatory.

We also have a “Folio” custom field group for publishing folio entries, which consists of similar fields plus a few more:

• Image 1-5 (all File fields)
• Tasks (Checkboxes)
• Description (Textarea)
• Web Address (Text Input)
• Testimonial (Textarea)
• Testimonial Source (Text Input)
• Show on homepage? (Select Dropdown)

The five “Image” fields make up the slideshows on our project template. The “Tasks” checkboxes allow us to check/uncheck the various project’s tasks (Branding, CMS…). This outputs on the folio and project website pages.

A quick note about our field naming convention. We like to prefix our field names with the field group name. So for example, the Folio field group has fields named:

• {folio_img_1}
• {folio_tasks}

And so on… This makes it much easier to identify your channel’s fields in your template code and avoid any conflicts with similar fields in other groups. For the Default group, our fields have no prefix (e.g. {meta_description}).

Back to our Folio group then. The “Show on homepage?” dropdown let’s us choose whether or not to include the project in the 3 random screens displayed on the homepage. We want to limit the folio page to only display our most recent projects. However, we might still want to display some of our older projects on the homepage, so that’s where this field comes in. Ideally, we would like to have used a checkbox instead of a dropdown, but EE’s search= parameter only works with text input, textarea and dropdown list custom fields, so ‘dropdown’ it is. Here’s our “Show on homepage?” (or {folio_show}) field in action on the homepage template:

{exp:channel:entries 
	channel="folio" 
	disable="categories|member_data|pagination" 
	dynamic="no" 
	limit="3" 
	orderby="random" 
	search:folio_show="=Yes"
}

Note— We like to order our parameters alphabetically. We’re fussy like that!

Here we’re grabbing three random entries from the folio channel where “Show on homepage?” (or {folio_show}) is set to “Yes”. By the way, there’s some tricky EE/HTML/CSS involved in those 3 screens that we may touch on later.

The only Categories we have are for the blog, and they are “ExpressionEngine”, “Site Launches” and “General”. Hmm… not much more I can add to that really.

We tie it all together with our 2 Channels, “Blog” and “Folio”. We could’ve created channels for things like the About and What We Do pages, but since we’re web developers we may as well just hard-code those pages.

Tidying the publish page

The last thing we do as far as setting up the publishing process, is tidy up the publish page. This is a nice feature of EE2 and allows us to order our fields in a way that makes sense for clients, and hide any fields or features that the client doesn’t need. The result is a super-simple, efficient publish page.

If it’s good enough for our clients it’s good enough for us too, so we went ahead and quickly tidied the publish page for Blog and Folio—see example below. Notice we’ve popped our “Browser Title” and “Meta Description” fields into a custom “SEO” tab.

Add-ons

There’s an impressive number of 3rd-party add-ons for ExpressionEngine that bring extra features and functionality (we’ve even created our own). We like to keep things light and tight however, only using an add-on if there’s very good reason. With a simple site like ours there aren’t many good reasons. Even so, we have a few old favourites on board DesignKarma.

We regularly use Freeform from Solspace. EE’s native Email module is kind of limited, and we like the ability to capture and store our Contact form submissions. Bad things can sometimes happen with simple form-to-email and we don’t want to miss out on that next big lead.

CP Analytics is another staple of our EE sites, providing a graphical overview of your Google Analytics.

We have three additional plugins installed on DesignKarma:

• ED Image Resizer
• SuperGeekery Tag Stripper
• TruncHTML

ED Image Resizer is used to resize and cache our published images (homepage, folio, blog). We use different EE image sizing plugins on different sites, for different reasons. ED Image Resizer is great for simple proportional resizing and cacheing on the fly, but we like other plugins for things like cropping or watermarking on other sites.

We use a combination of SuperGeekery Tag Stripper and TruncHTML to grab extracts for things like our blog teaser on the homepage.

For our three columns we want to maintain a nice layout of single heading and three line teaser, so we need to truncate longer headings and/or summaries. Since our blog Title has no formatting, we just use TruncHTML:

<h2><a href="{title_permalink='blog/comments'}" title="Read “{title}”">{exp:trunchtml chars="28" exact="yes" inline="&hellip;"}{title}{/exp:trunchtml}</a></h2>

If our heading is longer than 28 characters and gets truncated, we add a horizontal ellipsis (...) on the end.

Our blog summary comes from a Textarea field and may contain some formatting (like hyperlinks) that mangles the page if the HTML tags are truncated. That’s where SuperGeekery Tag Stripper comes to the rescue. Our data is first passed through the tag stripper so only text is returned, and we can then safely truncate.

<p>{exp:trunchtml chars="115" exact="no" inline="_[&hellip;]"}{exp:tagstripper:stripAllTags}{summary}{/exp:tagstripper:stripAllTags}{/exp:trunchtml}</p>

We add our ellipsis at the end again, but this time with a space (indicated with an underscore) and brackets.

I recently came across a new add-on that might do the job of both TruncHTML and the Tag Stripper, but I’ve yet to try it out. I’m sure there are many other ways of doing this too. Why not leave your comment below?

That’s it as far as installation and setup!

Next up: Variables, Snippets, Templates… Now we’re cooking!

Okay, no more sissy stuff! In the next chapter we’ll dig deep into the variables, snippets, and templates powering the new website.

Don’t miss the next article: Follow us on Twitter or Subscribe to our RSS feed.