Any visitors to our Facebook page would realise that we've been following the development of the mobile Internet closely with the take-home message being that more and more, people are using their smart phones and tablets to visit websites. Some of those articles quote different statistics to illustrate this movement, but recently we decided to take a look at the stats for some of the websites that we've developed ourselves.

And despite global browser usage statistics showing that Internet Explorer is Australia's most popular browser, followed by Google Chrome, studying 21 of our own sites told a different story.

Rather than being in fourth place, Safari was the most used browser for 38% of the sites we looked at compared to 47.7% for Internet Explorer, and the reason that figure is so high is because most people are using Mobile Safari on their iPhones and iPads. Mobile Safari was used more than the desktop version for 80.9% of the sites, and surprisingly it's not all people using iPads, as tablet usage was only higher than other mobile devices for 38% of the sites. So it would seem that there's a lot of people using their iPhones (or iPod Touches) to visit sites we've created.

Here's a table that illustrates the popularity of the different browsers from the 21 sites we looked at.

If you're wondering why the numbers for Firefox don't add up to 21, it's because it was actually the fifth most popular browser for one of the sites we looked at.

And of the sites included in this analysis that have specific mobile optimisation work done, we've seen significantly better engagement from people using mobile devices, in other words, visiting more pages, spending more time on the site, and lower bounce rates.

As we've noted before, getting your site mobile friendly isn't as hard as you might think, so get in touch to find out how we can help.

Read full entry →

Here at Tyssen Design, we're big fans of ExpressionEngine and use it for a lot of our work, but it's not always the right fit for every project, so over the last year or so we've been testing out a few alternative content management systems, some of which we've reviewed before.

Today, we're going to look at Processwire, which has been on our radar for a while. It touts its main features as all custom fields, an easy-to-use jQuery-inspired API, and a powerful selector engine. It was chosen as CMS Critic's best free CMS for 2012, and we know a few people who use it and swear by it, and it's also come up occasionally in comparisons with ExpressionEngine, all reasons which made us want to try it out.

​

Installation

Like most CMSs, installation is a snap with a wizard to guide you through the process and give you pointers as to things you've forgotten to do when getting read to install, like setting correct permissions on folders and files. Unlike some, it's process is probably a little more friendly, by starting off with a check of everything first, marking the items in either green or red for the ones that need fixing. This is better than having you start the installation process, then encountering errors which require you to fix things then go back a step.

Processwire installs with a standard set of pages that include Home, About, Search, Sitemap and 404 Page Not Found, and these pages are displayed with a default theme too. By default, Processwire installs with very few main menu items: just Pages for content, Setup for templates and fields (and settings pages for some modules), Modules and Access where you set up users, roles and permissions. Although, what's displayed in the control panel is all controlled by the Admin page which is displayed in the main Pages tree, so you can add and remove things as you like. There's also a selection of different admin themes to choose from. (We're using Futura Remixed currently.)

Although we haven't had the need to do it yet, upgrading the CMS to the latest version also seems like a fairly pain-free experience.

Pages

Processwire is built around a hierarchal structure for pages, like a family tree or a file system. Everything that appears on the front end of your site has to appear in this tree somewhere. Clicking on pages will automatically display their children if they have them as well as an actions menu alongside for choosing whether to edit, view, add new child pages or move pages by dragging and dropping. It's fairly easy to move through a whole site's site map from the one page in this way. It's the same sort of functionality that Structure brings to the table with ExpressionEngine, although I think the UI for Structure is a bit nicer.

Every page is made up of a series of custom fields which you define under Setup / Fields and has a template assigned to it which you create and manage under Setup / Templates. Before custom fields are available on a publish page though, they have to be assigned to the template that you add to a page. So creating a new page is a two-step process:

1. first you need to give the page a name (with it's URL slug automatically populated like with ExpressionEngine) and assign a template to it and save,
2. then when the system knows which set of fields to display based on the template you've chosen, you get a publish page where you can enter your content and press Publish to have the page appear on the site.

Pages that aren't published are viewable in the control panel but not on the front end, so it's easy to create drafts and you don't have to set up specific entry statuses.

Custom fields

Out of the box, Processwire comes with several custom field types including text, textarea – which can be converted to a rich text editor (RTEs), image, file, checkbox, date and URL.

Textareas and the images field have been implemented really well. The images field is by default a repeater field, i.e. you can keep adding images to it, in fact you can grab a whole bundle of images and drag them into the field area and they'll automatically get added. Each image added has its own description field for adding a caption.

So for quickly adding lots of images, ideal for creating image galleries, Processwire is much better equipped out of the box than ExpressionEngine. EE can achieve a similar level of ease of workflow, but you need to purchase add-ons to do it.

Even though textareas use TinyMCE for rich text editing (I'd prefer CKEditor which I believe has progressed further in recent years), the link and image buttons have tight integration with the rest of the CMS, enabling you to easily add images to the content and apply CSS classes for alignment (rather than inline style), and to choose pages already created to link to.

The only drawback I found with adding images in this way, is that the images have to be added to the page via a standard images field; there's no way to upload an image from the modal window launched from within TinyMCE. You can also only choose images that are added to the page you're on, or from another page. You can't select images from a global file manager because there isn't one. This seems like a bit of an oversight to me as this sort of feature is pretty standard among other CMSs, for example, ExpressionEngine, Concrete5 and Wordpress all have one.

The standard images field also has no way to select existing images, you have to upload the same image again using this field type, even if the file exists on another page somewhere. From a duplication and space taken on the server point of view, this isn't ideal, but because adding images is so easy, it's easier to overlook.

Templating

One of the things that delayed me getting into Processwire is that it uses plain PHP as it's templating language. I think my frustration with templating in Wordpress whenever I've had to get involved with it more recently coloured my view of writing code in PHP, but that's more to do with the way Wordpress works (or more specifically the way themes designed for it are put together) than with PHP itself.

By default, Processwire comes with a theme where the templates are split up into global header and footer includes, but it's also possible to follow a template partials approach and use a master layout template which individual templates then pass their specific data/code to. Here's an example of something similar to what I've been working with.

<!doctype html>
<html>
	<head>
		<title><?php echo $page->get("title"); ?></title>
	</head>
	<body class="<?php echo $page->name; ?>">
	<header role="banner"> </header>
	<div id="content">
		<article role="main">
			<?php echo $main_content; ?>
		</article>
		<aside role="complementary">
			<?php echo $sidebar_content; ?>
		</aside>
	</div>
	<footer role="contentinfo"> </footer>
</body>
</html>

<?php

/**
* Page template
*/

$image = $page->images->first();
if($image) :
	if($image->width >= 760) :
		$cropped = $image->size(760, auto);
	else:
		$cropped = $image;
	endif;
endif;

$main_content = "<h1>{$page->title}</h1>";

if($cropped) $main_content .= '<img src="'.$cropped->url.'" alt="">';

$main_content .= $page->body;

include("./main.inc.php");

In the examples above, everything that appears after $page-> is the name of a custom field.

Processwire has a fairly robust API inspired by jQuery for selecting data from your pages. We've only built fairly simple sites with Processwire so far, so we haven't had a need to fully explore the power of its selectors, but from the looks of the documentation, you could get quite sophisticated with your querying without having to write any SQL. Which brings me to my next point.

Documentation

Definitely one of the weakest points about Processwire is its documentation. There's a lot of good stuff in the official API guide, but there's also a whole lot of stuff which seems to only exist in forum threads, often with code examples followed by modified code examples, or links to modules at the bottom of individual forum posts.

You can usually find what you're looking for after looking around the forums a bit, but it's not as easy as it should be. From speaking to a couple of people it seems that Ryan Cramer, Processwire's creator, and the other core developers, are aware of the problem, so hopefully there'll be some improvement on the horizon.

Pros and Cons

Pros

• Uncomplicated control panel so it's easy to get used to where everything is.
• Easy page management with drag and drop functionality.
• A good collection of first party and third party modules (nearly all free) for adding a variety of functionality.
• Templating language that most people would be familiar with, and no need to learn new tags (although you do still need to learn what you can do with the API).
• Easy to set up templates, custom fields and users/roles.
• Easy to use image and RTE field types.
• The developer community around Processwire seems quite small but approachable and happy to help out.
• Updating seems to be a lot easier than with EE.

Cons

• Everything has to be a 'page' even if you don't use it as a page. For example, if you want to create a custom field which has checkboxes or select options, you actually have to create separate pages and then use a page-relation field type to have each page appear as an option in a publish form. Sometimes you might actually want site visitors to visit those pages, so it makes sense that you create them as pages, but that won't always be the case. And then you'd have to explain to clients why some pages are actually pages and others are something else.
• Doesn't have global variables, so small snippets of editable content also need to be created as 'pages'.
• As already mentioned, the lack of a global file manager is a shortcoming.
• There's no native contact form module. There is one you can buy (and it also has a developer's licence) and there is also this free one which can be used but both make use of Processwire's back-end form mark-up on the front end. While you can customise the output, you don't have 100% control, i.e. currently you can't add custom attributes (for instance I always like to add required aria-required="true" to required inputs to bring native browser validation into play), and anything involving radio buttons or checkboxes gets output inside unordered list tags, and there's no way to wrap all the controls in a fieldset with a legend.
• The documentation I've already mentioned.

But all in all, I think it's a good system, and from not having tried it just over a month ago, we've now built four small sites with it, and can easily see it being used it quite a bit on smaller sites that ExpressionEngine is overkill for (although BlockCMS just hit public beta this week, so that may change ;) ). Thanks to Marty Walker for his help with my questions and general tweeting about Processwire.

Read full entry →

Mobile Internet is massive in Australia; we have nearly 9 million smart phone users, approximately 37% of the population, making us the second most smart phone-friendly nation in the world. More than 2 million Australians use their mobile phone to access the Internet each month (Roy Morgan Research), with more than half doing product searches. In fact, research from Google indicates more than 40% of shopping-related enquiries come from mobile devices, but less than one third of small businesses have a mobile-friendly site.

Those numbers are only going to get higher, with mobile Internet usage tipped to outstrip that of the desktop (which includes desktop and laptop computers) in the next year or so.

So if you don't have a website that works well on mobile devices (smart phones and tablets), you could well be missing out.

But the good news is that it's not that hard to get your business ready for mobile; you don't necessarily need to rush out and have an app developed.

The first step would be to actually get yourself a website if you don't already have one because people are increasingly unlikely to buy from you or visit your business unless they can check out your website first. But we'll assume that you already have one, and are just after ways of making it work for mobile.

Create a mobile version of your site

While smart phones do a pretty good job of fitting your site's layout into their small screens, it's not as convenient for your visitors to keep having to tap to zoom in and out.

Creating a layout that automatically fits the screen it is viewed on will reduce the number of taps people have to make, making navigating your site easier and creating a more positive impression.

How this is done will depend on your site, its content and goals, but you wouldn't necessarily need to create a completely separate mobile site. For many smaller sites, your current site's layout could be made ‘responsive’ or ‘adaptive’ which means it adapts to whatever size screen it is viewed on.

Ideally, mobile layout considerations would be included in the original planning and design phase for your site, but existing sites can have mobile-friendly styles ‘retrofitted’ if you are looking for a short-term solution.

Keep pages as light as possible

Not only do search engines give preference to faster pages in their results, but particularly for mobiles, fast-loading pages are essential if you want to capture people's attention and keep them on your site. This ties in to the point above, but when creating a mobile version of the site, whether it's a separate site, or the same site using an adaptive layout, code and images would be optimised to ensure your site loads as quickly as possible on mobile.

Replace Flash

Flash is a technology that adds animation and movement to websites, but unfortunately it doesn't work on Apple's iPhones and iPads. So if you have Flash on your site and you view it on an iOS device, you'll just see a blank space, which doesn't leave a very good impression.

In most cases, Flash can be replaced with HTML and javascript that will work everywhere, and is easier to update.

Design changes

With limited screen real estate, you may need to make some slight adjustments to the layout of your pages, particularly the home page.

Make contact details highly visible, use less copy on your home page, and don't have pages that are cluttered with links.

Claim your local business listing on Google Places

Many people on the go will use Google maps or Google Places to find businesses close by. Claiming your business on Google Places and linking your office or shop to Google Maps means you are more likely to be found by these people.

If you'd like help getting your website mobile-friendly, or would like someone to assess how well your site performs on mobile now, please get in contact, we'd love to help.

Get your website mobile-friendly

Read full entry →

As promised in the last post I'm going to delve a bit more into some Stash examples I've used on other ExpressionEngine projects.

Shortcodes with Stash

If you're unfamiliar with the term ‘shortcode’, it comes from Wordpress and gives an author the ability to drop a block of code into their WYSIWYG editor where they want it which is pretty useful if you want to have some paragraphs of text, a block of code that does something else like a gallery or form or list of related entries, and can then follow up with more content without needing to split things up into separate fields.

In Wordpress a shorcode would look like [name_of_shortcode] and you could place that anywhere in the body of your entry and it would be converted into whatever code was contained within the file (usually a plugin) that the shortcode was called from.

<p>Lorem ipsum dolor sit amet…</p>

[name_of_shortcode]

<p>Lorem ipsum dolor sit amet…</p>
	

To do the same sort of thing with native ExpressionEngine functionality, you'd need separate fields: one for each block of text that would need to be separated by other code in the template. And in the template, you'd need to use either separate channel entries tags for each block or use embeds so that you could insert code from other channels in between the fields.

But with Stash, you can do pretty much the same thing as you would in Wordpress. Here's a couple of different examples.

Example 1

This example comes from the SpinePlus website which was redesigned earlier this year. The subheadings, paragraphs of text and the large single image at the bottom of the page come from a single entry in a Site Pages channel. The headshots of the visiting practitioners come from a Staff channel. Here's how it's done:

{exp:stash:set name="st_shortcode"}
<ul>
	{exp:channel:entries
		channel="staff"
	}
	<li>
		{exp:imgsizer:size src="{image}" width="150" alt=""}
		<h2>{title}</h2>
		<p>{position}</p>
	</li>
	{/exp:channel:entries}
</ul>
{/exp:stash:set}

{exp:stash:set name="st_content" parse_tags="yes"}

	{exp:channel:entries
		channel="site"
		url_title="{last_segment}"
	}
		{exp:allow_eecode}
			{body}
		{/exp:allow_eecode}
	{/exp:channel:entries}

{/exp:stash:set name="st_content"}
	

The information for the practitioners is saved to its own Stash variable which is then inserted into the body of the main page entry with {exp:stash:get name="st_shortcode"} at the point where it should appear. Then in {st_content} which is the Stash which displays the content on the page, we wrap the {body} tag in Allow EE Code plugin tags so that the Stash variable actually gets parsed (remember the parse_tags parameter).

Example 2

This example is still in development but it's doing a similar thing except that the Packages channel is being used to insert some content in the middle of the body of another entry and then after it too all using a single channel entries tag. This is because the content inserted into the body contains in-page anchors to the content that appears further down the page.

{exp:channel:entries
	channel="packages"
}
	{!-- Using some regex on the title to pull out certain entries --}
	{exp:stash:append name="st_packages" match="#^((?!Standard).)*$#" against="{title}"}
		<dt><a href="#{url_title}">{title} Service Package</a></dt><dd>{package_price}</dd>
	{/exp:stash:append}

	{!-- Picking out entries that have a detail page --}
	{exp:stash:append name="st_packages_full" match="#y#" against="{has_detail_page}"}
		<h3 id="{url_title}">{title} Service Package <span>{package_price} {package_price_extended}</span></h3>
		{package_description}
	{/exp:stash:append}

{/exp:channel:entries}

{exp:channel:entries
	channel="site"
	url_title="packages"
}
	{exp:stash:set_value name="st_page_title" value="{title}"}

	{exp:stash:set name="st_content" parse_tags="yes"}
		{exp:allow_eecode}
		{body}
		{/exp:allow_eecode}

		{stash:st_packages_full}

	{/exp:stash:set}

{/exp:channel:entries}
	

As with the previous example, {st_packages} is inserted into the body of the entry wrapped in {exp:allow_eecode}.

Displaying other items from the same category

This example isn't online either because the requirements changed after it had been done. Originally the brief was to display a list of entries from the same category on a product's individual entry page (later a Playa field was used instead to choose which entries would be related to it).

So what we had to do was get the category that the product belonged to (only one category was assigned from this particular group), and then output a list of other entries from that category. Content specific to the individual entry also needed to be displayed above and below the related entries.

{exp:stash:parse}

	{exp:channel:entries
		channel="{segment_1}"
	}

		{!-- Get the category ID of the product whose page we're on --}
		{categories limit="1"}
			{exp:stash:set_value name="st_category_id" value="{category_id}"}
		{/categories}

		{exp:stash:set name="st_content"}

			Individual entry content goes here…

			{!--  We don't want this to be parsed here since it will be filled with a value later on --}
			{stash:nocache}{exp:stash:get name="st_related_products"}{/stash:nocache}

			More individual entry content goes here…

		{/exp:stash:set}

	{/exp:channel:entries}

{/exp:stash:parse}

{!-- Get the entries from the same category --}
{exp:stash:set name="st_related_products" parse_tags="yes"}

	{exp:channel:entries
		channel="{segment_1}"
		category="{exp:stash:get name='st_category_id'}"
		limit="10"
		parse="inward"
		url_title="not {segment_3}"
	}

		<li><a href="{path={segment_1}/view/{url_title}}/" title="{title}">{products_images limit="1"}{exp:ce_img:single src="{image}" max_width="130" max_height="130" attributes='alt=""'}{/products_images}</a></li>

	{/exp:channel:entries}

{/exp:stash:set}
	

The tricky thing about this example was working around ExpressionEngine's parse order which meant that the category_id wasn't being parsed until after it was required by the channel entries tag where it was required as a parameter.

As is often the case, I had to ask Mark Croxton for some help and the solution was to force the opening block to parse {st_category_id} with {exp:stash:parse} wrapped around the whole block, and then {stash:nocache} around {exp:stash:get name="st_related_products"} to make sure it wasn't parsed until later.

Stash within a Stash

This example was used for the individual product pages on the Barben website.

Each page has a carousel of other products in the same category which are displayed below the main product. But the position of the carousel is also controlled by a start variable which equals the count of the entry. So we needed two Stash variables: one for the carousel code and one for the count of the entry.

{!-- Force Stash to parse tags and conditionals --}
{exp:stash:set parse_tags="yes" parse_conditionals="yes"}

	{stash:st_prod_nav}

		{exp:channel:entries
			channel="{segment_1}"
			category="{segment_3}"
		}
			{ if count==1}
			<nav class="carousel">
				<ul>
					{/ if}
					<li><a href="{url_title_path=xxxx}">{exp:ce_img:single src="{p_thumb}" max_width="140" max_height="140"}<span>{title}</span></a></li>
					{ if url_title==segment_3}{stash:st_start}start: {count}{/stash:st_start}{/ if}
				{ if count==total_results}</ul>
			</nav>
			{/ if}

		{/exp:channel:entries}

	{/stash:st_prod_nav}

{/exp:stash:set}

<article role="main">
	{st_content}
</article>

{!-- The nav gets called here --}
{exp:stash:get name="st_prod_nav"}

…

<script>
	$('.carousel ul').jcarousel({
		buttonNextHTML: '<span id="next" class="carousel-nav"></span>',
		buttonPrevHTML: '<span id="prev" class="carousel-nav"></span>',
		{exp:stash:get name="st_start"} // The count variable gets called here
	});
</script>
	

As mentioned before, a lot of these examples have been arrived at with the help of Mark, so major thanks to him for not only developing such a powerful and useful add-on, but for also being on hand to answer questions about it.

So that's it; I'm out of interesting examples for now, but when I've got a few more up my sleeve, will post them here. As before, if you've got any interesting examples yourselves, feel free to share in the comments.

Read full entry →

As you may have noticed, this site has been redesigned recently, and I mentioned in the announcement that I'd talk about some of the work that went into the process. So in this first instalment of what might be a two or three-part series, I'm going to talk about some of what's going on under the hood in (the) ExpressionEngine. In the other parts, I'll cover topics relating to design in general, and aspects of the front-end development. In terms of how sites normally get built, that's a bit backwards, as integrating your design and content into the CMS usually comes last, but most of what I'm going to discuss here relates to Stash, which seems to be a bit of a hot topic at the moment.

Bangers & Stash

Yep, so tasty that you just want to smother it in gravy and eat it up! If you're not familiar with Stash by Mark Croxton yet, you should be because it's awesome in so many ways, some of which are discussed by Adrienne Travis on EE Insider. One of Stash's greatest strengths, its amazing flexibility for use in a variety of situations, I think is also one of its shortcomings when it comes to uptake by developers. Because there's so many different things it can be used for, for people new to it, I think it can be a bit hard to grasp just how it can benefit you in your own work.

I'm very much a learn from examples type of guy, so rather than give a dissertation on why I use it, I'm just going to dive straight into some examples from the build of this site and others I've worked on recently.

Templates

Standard pages

There are actually separate template groups for all the main sections of the site, even though the templates for some like About and Info are essentially the same. That's just so I didn't have to use either the Pages module or something like Structure or Navee to assign the same template to pages that appear under different URLs. But even though I have different template groups for the sections, they all make use of the same code like this:

{exp:channel:entries channel="site" url_title="{segment_2}"
{sn_page}

Just the start of the channel entries tag to set the channel and the entry to display, the rest is contained in the {sn_page} snippet.

limit="1" disable="categories|member_data|pagination|trackbacks"}
 	{ if no_results}{redirect="404"}{ /if}

	{embed="_embeds/index" body_class="{segment_1}" nav_active="{segment_1}"}

		{exp:stash:set_value name="st_page_title" value="{title}"}

		{exp:stash:set name="st_content"}
			{body}
		{/exp:stash:set}

	{/exp:channel:entries}

	{exp:stash:set name="st_side"}

		{!-- Sidebar stuff like: --}
		{sn_testimonials}

		{sn_social-links}

	{/exp:stash:set}

The snippet finishes off the channel entries tag (these parameters are common) and then a single embed which pulls in the ‘layout’ template (below). We're setting a value for the page title, the {st_content} variable holds the body of the entry, and then there's another {st_side} variable for sidebar content. All fairly straightforward stuff.

{!-- Setting proper 404 headers --}
{ if segment_2=="404"}{exp:http_header status="404"}{ /if}<!doctype html>
<html>
<head>
	<meta charset="utf-8">
	{!-- Using SEO Lite for page titles --}
	{exp:seo_lite use_last_segment="yes"
		title_postfix="{embed:postfix}"
		default_title="{embed:page_title}"
		default_keywords="{embed:keywords}"
		default_description="{embed:meta_desc}"
	}
	{!-- Using Minimee for asset minification and combination --}
	{exp:minimee:css}<link rel="stylesheet" href="/assets/css/master.css">{/exp:minimee:css}
	<script src="/assets/js/LAB.min.js"></script>
	{!-- Using our own EE #RWD add-on for setting a screensize variable --}
	{exp:ress:cookie}
	{!-- Can inject code into the header from individual posts in the blog --}
	{exp:stash:get name="st_code"}
</head>
<body class="{embed:body_class}">
	<div class="header" id="header">
		…
	</div>
	<div id="content">
		{ if {exp:stash:not_empty name="st_page_title"}}<h1><span class="wrap">{exp:stash:get name="st_page_title"}</span></h1>
		{ /if}
		<div class="wrap row">
			<div role="main" class="main">
				{exp:stash:get name="st_content"}
			</div>
			{ if {exp:stash:not_empty name="st_side"}}<div role="complementary" class="aside">
				{exp:stash:get name="st_side"}
			</div>
			{ /if}
		</div>
	</div>
	<footer role="contentinfo">
		…
	</footer>
	{exp:minimee:js}{ if embed:js_off!="true"}<script src="/assets/js/site.js"></script>{ /if}
	{/exp:minimee:js}
	{!-- Can inject code here too --}
	{exp:stash:get name="st_code_ft"}
</body>
</html>

This is the template that forms the framework for the whole site, containing the global elements — header and footer, with conditionals in some places to include different things on different pages. There's comments included in the code above to describe some of what's going on.

Portfolio

The carousel displaying recent projects appears on the home page and also at the top of every portfolio detail page. To keep the templates DRY and also improve performance by cacheing the output, I'm saving a Stash as a file, in this case carousel.html which contains:

{exp:channel:entries channel="portfolio" search:p_detail="=y" disable="member_data|pagination|trackbacks" dynamic="no"}
<li class="touchcarousel-item">
	<a class="item-block" href="{url_title_path=portfolio/view}/">
		{exp:ce_img:single src="{p_thumbnail}" width="150" attributes='alt=""'}
		{title}
	</a>
</li>
{/exp:channel:entries}
	

And it's then pulled into the different templates with:

{exp:stash:get
	name="carousel"
	scope="site"
	file="yes"
	save="yes"
	refresh="60"
	replace="no"
	output="yes"
	parse_tags="yes"
}
	

I should fess up and admit that performance-wise, in terms of the number of queries and the time taken to load the page, using the above method works out pretty much the same as if I'd used a snippet and added cache="yes" refresh="60" to the channel entries tag, but I'll be looking at this method in the future and comparing it against embeds and snippets to see if it performs better in different situations.

Another thing that Stash is very handy for is inserting blocks of content from one channel in between blocks of content from other channels. For instance on the portfolio detail pages, I list the details of the project followed by a related testimonial, and then the images associated with the project. Without Stash, I'd either need to use an embed or two separate channel entries tags. With Stash I can do this:

{exp:channel:entries channel="testimonials" url_title="{segment_3}" dynamic="no" disable="categories|member_data|pagination|trackbacks"}

	{exp:stash:set name="st_testimonial"}

		<blockquote>
			{quote}
		</blockquote>

	{/exp:stash:set}

{/exp:channel:entries}

{exp:channel:entries channel="portfolio" limit="1" require_entry="yes" disable="member_data|pagination|trackbacks"}

	{exp:stash:set name="st_content"}

		<h1>{title}</h1>

		Project details…

		{exp:stash:get name="st_testimonial"}

		Project images…

	{/exp:stash:set}

{/exp:channel:entries}
	

One other thing not related to Stash going on in this template worth pointing out is how I'm dealing with the issue of responsive images. I'm using an add-on I developed, RESS-ee which creates a variable based on your screensize which you can then use with conditionals in your templates to serve up different sized images or even blocks of content.

{ if ress>768}
	{exp:ce_img:pair src="{image}" max_width="800"}
	<img src="{made}" alt="{title} website screenshot" width="{width}" height="{height}">
	{/exp:ce_img:pair}
{ /if}
{ if ress<=768}
	{exp:ce_img:pair src="{image}" max_width="{ress}"}
	<img src="{made}" alt="{title} website screenshot" width="{width}" height="{height}">
	{/exp:ce_img:pair}
{ /if}
	

So if your screen is wider than 768 pixels, you get an image whose width is limited to 800 pixels, and if it's under that, the image is sized to whatever size your screen is, i.e. the value of the {ress} variable. The image will be displayed a bit smaller than that due to padding, but I don't think the difference is enough to worry about adding more processing overhead and adding another plugin to do mathmetical calculations on the {ress} variable.

So that's some Stash goodies being used on this site. I'm going to follow up with another post about some I've been using on other projects recently, but feel free to share some of yours in the comments.

Read full entry →

To celebrate the relaunch of the site, we're running a special during September. Anyone who books any type of work, whether it be some site maintenance or updates, a redesign, or a completely new site (feel free to pass the message on to people you know as well) before the end of September will receive a 20% discount (up to a maximum of $500).*

ExpressionEngine upgrades

If you have a site with a Content Management System (CMS) that we have created for you, it's likely that the CMS is ExpressionEngine. If your current site is older than 18 months, then its likely you're using version 1.6+ of ExpressionEngine.

A new version of ExpressionEngine, version 2, has been out for a couple of years now and official support for the 1.6+ version ends later this year, so now is the time to upgrade. Your site will continue to function just as well as it does now if you stay with the older version, but reasons why you should upgrade include:

• It is always recommended to stay as up to date as possible with your CMS to make sure it has the latest security patches and updates.
• All the latest features and technologies are now being developed for the new version. If you have a new feature you want to add, chances are it won't be possible with the older version.
• As mentioned before, official support from the makers of ExpressionEngine ends later this year.

If you'd like to book an upgrade, take advantage of our special and do it before the end of September.

To make a booking and receive the discount, please email us with Relaunch Special in the body of the message.

*The work only has to be booked some time in September. Depending on scheduling, the work may not be completed during the month.

Read full entry →

Why yes we have, thanks for noticing. After about six years, several attempts including a couple of false starts, and some that only got part of the job done, this site has finally been redesigned. Tyssen Design is now in its third incarnation since having first launched in 2005 (you can see screenshots of the previous two versions below), and the biggest changes are making the site mobile friendly (which has come to be known as Responsive Web Design), completely overhauling and enhacing the portfolio, pushing the boundaries of what can be done with CSS instead of images, and finally making the whole thing run on ExpressionEngine (EE).

It is said that the old saying ‘the cobbler's children have no shoes’ is often quite relevant for web designers/developers and their sites, with those in the business either being too busy working on other people's websites to have time for their own, or being too critical of their own work to ever be satisfied when they do find some time, and that's certainly been the case here too.

After having thought about it for some time, the first tentative steps towards actually doing something began in January 2010. That first step was to install ExpressionEngine. I'd already been using EE for several years by then, using it for the majority of the work that I do for clients, but the site was still running on Wordpress which was introduced at the time of the previous redesign in 2006.

The story over the next two and a half years (with numerous periods when I was too busy with client work to do anything on it) went something like this:

• Analyse the site content to see what should stay, go or be rewritten.
• Create site wireframes.
• Don't get anything done for seven months.
• Upgrade EE to version 2 (a major process since version 2 was a complete rewrite of the CMS).
• Update HTML for some pages including HTML5 tags that weren't around when the previous design was done, and toss around a lot of different ideas about what I wanted to do with the site and how it should work.
• Start work on some designs, but get discouraged by nothing coming out right and put it aside for a while.
• Take a completely different tack to blow out the design cobwebs, and start work on my personal blog instead.
• Update most of this site to work with EE first (except for the blog which remained on Wordpress because there was a lot of content to import and convert) so that both the new blog and this site could be run from the same installation of EE using the Multi-Site Manager.
• The new blog goes live in June last year.
• A busy period of publishing articles on the new site follows.
• Don't get anything done for another seven months.
• Import the rest of the blog content from Wordpress into ExpressionEngine and also migrate comments to Disqus.
• Redesign the logo for the site.
• Send out a survey to clients asking for feedback on their experience in dealing with us in the past. Some of this would find its way into a second rewriting of the site content that would soon follow.
• Redo site wireframes.
• Finally come up with the basis for a design of the site that I'm happy with (just header and footer).
• Work out grids and code up foundational HTML and CSS.
• Design the rest of the sections of the site one by one in the browser.
• Browser testing including mobiles and informal user testing.

And so that brings us to today with the public launch of the new design. I hope you like it. If you don't, or have noticed something that doesn't work quite right or that could be improved, please let me know in the comments (oh, feel free to let me know if you like/love it too ;)

I hope to write one or two more articles detailing some more of the specifics involved in different aspects of the redesign process, so if you have an interest in design and development sort of topics, subscribe to the feed or follow me on Twitter for updates.

Read full entry →

It's been a while since I wrote anything on this blog and it's possible that this may be the last post here because from now on I intend to do most of my writing at my new blog. This site is due for a redesign but the first part in that strategy involved setting up a new site. If that doesn't make much sense, please read the first post on the new site in which I explain my reasoning.

I'm not ruling out entirely ever writing articles on this site in the future, but it won't be until after the site has been redesigned and I don't have an exact timeline for that right now. So in the meantime, if you've bookmarked or subscribed to the feed for this site, you might like to do the same for the new one too.

Read full entry →

Yesterday I was working on the planning of a new site to be built with ExpressionEngine and was wondering about the best way to let editors link to other entries from within the body of an entry they're creating or editing. ExpressionEngine doesn't have this sort of functionality built into it by default so I asked on Twitter to find out if anyone knew of any add-ons that had been created that might do this.

One of the replies I got from Eric Barstad mentioned epEditor which does indeed include this functionality. epEditor also has its own built-in image and file manager but I don't really like some of its HTML output and there's no documentation that goes with it so I don't know if it can be configured to change this or any other settings. It seems that the internal linking feature if only available if you're also using the Structure module.

I have used Structure on more than one occasion, but I don't use it exclusively, so I began thinking about whether it would be possible to achieve what I wanted with the WYSIWYG editor I usually use, TinyMCE. Then I remembered about the External Link List URL option which does in fact allow you to provide a list of links that editors can insert into their content. Configuring TinyMCE was fairly simple, so then it was just a question of working out how to get ExpressionEngine to output a list of links that TinyMCE could read.

The process

First you need to tell TinyMCE which file contains the array of links to include. These days I'm exclusively using either the LG TinyMCE 2 or MX TinyBrowser (with TinyMCE support) Fieldframe fieldtypes for creating WYSIWYG areas. Both include a tinymce_config folder where you can create different configuration files which feature different buttons, size, appearance etc. According to the TinyMCE Wiki documentation, you add the following to your javascript configuration file:

external_link_list_url : "myexternallist.js"

To get a list or links from within ExpressionEngine, the path to myexternallist.js needs to be changed to a template on your site. So first we need to create that template. For my example, I'm creating a template group called tinymce which will contain an index template file. By default, when creating a new template group, ExpressionEngine will populate that folder with an index page saved as a 'web page'. So the first thing to do after having created the template group is to select the preferences for that group where you can change the type of the index template from web page to javascript. You'll also want to allow PHP to be parsed in the template (and leave the parsing stage as output).

(It should be noted that if you save your templates as files, as I do, even though you've selected javascript as the type, the file will be saved with a .php extension.)

Next you'll want to add some ExpressionEngine code to your template to retrieve the list of entries that you want to appear in the link list.

<?php
header('Content-type: text/javascript');
print "var tinyMCELinkList = new Array(";
?>
{exp:weblog:entries weblog="site" disable="categories|member_data|pagination|trackbacks" dynamic="off"}
["{title}", "http://www.tyssendesign.com.au/{url_title}"]{if count != total_results},{/if}
{/exp:weblog:entries}

<?php
print ");";
?>

In my example, I've selected a weblog called site which I usually use for static, stand-alone pages (i.e. not part of another section) so the URI for these pages is always site_name / url_title, but if you want to populate your list with links from other sections too, you'd just add more exp:weblog:entries tags with each one outputting a slightly different path. If you do use more than one exp:weblog:entries tag, you'd leave {if count != total_results},{/if} until the very last one, because this is to add a comma to the end of every line except for the very last one.

You can test that the template is outputting in the correct format by viewing it directly in the browser. It should output in this format:

var tinyMCELinkList = new Array(
// Name, URL
["Link 1", "http://www.example1.com"],
["Link 2", "http://www.example2.com"],
["Link 3", "http://www.example3.com"]
);

Then you just need to edit your TinyMCE config file so that it has the correct path, so in my example it would be /index.php/tinymce/index.js.

If you've followed everything correctly, you should have a Link List dropdown appear in the link popup window below the Link URL field when publishing or editing an entry. If there a lot of entries, the dropdown will be one big long list which isn't very usable, but you could perhaps make it easier to differentiate between items by adding the name of the weblog or section at the beginning. And it's certainly better than asking the editor to copy and paste a link.

Read full entry →

With ExpressionEngine you give your clients a lot of power and flexibility to update the content of their own site, but at some point in a site's life there's going to come a time when changes will be required that the site owner or his/her staff can't do themselves via the control panel. Changes to a logo or other graphical elements of the site, adding new sections or functionality, giving the site a new 'skin' or theme, or completely rebuilding from the ground up will require a designer of developer to get involved.

I'm not going to discuss the processes involved in creating a new site design (although I might do one day when I get around to redesigning this site; in the meantime Erskine Design have an interesting series of articles discussing their redesign), but rather how you go about implementing that redesign into your current ExpressionEngine site.

The different types of redesign you might need to implement could include:

• changing a single element common to all pages (or a section of pages)
• changing a single element on just one page
• changing the layout of an entire page or section
• changing the design of an entire site

And there's different ways you could approach to making the changes to the site:

• develop locally or on a different server or subdomain and then transfer to the live server
• create additional templates and/or template groups
• use conditionals within existing templates

I've used all three of the above methods and don't really have a particular favourite; each is better suited to different situations. So let's look at what some of those situations might be.

Developing locally / on a different server or subdomain

I've only used this in situations where I knew I was going to have to make changes to more than just templates, i.e, weblogs, categories and in some cases, entries; the sort of changes that can't be implemented on a live site until everything is ready to go and has been approved.

In most cases, if you're going to use a separate server or subdomain (with its own separate database) for previewing the changes to the site owners, you probably wouldn't bother developing locally as well, as then you'd have to transfer things twice. But I've been involved with one redesign that wasn't a visual redesign, one that could be noticed by site visitors, but rather a redesign of templates to make them more flexible, to cope with the changing nature of the content that had developed since the site's launch.

I exported a copy of the live site's database to work on locally, made all the changes to templates and database structure locally one section at a time and then recreated the changes on the live server. This redesign was really more about making my job easier in terms of maintenance and so didn't require the site owners to preview the changes as, from their point of view, there were no changes – they still created their content in much the same way and the public site looked no different.

That project was a bit of a special case and usually I'd recommend just developing on a server that the site owner can preview changes on. The process would still be the same though. The problem with this method is that if you're working on a site that is updated regularly you can't just reimport your version of the database into the live database (after having made a back-up first!) as there will likely have been new content added since you first exported it. If you're a MySQL whiz, you might be able to create scripts to automatically merge your changes with the live database, but I'm not so find it easier to just recreate whatever changes I've made to template groups, weblogs, categories, entries etc. on the live site via the control panel after I've tested they were work correctly on the test site. The few times I've had to do this the changes of this nature have been pretty minor anyway, so it's not been an issue.

Developing on a subdomain using the same database

I've not had to go down this route myself yet but Jamie Pittock from Erskine Design gives a good explanation of how to Create an alternative version of your ExpressionEngine website using a subdomain which accesses the same database as the main site. This method involves creating additional templates which I'll discuss next.

Create additional templates and/or template groups

If you've now read Jamie's article, you'll have one way in which you can use new templates in conjuction with a subdomain for previewing changes to a site's design. But you can also use new templates within your existing domain too. For instance, if you're creating a new design for the home page and your current home page template is /home/index/, you could create a new template in this group, e.g. /home/preview/ and set its access privileges to be viewable only by certain member groups, i.e., you'd have to be logged in. Or you could create a completely new template group, e.g. /home-new/ for the same purpose (again restricting access to logged in users).

If you're redesigning a section that has more than one template in it, you'd probably be better off creating a new template group because then you could copy all the template files to the new group and when you're ready to push the changes live, just delete the old group and rename the new one. If you stuck to using one template group with differently-named files, you might end up with a lot more files to rename. Of course, if you're creating a whole new section with all new content (or maybe repurposed content), then a new template group would be mandatory.

If your redesign involves reworking embedded templates that the rest of the site uses then you'll probably need to create a new template group for these two. Or you could get creative with a few conditionals, e.g.: { if segment_1 == "preview"} show new design elements { if:else} show the current design's elements { /if}. Which brings me to the next method:

Use conditionals within existing templates

This is the method I used for the most recent ExpressionEngine redesign I did. I was thinking originally about using a subdomain, but the site is a fairly simple brochure site promoting services and most of the templates were exactly the same except for the weblog entries being displayed. So to make the templates a bit more readable I first created an embed which contained the bulk of each template, and then reworked the existing templates to look something like this:

{if logged_in}New template code goes here.{if:else} {embed="embeds/.content" weblog="{segment_1}"}{/if}

I created a new template group for the new embeds I was going to create so it didn't clash with the current design's embeds. Doing it this way meant that only me and the site owners would see the new design while everyone else would see the old one. As it was only a simple site with only two active member groups – admins and editors – { if logged_in} was all I needed but if the site had more complex member structure, then you'd use the { if member_group} conditional instead.

So that's the way I've approached redesigning ExpressionEngine sites in the past. I'm sure there's some out there who probably use version-control systems like Git, but I haven't quite gotten around to working with Git yet. What's been your method?

Read full entry →