Zao Mock API: A WordPress Plugin for Testing API Responses

Right now, REST API usage is at an all-time high, especially now that WordPress, which powers 27% of the web, has its own REST API. And it makes absolute sense. There are so many great services and data sources in the world wide web, and there has been a need for those sites/services to “talk” to each other for almost as long as the web has been a thing. REST APIs have long been a subject we are passionate about at Zao.

If you’re not familiar with REST APIs, I recommend doing some reading, and bookmark this article (and plugin) for later.

Continue Reading

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 
development retainer, when should i put a developer on retainer, should i have a developer on retainer, should i have a programmer on retainer, hiring a programmer, when to hire a programmer, hiring a programmer for my business site, business site development, eCommerce development, WordPress plugin development, build a plugin for my business, build a WordPress plugin for my business, build an eCommerce site, hire someone to develop an eCommerce site

Why You Pay a Premium for Web Development Retainers

When folks think about hiring a service provider, they’re usually looking for help achieving one particular goal.

Whether it’s hiring a lawyer to draft a will, a contractor to remodel your kitchen, or a developer to build your website, the goal is to finish one specific project and set you up for future success on your own.

But what if you know you’ll need ongoing support from your chosen provider? What if you think this project isn’t the only thing you’ll need their expertise on?

That’s when you want a retainer.

What’s a retainer?

A retainer is a fee paid in advance to a service provider to secure their services. People most often associate retainers with lawyers, but all kinds of service providers offer retainer accounts, including developers. While a developer can build your site and send you on your way, retaining a developer’s services on a long-term basis is a fantastic way to make sure your technology is being handled by an expert as your business grows.

How web development retainers help you

Most developers offer a broad variety of services: building and designing websites, building apps, conducting code audits, debugging code, updating your site (particularly relevant if you’re on WordPress and things fall behind), and more. As your business grows, your technological needs will change. Justin talked about this in his most recent post covering code audits:

…Some plugins do well if they’re on a site that has no users logged in. However, if that same site has switched to a subscription model, it won’t have caching layers that allow the plugins to run as smoothly. Your client may not know this difference. All they know is that they made the switch when they needed to shift their business model. They didn’t recognize the impact it would have on their technology.

As your business changes, issues like the one outlined here may crop up–without you understanding what is happening or how to fix it. If your business goes through a sudden growth spurt, your site may not be able to handle the traffic or engagement, which could be financially devastating. And if your site goes down, if you don’t have technical support, you’re on your own, since most developers can’t drop everything they’re doing to work on your site (or if they can, they’ll charge a pretty penny for it).

Having a technical expert in your corner ensures that your technology will grow alongside your business. It means that you can either outright avoid or quickly ameliorate any pain points that arise, which makes your life less stressful, your business run smoothly, and your clients happy.

But retainers are expensive!

Some folks argue that retainers are a waste of time, since you pay for the hours upfront and if there isn’t work to be done, not all of those hours may be used. Although the nature of transactions like these is how they’re outlined in terms of hours, thinking of it this way is too simple. You’re paying for so much more than just the hours.

Priority and access

If you’ve ever desperately needed tech support and tried to find it last minute, you’ve likely discovered how difficult it is to get it done as quickly as you need it. If you have managed to find someone to handle it, they likely charged you a ton of money to handle the immediacy of the request.

Setting up a retainer with your web developer means paying for priority. They’re turning down other work in anticipation of being available to you.

At Zao, in particular, we provide a higher level of access to not only our time, but also, in immediacy of response. That different level of access means reaching us during a broader range of hours (particularly good in an emergency), as well as a quicker turnaround.

A working knowledge of your business

Any developer who is working with your site should make it their priority to know your business. They need to know your technical pain points and goals, of course, but they should also keep your broader business goals in mind as well. When you hire a developer on retainer, it means you’re keeping a consistent tap on someone who filters your professional objectives through a technical lens. It means they can anticipate your technical needs and potential obstacles you may face in the future–and help you plan for it.

It also means you have someone who knows your code inside and out, so fixes are a lot quicker and easier. It means your development is consistent in quality, delivery, and expectation.

No DIY worries

How often do you get your oil changed? Tires rotated? Do you do it yourself, or do you hire a professional to handle it so that you don’t have to worry about getting your hands dirty?

Maintenance doesn’t just apply to cars; it applies to your technology, too.

Of course you can handle the WordPress site updates yourself, but do you really want to add something to your ever-growing to-do list? And do you have the technical capability to handle it if an update shuts down your site?

That aforementioned access and expertise comes into play here, because with a developer on retainer, you can build maintenance into your agreement with them. Not only can they handle the basic tweaks to keep everything running, but they also have the skill and time dedicated to you to fix anything should an update go awry.

Retainers can be spendy, but they’re an investment.

Rather than handing over your arm, leg, and one extra pinky toe to pay for an urgent fix, retainers are an investment in technical partnership that prioritizes your emergencies and needs. They may seem spendier in the long run, but when you consider the cost of emergencies, it is pennies in comparison.

A one time buy is for vendors, but retainers create technical partnership

Paying for a retainer means essentially paying someone to join your team. One of our values is family, and that extends not to just our families, but to creating a kind of family in our professional sphere. We want to welcome our clients in, and do more for them than just build something and kick it out the door. We like offering more than a drive by snack; we want to have a family meal.

When our clients hire us on retainer, they’re paying us to take some of the focus off of our business to focus on theirs. We take their dreams and big ideas and translate them into something that has a tangible impact on their business. That takes time, priority, and strategy that simply isn’t possible for a short-term project.

We guide as they scale. We care about the success of their projects and business as much as they do. Like any family, we love being able to celebrate our clients’ successes as they happen just as much as we want to dig in and help when things fail.

what is the discovery phase?, web development, wordpress web development, what does the discovery phase include?, what does discovery web development mean?, what should a web developer do, what does a web developer do, zao wordpress web development, zao wordpress ecommerce development, Zao WordPress plugin builder, Zao code audit

What is the Discovery Phase and Why Do I Need It?

If you are one of our potential clients, it’s likely that you have been around the block and have heard the term “discovery” more times than you can count. The discovery process is the first step taken in moving from a prospective client to an actual client; it’s the time when a professional digs in deep, asking pertinent questions and figuring out what the client is seeking.

From what I can tell, this is becoming a standard in our industry. Why? Because building software (websites, apps, et al) is hard. One of our industry’s running jokes is that every project will be under-scoped and over-budget.

According to Hofstadter’s law, “It always takes longer than you expect, even when you take into account Hofstadter’s Law.”

This truth is magnified when estimates are requested before understanding the entire scope of the work needing to be done.

There are actually many reasons projects go over budget or time — some positive and some negative:

  • A key requirement is missed during the requirements-gathering phase.
  • A simple line-item balloons into days of work (For example,”Import items through ACME API” turns into days of digging through a massive API ebook PDF)
  • Crucial information is brought to the table late in the game. (“By the way, that API requires NSA security level clearance passed through a token.”)
  • Developers discovered a missed user-case problem and solved it without bothering to set up meetings/discussions/approvals.
  • A feature was given a bit more pizzazz than was scoped. (Developers get carried away!)
  • Straight-up underestimation of the work needing to be done and what it is going to take.

Building software is hard, but estimating software is even harder. After all, it’s rare for us to build the same thing twice. Though we work with WordPress, it’s actually quite impressive how little of our work deals with the actual blogging component. WordPress has the basic, expected features on lockdown, and so what we end up building is ways to make WordPress do something unique.

Uncharted territory

Let me remind you: Christopher Columbus’ intentions were to sail around the world to establish a shipping route to Asia. He estimated the distance to be about 2,300 miles (the true figure was much more vast at about 12,400 miles). This idea was controversial at the time; the prevailing theory was that the earth was flat. So Chris was spot on about the earth being round, but what he completely missed in his estimations was the existence of an entire continent between Europe and Asia. The United States of America is an example of massive scope creep.

What’s the point?

If we opt for skipping the discovery phase, we’re likely to run into this unfortunate truth: The short term gains are not worth the long-term pain.

At Zao, our goal is to give your project the best chance of success. The primary way we can help guarantee that success is by providing an accurate budget and timeline estimate (with some margin). As you have established by now, the primary way we establish an accurate estimate is through a discovery phase!

So enough about why…let’s talk about what.

What exactly is a discovery phase?

There are actually many ways to define a discovery phase, but the discovery generally involves gathering requirements, reviewing goals, identifying what is working, and what isn’t.

In order to do the work of discovery, we need access to all the relevant resources, which can include things like:

  • Existing scoping documents
  • Stakeholder requirements
  • Admin access to existing solution (CMS login)
  • Developer access to existing solution (FTP, GitHub repos, etc)
  • Access to relevant documentation
  • Project Review

Once we have access to all the relevant resources, we take time to review with you, the client. Some of the things we need to review together include:

  • Current pain points with your existing solution (This involves in-depth conversations, and likely a demo walkthrough or two)
  • The new proposed solution, and any of your accompanying wireframes, mockups, documentation, etc. (When possible, this can be accomplished through tools like InVision.)
  • Any of the gathered resources which require additional context (e.g. internal API documentation)

This review process is a great opportunity for Zao to collaborate with you. Our intent is to work alongside you as a trusted partner and help you maximize the potential for your project. We can offer industry-level insight based on our years of experience, and even help you to determine if the proposed solution is the best way to accomplish your goals.

In addition to the collaborative review effort, this is also the time we do in-depth research into your desired goals, and audit any existing solutions that we may be building with or on. These audits may include things like your eCommerce platform, web hosting provider, codebase, performance, etc.

Delivery of the discovery document

When we have completed the previous steps, we compile a discovery document for delivery.

This discovery document is the concrete answer to questions like:

  • “How do our requests align with our budget and timeline?”
  • “What will the individual components cost, and can I prioritize based on costs/effort?”
  • “What should be our MVP (Minimum Viable Product)?”
  • “Where does the MVP fit into our long-term roadmap?”
  • “How long will it take to launch our MVP?”

This discovery document represents a significant investment of time and energy and is the result of our collaborative efforts.

Completing the discovery phase and producing the discovery document brings a cohesion and clarity to the project that cannot exist otherwise, and provides a value far beyond the associated costs.

What…so what’s the point, again?

While our ultimate and obvious goal is to continue into the development phase with you, we also recognize that the discovery process may provide a broader insight into our working relationship. Zao is a small, focused team, and we recognize that not every project, timeline, or budget is a good fit for us. If, by the end of the process, it is determined that Zao is not the perfect fit for your project, the value you gain through discovery, and the resulting document is not wasted, and you now have much better clarity moving forward.

We’ve talked about the value of the discovery phase, but what if you don’t have the time, or budget for this important step? If we opt for skipping the discovery phase, we’re likely to run into this unfortunate truth: The short term gains are not worth the long-term pain.

Lacking the clarity of vision over the long-term work of the project, dealing with the surprises and scope creep, and pivoting on features mid-project — these are all very real risks of skipping this phase, which is why we consider it the first step in working together, and a high priority.


Have questions about the discovery phase? Or have any tales of horror of working without one? Let’s hear ’em!

What does a company meetup look like when “Family” is a core value

This last week, the whole of Zao converged on the beautiful city of Portland Oregon for a 5 day meetup extravaganza. Being that Zao only has 5 members, this may not sound that impressive, but Zao has a particular value, Family, which meant this was not your typical company meetup.

We had every member of each family in Zao together for those 5 days in a large home near downtown Portland. This includes Mihai and his wife Roxana (who made a trans-continental journey from Romania!), Me, my wife Meagan and our 3 kiddos (cross-country from North Carolina), Liz and her husband, Marcus, and their 2 children, and Justin and Melissa and their 4 children. If you’re counting along, That’s 17 people under one roof!

While a meetup like this has the potential to quickly become a disaster, we found it to be the exact opposite (despite the fact that the adults were outnumbered by young children, and the event wasn’t without a certain level of “crazy”). So much of our work is reflected in our families, and vice-versa. We were able to spend time with each other’s families, and to see the similarities as well as differences, and to gain an understanding of what makes each of us “tick”.

There is simply no replacement for in-person meetups, where we can put a face to a name (or slack avatar) for each employee, and their spouses and children. Having this meetup was an incredible way to confirm our core value of “family”, both by ensuring our families were involved, but also by confirming the abstract notion of Zao as an extended family. This may not be the quickest or recommended way to corporate/financial “success”, but for Zao, we wouldn’t want it any other way.