Tom McFarlin

Software Engineering in WordPress, PHP, and Backend Development

Page 12 of 427

WordPress Has No Templating Language (and That’s Okay!)

Most of us who have worked with WordPress for the last decade or so have lamented the lack of a templating language whenever it comes to front-end logic.

There are teams that have done this, such as Roots, and it’s admirable. It’s opinionated nature can make it incredibly easy to work with a project or more trouble than necessary. It depends on the project, the team, and so on. But I’m not here to talk about Roots. (Check it out if you have time.)

Anyway, as with most things in development, compromises can be made. Though there isn’t any native templating built into WordPress, this doesn’t mean we can’t introduce something approximating that when it comes to our frontend functionality.

First, remember that WordPress has a convention that if you prefix a function with ‘get’, then it means it’s going to retrieve the value for you, but it’s up to you to do something with the value. For example, get_the_content() will retrieve content for the post in question but it won’t actually render it. On the other hand, the_content() will retrieve the content and will render it.

I mention this because if you’re going to separate your logic in a similar way, it’s important to follow this convention (though I’m personally partial to the PSR12 way of naming functions with camelCase).

Secondly, remember that we’re now writing code in a time where it’s more than acceptable to mix multiple languages into a single file. This means that one file may include HTML, JavaScript, CSS, and maybe even some type of PHP. This isn’t how it’s always been and it isn’t how it has to be, but React ushered a lot of this into the mainstream.

All that to say, while it’s completely possible to set up your templates that look something like this:

<?php // Check $userId is set or can be retrieved in whatever way works for you. ?>
<li>Phone Number: <a href="tel:<?php echo get_user_meta($userId, 'phone_number', true) ?: 'Not Provided'; ?>"><?php get_user_meta($userId, 'phone_number', true) ?: 'Not Provided'; ?></a></li>
<li>Email Address: <a href="mailto:<?php echo strtolower(get_user_by('id', $userId)->user_email); ?>"><?php echo strtolower(get_user_by('id', $userId)->user_email); ?></a></li>

This is noisy and if you want to use those same function calls again, you’ll have to make sure they are used every single place throughout your codebase exactly as they are called here. Maybe that’s okay, maybe not.

If you’re building a large site or any application, it’s going to create more work than not, though.

You can separate the logic a bit so even though it’s not a full on templating language it still separates some of the rendering logic so the frontend isn’t so visually noisy. Plus, it allows you to update the code in one place rather than in every single template that uses it (yes, I know we could use partials or even some other smaller component of a partial that can be reused throughout the project but then you get into potential markup or design challenges with doing that).

This will make sure that the function is retrieve only the data that you need and leaves the rest of the markup and styling to be done elsewhere. Even better, it can be used in templates, in partials, or in fragments (or whatever they are called right now).

Anyway, this means that your template may look something like this:

<section id="contact-info">
    <ul>
        <li>Phone Number: <a href="tel:<?php echo getPhoneNumber($userId); ?>"><?php echo getPhoneNumber($userId); ?></a></li>
        <li>Email Address: <a href="mailto:<?php echo getEmailAddress($userId); ?>"><?php echo getEmailAddress($userId); ?></a></li>
    </ul>
</section>

And then the code behind the function call looks something like this:

/**
 * Retrieves the phone number associated with the specified user.
 *
 * @param int $user_id The ID of the user to retrieve the phone number for.
 *
 * @return string|false The phone number of the user, or false if not found.
 */
function getPhoneNumber(int $userId)
{
    return (
        get_user_meta($userId, 'phone_number', true) ?:
        'Not Provided'
    );
}

/**
 * Retrieves the email address associated with the specified user.
 *
 * @param int $user_id The ID of the user to retrieve the email address for.
 *
 * @return string|false The email address of the user, or false if not found.
 */
function getEmailAddress(int $userId)
{
    return strtolower(
        get_user_by('id', $userId)->user_email
    );
}

And though you’re not straight up calling a template in terms of using brackets and the properties of a model (which you technically could, but that’s another post), you’re at least still able to get the raw data with which you can work in your template.


Maybe the methodology discussed in this article strikes you as out of date, old, or even unfamiliar. And despite how I may have come off, I’m not necessarily against mixing languages in a single file, but I do think it’s important – in an application that has no templating language – to do what we can to incorporate a pattern of development that meets us half way.

It doesn’t require third-party dependencies and it doesn’t require a paradigm shift. Just keep the functionality required for retrieving and returning the data separate and have the presentation call said function. Then mark it up and style it however you want.

WordPress is a Foundation, Not a Framework

In 2016, I wrote a post about why WordPress is a foundation, not a framework. Though I don’t participate much on social media any more (I certainly lurk, but don’t converse), I’ll see things I’ve not thought about, things I’ve thought about, and things worth reconsidering.

And in an effort to continue writing more regularly and to revisit things I’ve previously written (because that’s healthy, right?), I thought I’d address something I recently read:

We need to stop thinking of WordPress as a CMS and start thinking of it as a framework.

There’s a litmus test as to what defines a framework and what defines a foundation

  • A framework doesn’t function until someone builds something using the tools it offers.
  • A foundation is an application that can run on its own without any additional functionality but it offers APIs that allows developers to build things on top of it.

To that end, WordPress is a foundation. Not a framework.


Note: It’s not that I don’t want to attribute the quote to the specific person out of disrespect; on the contrary, I’ve seen enough subtweeting and general unpleasant discourse online that I don’t want to spur that. It’s not about talking about the person; it’s about talking about the idea.

Yes, They’re Still Exciting: Headless WordPress Applications in 2023

In r/ProWordPress, OP asked a few questions around Headless WordPress in 2023. One question stood out the most:

Developers who develop headless WordPress sites, how are things going in 2023?

Given all that’s happened within the core WordPress application over the last few years – that is, with the Block Editor and Full Site Editing – it’s not only easy to lose sight this is functionality built into WordPress but there’s likely a portion of people onboarded into WordPress development who do almost nothing with this type of work.

Even with all of the excitement around the new editing tools and how much JavaScript has been introduced into WordPress core, building headless applications with WordPress is still something I find to be one of the most powerful aspects of working with the application.

Continue reading

The Deep Life: Me, A Case Study

Back in June, I wrote an article called Living Deeply, Writing Broadly and tagged it under TDL. I haven’t done much with that particular tag since writing that post, though.


Earlier this week, a close friend sent me the following text (with some context removed for the sake of keeping it concise):

Clear writing gives poor thinking nowhere to hide. A lack of understanding, which was previously invisible, becomes suddenly visible. You can’t simply take a few minutes here and there, get the gist of the problem, and expect to have clear writing. It doesn’t work that way.

How to Think Better: The Skill You’ve Never Been Taught

Not so long ago I used to write daily even if it wasn’t for this site. I’d write in a journal or in a notebook or a field guide just to get some thoughts done.

Not everything worth writing is necessarily worth publishing, but perhaps nearly everything deserving of serious consideration is worth putting into writing. At least in terms of working on or working out an idea.

Couple that with a recent podcast from Cal Newport in which he breaks down what he calls The Deep Life Stack along with many of the things I’ve been working to practice in my day-to-day for the last couple of years and you have somewhat of a structure for how I’ve been trying to organize this particular phase – or season, as some say – of my life.

If you listen to any of Newport’s podcasts or any others that talk about this type of stuff, they often cite a case study or multiple case studies throughout their episodes or book. So why not take the material I’m learning and turn myself into my own case study?

Continue reading

On the Market for Utility Plugins

Years ago, I started writing small utility plugins that helped me maintain any given task on managing this site or projects that I was building for others.

Some of these plugins I’ve kept just for me because they are quickly put together and built in such a way that are geared towards this site; others I’ve open-sourced, shared, and/or installed on other sites because a person with whom I was working was interested in the functionality or because it was niche enough that it solved a single problem they didn’t want to deal with.

Many of these have been archived because I didn’t need them, didn’t want to maintain them, or no longer had a use for them. Case in point: Page Template Dashboard.

But these types of plugins, at least for me, date back over a decade. The first plugin I ever released in the WordPress Plugin Repository was called Tipsy Social Icons. This year, it will be 11 years old (not that I maintain it anymore but get a look at the plugin page to get some good social web nostalgia).

It was written one afternoon when there was a rare snow storm in Georgia and we couldn’t go anywhere. 🙃

Anyway, there’s something to be said for large plugins that greatly extend WordPress in all kinds of ways such that we practically have full applications running within WordPress that help users do things far beyond posts, pages, taxonomies, and user management. Be it something that runs in the browser, something that serves as a headless application, or something else. There’s a reason WordPress can be referred to as the operating system for the web.

But there’s also something to be said for small tools or utilities that do something either that require user interaction or that take care of something behind the scenes. I see the occasional discussion about this [whenever I am lurking] on Twitter, in newsletters, or in other Slack channels [in which I am lurking].

That is, people seem to be interested in them, people want to build them (or they want them built), but they seem fewer and far between given the size of other plugins that are available.

So it raises a question: Where are they? Is there a market for utility plugins? Are they overshadowed by larger projects? Is it too hard to find them given the way GitHub or the WordPress Plugin Repository is structured?

These aren’t loaded questions; instead, they’re general musings on the whole thing.


For those of you reading this who have been in WordPress for a long time, you’ll remember some of this and for those of you who may be newer consider it a cautionary tale:

  • Years ago, we had what was essentially a race to the bottom for product pricing. The idea was something like “s/he who sells the most at the lowest price wins.” This could be for plugins but it started with themes.
  • Then we moved in the subscription model which we see every where both inside WordPress and outside of WordPress.

It’s not that I need an lesson on economics to understand this dynamic but there’s also alternatives especially in projects that aren’t the backbone of a person’s livelihood or their business.

People talk a lot about “side hustles” and each person has their own motivations for having them. (That is, some want to turn them into full businesses, some just want a hobby.)

This is where I think this idea of utility plugins come into the picture again (granted, I don’t think this is an elegant term to describe a product but that’s beside the point – for now).

Instead, I think there’s a small model by which extremely simple plugins can be marketed for a specific problem and sold at a price that doesn’t require a subscription, that doesn’t drain a person’s wallet, and that helps them when using WordPress by simply doing a job that keeps them from having to do it.

Further, “extremely simple” may be an overloaded phrase. Some of the simplest solutions are not in how few lines of code or how much is going on behind the scenes but how simple it comes across to the user.

  • Does it require activation, user input, settings values, and so on
  • Does it just require activation?

Alternatively, simple plugins can be just that. It might be an anonymous function that’s associated with a hook that adds or removes a single UI element.

Despite talking semantics here, that’s not what I’m after. Instead, I’m talking about a market for utility plugins where a utility plugin is defined as a single plugin that’s activated and does one thing with minimal user input and that enhances or streamlines their work within WordPress.

It does a job they don’t want to do (maybe once, maybe multiple times, maybe always), stays out of their way, and allows them to focus on what they need or what they want to do.


Personally, I think there’s a market for them. I don’t know how large or how small it is nor do I think there’s a consistent price point at which they can be placed (how do you value someone’s time when it’s a single WordPress installation that’s a hobby or someone who maintains an entire set of WordPress installations?).

There are ways to test this, though. And I’ve a list of ~25 plugins that I’d love to actually try to implement.

« Older posts Newer posts »

© 2025 Tom McFarlin

Theme by Anders NorenUp ↑