News & Insights

Checkered Shirts & Denim - A Year With Timber

29 Mar 2017

Jamie Sergeant

Global CEO

Roughly a year ago, Crowd started to use Timber in it’s bespoke WordPress website builds.

Along with a number of other evolutions in our Developer’s toolkit this change has lead us to some big changes in approach. Over the past year, we’ve completed a number of builds, both big and small, using Timber and we’ve learned a lot. So much so, our Web Developer Matt thought we should share some of our experience when it comes to using Timber, why we like it so much, and how it’s benefitted our Clients.

Technically, Timber is a WordPress plugin. However at Crowd, we use it more as a framework. This is because it has completely changed  the way we build websites.

Timber for Developers

 

Timber completely reinvents the way you can access WordPress data. Normally a developer would use numerous functions to access bits of information from a WordPress backend. Things like the_content() or get_the_permalink(), now while these do a grand job, they’re not very flexible. This turns otherwise professional development practice into a guessing game of remember the function. I know that when I started WordPress development, the Codex was my most viewed webpage for quite a while!

Timber gets you to separate out your data. Separate is good, separate means we know where to look to find something. Imagine if you stored everything you owned in one big pile of stuff, how would you ever find anything?

The first separate ‘pile’ is the standard PHP template file, which with Timber can just consist of 3 lines:

// index.php
<?php
    $context = Timber::get_context();
    $context['posts'] = Timber::get_posts();
    Timber::render('index.twig', $context);
?>

That’s your whole php template file, 3 lines, I’ll explain why this is good later. What these three lines above do is relatively simple.

  • Line 1, creates an array and fills it with the ‘context’ of the site. get_context() in timber fills out all of the information about the site that you might need on every page, such as the site’s title, url and navigation menus, etc.

  • Line 2, we get all the posts that WordPress tells us that should be displayed on this page and add those to the $context array, since this is the index.php template.

  • Line 3, we pass it all to a Timber method called render. This takes the data that we’ve compiled into the $context array and funnels it into the given template, index.twig.
Now we’ve got all our required data, we can use the other main component of Timber, the Twig templating library. Twig gives us a clean and simple syntax to traverse the data and output it into our templates. The template file itself is essentially just a html file, then we use the twig handles to output our data, similar to handlebars or moustache. For our example above, we could for example access all the posts of our page using or even better, we could loop through them. Don’t panic, this won’t be the WordPress loop you’re used too, it’s simply a for loop:

Keeping Things Tidy and DRY

 

But one of the best reasons in my eye to use Timber is much simpler and anyone that’s maintained PHP & HTML in the same file would probably agree. It’s impossible to keep things clean and tidy. Even starting with the best intentions, WordPress PHP templates usually fall into a pit of complex logic and messy PHP conditionals wrapping HTML. Not only is this just a visual nitpick, it also makes maintaining the code that much harder.

Every time you want to edit a part of one of these templates, you have to remind yourself of the template’s logic pattern and understand it before you know you are editing the right part. Or you just crowbar the new feature in and hope no one will ever need open that file again:

I'll just put this over here with the rest of the fire.

With Timber, we can go into a template that’s 9 months old, understand it immediately and make an edit.

Timber allows you to go further and separate out the data aspect from your components. This means you can setup a component to accept any form of data and display it in the same way, only writing that part once. Timber’s alternative to get_template_part() is:

include accepts the view’s name that you want to display and allows you to pass any data along with it. With the example above, inside the view we could call BlogPost 40865149175 Checkered Shirts & Denim - A Year With Timber and we would get the post object that we passed into the view. As this data has also been converted into a TimberPost or TimberTerm etc, it also follows a similar data structure, meaning if you were to call Checkered Shirts & Denim - A Year With Timber in the view and pass it a post object, it would display the post’s title. Or if you were to pass a term object, it would display the term’s title, creating a natural flexibility without the need for conditionals.

Crowd’s New Approach

 

In the past 12 months Crowd have been able to transform the way we deliver bespoke websites; allowing us to be faster, more flexible, and offer better value for money than before.

Rapid Component Creation

Timber’s templating engine Twig encourages developers to focus on writing simple, semantic, reusable components. By breaking down pages into components, our globally distributed team can collaborate on a build with less management overhead.

Once a developer is finished with their component, they can simply merge it back into the ‘develop’ branch and move onto the next task.

Making Content Management Easy

As well as speed, Timber has allowed us to pull off some complex yet flexible builds. By combining our go-to custom content plugin, Advanced Custom Fields, and it’s ‘Flexible Content’ field, we can create dynamic page templates.

Imagine a restaurant menu, you can ‘build’ your own meal by picking the different elements; starter, mains, sides & dessert etc. In this analogy, the developer is the chef cooking the different dishes as components. Then the client can come along and build their meal (page) using the parts created by the developer.

Dynamic page templates can load in components selectively, depending upon the content of the page. For example, on any page template we can add this one line:

// page.twig
Then in the flex-content.twig twig file, we have a simple loop that runs through all of the flexible content blocks assigned on that page and shows their relevant components based upon file name:
// flex-content.twig

With this approach, we’ve been able to create very complex sites in a fraction of the usual amount of time as the core development happens at the component level. Once those components are built, the actual build of the site’s pages and content happens in the CMS and can be adjusted as business requirements change and as the site grows.

Our Clients are no longer limited to static page templates – if they need a new page with a different layout, they simply construct it in the backend with the help of a bespoke CMS guide, without worrying about complex shortcodes or fiddly drag and drop builders.

Making Our Developers Happy

Finally the best benefit I’ve seen so far with adopting Timber is how much my colleagues love it. On a personal level, I now enjoy writing simple components, separate from PHP. For lack of a better word, it’s just nicer. I like having things neat and tidy, something as I mentioned before that is nearly impossible with PHP templates.

Everything comes naturally with Timber and Twig, it’s a simple syntax and follows the widely adopted idea of having a data ‘object’ that you pass into a static ‘view’. Jared Novack, the creator of Timber, said when using Twig for the first time:

“The syntax felt so natural I almost didn’t need to read the docs (don’t worry, I did)” - Wp Tavern, 2016
He liked working with Twig so much that he states one of the original reasons behind the creation of Timber was to “… marry Twig and WordPress…”. And I agree with him.

Get in touch with us today to talk about your marketing challenges

Get personalised marketing insights