JavaScript, learn to use JavaScript, using JavaScript in WordPress, learn to code in WordPress, WordPress coding tips, WordPress coding tutorials, how to use wp.template, using wp.template, wp.template tutorial

How to Use wp.template, WordPress’ Underscore.js Template Method

Like many developer agencies, we have a few different audiences, including clients (current and prospective) and other developers. Our aim is to serve all of our audiences, who fall on a broad spectrum of technical knowledge. Even if you’re not a professional developer, we know that many of you still educate yourselves on the technology used on your site–and we want to help! If there’s anything we cover that you don’t understand (or anything you’d like to see us cover that’s WordPress related, even 101!), please let us know. There are no stupid questions.

That said, let’s dive into something fun: WordPress’ Underscore.js Template Method, wp.template.


If you’re not yet familiar, wp.template() is a cool little JavaScript utility method that is provided with the WordPress core ‘wp-util’ script. At its core, it uses the Underscorejs .template() method.

WordPress uses this utility to load templates for all of the backbone views, but backbone is not required to use it. First, I’ll demonstrate using wp.template() with a little jQuery in order to output some JavaScript data into an HTML template, then later as a bonus, we’ll rebuild wp.template() as our own module with some additional features.

Keep in mind: this is meant to be an example presented as simply as possible, and not something you would copy/paste into production code. Please continue to follow standard best practices, including things like putting JavaScript in its own file, avoiding anonymous functions, internationalizing your text strings, etc.

By default, the method requires a script tag with an id of tmpl-my-template-name. Because all of WordPress uses this templating method/system, you will want to make sure you properly prefix your ids, so as not to conflict with another template that may be loaded on the page. That script tag should also have a type of “text/template.”1

Let’s get started:

<?php 
function zao_item_status_tmpl() {
    ?>
    <script type="text/template" id="tmpl-zao-item-status">
        <span class="zao-status" data-id="{{ data.id }}">
        <# if ( data.status.name ) { #>
            <div class="zao-item-status">
                <span class="zao-status-color" style="display: inline-block;background-color:{{ data.status.color }};width:10px; height:10px;"></span>
                {{{ data.open }}}
                    {{ data.status.name }}
                {{{ data.close }}}
            </div>
        <# } else { #>
            &mdash;
        <# } #>
        </span>
    </script>
    <?php 
}

So now we have the proper script template tag ready to go in a PHP function, with unique id, tmpl-zao-item-status. As you can see, this isn’t 100% standard HTML. You can see we are using Mustache-inspired data variables, as well as Underscorejs logic blocks.

From the Codex:

WordPress defines its own interpolation tags using the _.template( options ) to avoid incompatibility in some PHP configurations with asp_tags enabled. The WordPress-specific interpolation syntax is inspired by Mustache templating syntax:

  • Interpolate (unescaped): {{{ }}}
  • Interpolate (escaped): {{ }}
  • Evaluate: <# #>

An important bit to understand is the <# and #>, which signals the opening/closing of raw JavaScript output, so you can do things like logic operators (like the if statement in the example above). You can also see we’re taking advantage of the unescaped interpolation when we output the data.open and data.close parameters, since those will contain HTML and we don’t want that escaped.

At this point, let’s hook into WordPress so we can see this in action.

Add this snippet somewhere in your theme’s functions.php file, or a custom plugin:

<?php 
// Output this at the top of the post-edit screen just below the title input.
add_action( 'edit_form_after_title', function() {
    ?>
    <span class="zao-status"><span style="display: inline-block;background-color:red;width:10px; height:10px;"></span> Please wait...</span>
    <?php 
} );

If you go to a new-post or post-edit screen, you should see something like this:

That doesn’t do much for us. We’re going to need some JavaScript setup to grab our updated status and update the status markup. To simplify, we’ll simply fake an AJAX request by setting a short delay. You could also using something like the Zao Mock API to mock some API requests/responses.

The JavaScript:

<?php 
function zao_item_status_js() {
    ?>
    <script type="text/javascript">
        // Wait for the dom to be ready..
        jQuery( function( $ ) {

            // Get the template function corresponding to our template markup.
            var template = wp.template( 'zao-item-status' ); // uses script tag ID minus "tmpl-"

            // Let's wait a tick, so we can see it go from yellow to green.
            setTimeout( function() {

                // Let's fake some data (maybe this is data from an API request?)
                var tmplData = {
                    id: 1,
                    status: {
                        name: 'Success!',
                        color: 'green'
                    },
                    open: '<span class="status-name" style="color:green">',
                    close: '</span>'
                };

                // Send the data to our new template function, get the HTML markup back.
                var html = template( tmplData );

                // Now let's replace the contents of the existing markup with our updated template markup.
                $( '.zao-status' ).html( html );
            }, 1000 );
        });
    </script>
    <?php 
}

The code comments should be self-explanatory, but to recap:

  1. Call wp.template() with the ID of the script tag we created earlier minus the tmpl- prefix
  2. Fake an API request by setting a one second delay
  3. Generate an object of data and pass it to our new template function which returns the compiled HTML
  4. Take that HTML and replace the existing.

We now have the JavaScript output in a PHP function, which we can hook into the footer. We have almost all the pieces we need to make this work, so let’s update our edit_form_after_title anonymous function:

<?php 
// Output this at the top of the post-edit screen just below the title input.
add_action( 'edit_form_after_title', function() {

    // Hook in our template script tag to the footer.
    add_action( 'admin_footer', 'zao_item_status_tmpl' );

    // Hook in our custom JS for updating the status.
    add_action( 'admin_footer', 'zao_item_status_js' );

    // Now, enqueue the WP util script so we can use wp.template
    wp_enqueue_script( 'wp-util' );

    // Make the initial output have a yellow status square
    ?>
    <span class="zao-status"><span style="display: inline-block;background-color:#ffe24d;width:10px; height:10px;"></span> Please wait...</span>
    <?php
} );

With that, we should see the status go from yellow (“Please wait…”) to green (“Success!”).

wp.template success! gif

wp.template success!

Hopefully, this basic example will help you get started using wp.template() in your own work, but if you have any questions, please leave comments below.

The full output for this example snippet can be found here.

If you’re still with me: now that we’ve covered the basics of the WordPress’ utility, you might be interested in a similar utility based on wp.template() which I created, _templatize. This script simplifies the above steps a little by combining the template-getting and data-sending, and also provides a feature that allows creating a template by passing it an HTML string (vs being tied to a tmpl- script tag in the dom). As a bonus, you can see the above snippet updated to use _templatize here.


  1. The key is that it shouldn’t be type="text/javascript" (or no type specified). More info 
Zao, learning to code, WordPress developers, WordPress ecommerce, learn to build WordPress, learning to build in WordPress, learning WordPress, how to use WordPress

Five Things I Wish Someone Told Me When I Learned to Code

I haven’t been in the software development industry for loads of time, but thanks to some amazing people who championed my growth, I slingshotted in quicker than some other peers who did it all on their own. (Props to you individuals, by the way, that wrestled it all out by yourself–you are unstoppable!)

After thinking a bit about my experience I came up with five things I wish I had known when I started developing:

1. It’s 100% normal to feel like you’re drowning

I stumbled my way into coding; it initially started as a hobby.

At first, everything was bite-sized and easy. I was blissfully unaware of how little I knew. Once that bubble popped, my lack of knowledge was overwhelming. Everywhere I turned there was something I could not do.

I remember the first time I tried poking around in the Codex. I ran away thirty seconds later because it all seemed like Greek! I literally did not have the capacity or supporting framework to “get it.” I wish I had known in advance how often it would feel like drowning and that it was fine.

2. Just Keep Learning, Just Keep Learning

Go after all the low hanging fruit that you can. It might seem like a waste of time to spread yourself so wide, but if you are truly a newbie and have no context for the developing world, the wider you go, the wider your foundation will be. Although you won’t be fully aware of it at the time, you’ll fill in the gaps of your understanding so you can level up.

When I felt like I was drowning, I continued to chip away at the pieces I could master and walked away from the pieces that made no sense to me. It paid off in the long run.

You can only handle so much drowning before you give up. By moving on, I kept my overload threshold in the green and experienced small wins that boosted my confidence.

Every so often, I would return to the Codex and give it a go again. When it still wasn’t useful for me, I moved on. I remember the day I was working on something, jumped around several Codex pages…and realized it made sense to me. Suddenly, the Codex was in my toolbox. By expanding my understanding in other areas, I built a framework that allowed me to tackle the previously impassable problems.

I wish I had given myself the permission earlier on to move on when it suited me. While there is a satisfaction to mastering something, I have found the field to be so wide, deep, and complex that it is rare to master something the first go around. Spending all your resources to come out utterly defeated is more costly than saying, “I don’t get it, so I’m going to move on to something else and return to it another time.”

It changed my experience from perpetually drowning to recognizing that I need to play in the wading pool a bit longer.

Note: This should go without saying, but don’t put yourself in a situation where you have committed to do something that is beyond your abilities for a client…because then, you don’t have the permission to walk away from it.

3. Hone in on your trusted sources

The internet is amazing and Google a robust resource, but not all of the resources out there are reliable.

As helpful as Stack Overflow is, quality control is not always a guarantee. Many of the solutions provided are hacks, instead of the industry standard approach to the problem. When you’re starting out, it’s hard to know who you should and shouldn’t listen to. It’s imperative to find good sources that you can soak up. This might require reaching out to experts in the business and find out who they trust.

My introduction to coding started with a free online coding tutorial resource. It was great for the most basic things. However, the further I got down the rabbit hole, I discovered that some of what they were teaching was completely wrong. Fortunately, friends who are professional developers pointed me to some credible resources.

It is hard to unlearn something foundational if you learned it wrong the first time. You only have so much time and you can spend eternity reading about all the different approaches.  Find approaches you can build on so it’s not considered time wasted later.

Team Treehouse proved to be an invaluable resource for me. They are trustworthy and they are actually good at teaching–a huge bonus because not all developers are good at breaking down what is natural for them into bite sized pieces for newbies.

4. After you learn it, build it

I cannot tell you how often I’d go through a tutorial and think to myself, “This makes complete sense. I get it!”

I followed with the tutorial and find myself at the end with the desired product. Ta-da! I learned it, right?

More times then I can count, I noticed that stepping away for the weekend would be enough for me to completely forget it. I found that after completing a tutorial, it was really helpful to go through and build the entire project again without the tutorial.

That was the real test of what I had actually learned, versus what I was regurgitating. It is great to follow along with a tutorial, but that’s only the first level. You need to practice it several times before you get it. The more you build it, the more muscle memory you create.

I wish I rebuilt the same things over and over instead of moving on to the next skill before mastering what I initially focused on.

One final point on building: going through other people’s tutorials is a great way to gain knowledge. However, reproducing something that already exists does not activate your creative thinking.

I discovered if I tried to implement a skill in a different context than the tutorial, I understood the steps to build one specific solution, but didn’t always grasp the concept in its entirety and how it could be applied to different situations. After you master a project on your own without the tutorial, try it again but with a different outcome as the goal. This will keep the skill pliable for you.

5. Get excited about pet projects

One of my biggest struggles when learning to code was that I had no idea what to build on my own. I desperately wanted to practice and try things out, but I had zero idea where to start.

As I mentioned earlier, you can only drown for so long before you give up. The antidote to this is passion. If you are really passionate about what you are building, you will have more endurance to push forward when the going gets tough.

Additionally, the great things about pet projects is that they are often side projects. You probably have other pressing matters that need attending, and so your project will get put on the back burner. This is fantastic!

When you return to it you will see your work through the eyes of a new developer. You will learn first hand the importance of commenting because you’ll probably have forgotten about why you did some of what you did and what all the moving pieces do.

As you improve your skills, you’ll find that when you return to your old work, you’ll be embarrassed by some of your approaches. The upside: you’ll have an opportunity to practice refactoring. These skills are super important and less painful to learn on your own project then in a group project where you’re impacting your peers and clients.


I wish I had known all of this sooner.  What about you? What things do you wish your baby developer self knew?