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 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.
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.$context
array, since this is the index.php template.$context
array and funnels it into the given template, index.twig
.
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:
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:
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.
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.
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.
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.
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, 2016He 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.