Timber, 3 Benefits of Using it in WordPress Development

Timber is something that we've been excited to talk about for the past month.

We love using WordPress, (if you haven't already noticed), and combining the CMS of WordPress with the Twig templating language via Timber has taken our development process to all new levels.

We now have a structured layout for our front-end codebase and our data/logic codebase.

By using Timber, we have kept our files focused on a singular task, we are no longer mixing presentation and logic. Instead, the two exist separately and communicate with each other to render our site pages.

Why didn't we start sooner?

Since getting to grips with Timber, this has been a question that I keep asking myself every day!

In all honesty, prior to Timber, our development stack worked well.

We didn't want to change it, we understood our code, our structure and felt confident in the quality of products we delivered.

Which often is one of the biggest issues with development, getting comfortable because 'it just works' is the wrong reason to continue using a development process.

However, as part of our ongoing efforts to experiment and research the latest tools used in our industry, we thought best to take the plunge and see what the hype was all about with Timber for Wordpress.

Benefits of Using Timber

Before we dive into each benefit in using this development stack, we'll first list them out!

People love lists right?

1. A clear objective when developing (front-end and back-end)
2. Flexible layouts that work with other development stacks
3. Improved security in comparison to standard WordPress development

A clear objective when developing (front-end and back-end)

Website development when boiled down to it's simplest form is problem-solving.

Problems at first may seem big and intimidating to take on, finding a solution can take minutes, hours or days depending on the task at hand!

The easiest way to approach problem-solving is to take the large task (100%) and break it down into medium tasks (10% each). Then see if you can break those into even smaller tasks (1% - 3% each)!

Now you've got your fair share of tasks ahead of you, instead of the one.

However, the tasks are no longer huge and scary, instead, they are approachable, measurable and give you milestones of progress made.

Now that I've got that tangent out of the way, let's see how this relates to Timber.

Instead of seeing a page as a task, let us say a large task perhaps?

Now instead of looking at it as one large task, let us look at it as two medium tasks. Logic and Presentation.

You see, Timber keeps our familiar .php files for our website logic. Carrying out queries, functions and processing data to pass over to our presentation files.

Once you have your logic generating data, you can present it with the use of .twig files.

Twig is a powerful templating language that allows for a strong focus on the markup structure. Using a handlebar syntax {{post.title}} to import any data generated from your PHP files.

If you've ever had to use handlebar syntax in JavaScript, you'll be familiar with the syntax formatting of Twig.

A Visual Example

Single.php

$context = Timber::get_context();
$context['post'] = new TimberPost(); // It's a new TimberPost object, but an existing post from WordPress.
Timber::render('single.twig', $context);

Single.twig

{{post.title}}
{{post.content}}

Output HTML

<h1>The Empire Strikes Back</h1>

<p>
It is a dark time for the Rebellion. Although the Death Star has been destroyed, Imperial troops have driven the Rebel forces from their hidden base and pursued them across the galaxy.
</p>

Hold your horses

Now if you're familiar with WordPress, the above syntax may seem intimidating.

You may be trying to figure out what is going on and why we are using some new function syntax instead of the usual "the_title" and "the_content".

To put it in it's most basic terms, the PHP is first creating a variable $context.

Once we have the $context which may have been defined by our functions.php file, we then grab the 'post' object.

The post object is the current page or post you are targetting. Say you were coding in the single.php file, the post object would be the individual post.

The post object has a tonne of values that we can access. For a full list, check out the official timber documentation - https://timber.github.io/docs/reference/timber-post/

Once we have our context, added the post object to the context, we then specify what twig file to pass all of this information into. In the examples case, we use single.twig.

Still with us? If you can understand the PHP logic, the rest of the templating syntax will make sense.

Now that we have our data importing into the single.twig file, we can reference the data as using the context variable property, in this case 'post'.

So post.title would be the property of the post object.

When the page renders the HTML, it will replace post.title with the post's title.

Flexible layouts that work with other development stacks

Redefining how data is used in WordPress allows for flexibility in your developers choice of process and stack.

If a developer has no experience with WordPress, it won't take long to understand the syntax of passing data to your front-end view and calling it with syntax such as {{post.title}}.

In fact, it is becoming more common across templating frameworks to use the handlebar code syntax.

We at NoFace love pattern libraries, our first choice of pattern library frameworks is Fractal. Fractal allows us to implement theme pattern libraries through the use of front-end languages such as HTML, CSS and JavaScript.

The reason we mention this tool is that as well as the common front-end languages, Fractal supports the use of handlebar syntax to pass data in from configuration files.

By creating a consistent use of the handlebar syntax across our pattern library and our theme development ensures that the team isn't 'flip-flopping' between languages and has a common relation between the theme and the pattern library, creating less work for us!

Improved security in comparison to standard WordPress development

If you're creating a WordPress site, you'll commonly call on database queries, user authentication and other data access methods which when manipulated in a malicious manner could cause issues for you and your client.

By separating the backend logic and front-end rendering of the site, you are creating less accessible routes for hackers to attempt to exploit.

As well as this, Timber will auto escape HTML Unicode characters and other special characters to prevent common PHP exploits on your site.

Round up

We love Timber, we love our new twig files and how flexible it makes our WordPress development process.

This post doesn't cover all of the benefits of using Timber in your workflow, but a simple search on Google will return a sea of good feedback from other developers.

We recommend giving Timber a go if you haven't before!

If you have used Timber, and want to share your favourite feature, or how it has benefited you and potentially your team, leave us a comment below.