
The Loop is really the crux of WordPress – it’s vital, central, key and, in many ways timeless – but it is also a source of confusion and for many frustration – so let’s strip it back to it core purpose to try and understand its role more clearly.
WordPress – at least in its early versions – was built as a blogging tool – it provided simple content management for posts, images and links in the admin and the themes were built to show lists of posts in reverse chronological order and single posts – and not much else.
The default home page of all classic themes – index.php
– was built around The Loop – which looked for a defined number of the latest blog posts and listed them with a thumbnail and some excerpt text – there was also pagination to dig deeper into the post past and archive templates to list the same post content grouped by taxonomy objects – categories and tags.
Today, WordPress ships with a powerful REST API, handles multiple data types and has a huge ecosystem of plugins, themes and developers which continually push the boundaries to produce complex applications and tools.
The Loop
Below is a classic example of a WordPress loop from the Codex documentation site:
Of course, this is a very simple example and gives very little control over the format of the output data – other than styling the_title
in h2
tags.
It is also possible to move the entire loop to a function – perhaps called the_loop
and call inside the template, allowing some of the data control to be moved away from the presentation layer of the application – but in some instances this can cause problems because WordPress relies on global objects to generate and validate some data.
WordPress Core team try to release a new default theme most years – the latest version is handily called 2020 – and below is the code from the index.php template – the default application landing page for most uncustomized sites:
We’re not going to go into detail about what each block of code does, but we can see somewhere in there that the_loop is still at the core of how this template – and WordPress – works.
One thing to consider is that 2020 – like most WordPress Core themes – is designed as a generic solution, to fit as many use-cases as possible – the output can be modified via child themes and functionality can be changed via plugins – but at first glance, it’s a pretty complex collection of code and not very user-friendly, especially for less experienced developers.
Willow Way
As an alternative approach, we have written our own Template Engine – called Willow – and here is a very simple example of how we can generate the post loop:
{~ post~query ~}
Of course, Willow is not magic, so it needs more than this small tag to gather, format and render the post data.
Willows can be written with all configuration options passed in argument tags, but in most cases and especially when you re-use tags, it makes much more sense to store configuration in a file – as the example post.php
below shows:
The logical part of gathering and formatting data is handled by Willow getter methods – in this case get/post.php – which you can study in the GitHub repo here – Willow comes bundled with data collectors for many standard WordPress features, as well as ACF field groups and can be extended easily to collect and return data from any source.
And – as a final comparison – below is an example of a complete index.willow template form one of our projects:
Each Willow can have it’s own configuration file or options can be grouped together by context
– for example the settings for post title, except and content might all sit in the same post.php
configuration file.
All approaches have pros and cons, and with enough exposure to any particular method, we are likely to accept that things work in the way they are presented, but it is also possible to change the default way that we work, if we take the time to understand more deeply the tools that we use and the how we can best apply them.
Happy coding đŸ™‚
No comments on this article yet.