Once a Week: It’s a Start!

As a part of a larger effort to be more involved in the WordPress community as a whole, I’m now trying to set aside at least half my workday every Thursday to focus on core contribution.

Compared to most, that’s not much, I know. I’m always in awe of how much time and energy is volunteered daily by such talented folks. I know that’s been said a thousand times, but it’s no less true.

I’ve been held back holding myself back from regular contributions for quite a while. It’s always seemed futile to me to jump into an ongoing code discussion and have anything of value to offer. But that’s just my insecurity with a little dab of “imposter syndrome” talking. I’m starting to learn that making development contributions to WordPress doesn’t usually start with declaring “I’m going reinvent the media editor!” or “Time to give back by writing a new Settings API!”

The fact is that there is so much that can be done. Documentation, support, spelling errors, etc… Thanks to help from the great folks at WordCamp Seattle this year, I submitted a small inline documentation ticket & patch. It was such a small contribution, but it was something. And that small something opened up the door a little bit to me realizing that this core contribution thing doesn’t have to be so damn daunting.

Hey, it’s a start.

Modals for WordPress themes using AJAX & Template Parts

Developing a theme’s modals has always perplexed me. Over the last few years, as I’ve developed one-off themes for clients and various other projects, I’ve bounced around different methods for loading and displaying modal markup. I’ve gone from quick-and-dirty methods like hard-coding them all before </body>, hidden, and then adding display styling to each when called, to writing overly complex functionality plugins to do all of the…modaling (?).

Just recently, I developed the following method that I find to be both lightweight and flexible in most situations. **Note that here I’m only exploring working with modals on the level of getting the markup to the page when called .I’ll leave other topics like styling and animation for another post.

Modals as Template Parts

In theming, I hope you’re using WordPress’ core template tag get_template_part(). If you haven’t yet heard of or utilized this template tag, I recommend reading Tom McFarlin’s excellent post that details the benefits of developing with “partials” using this function.

It’s a very useful concept for any sort of reusable piece of your theme, and this idea can benefit us greatly when dealing with modals because:

  1. We will often need a single modal to be available in multiple places throughout a theme.
  2. It presents us with an easy way to provide a fallback page for visitors with Javascript turned off, for example.

So assuming that our theme, which I’ll call Pinwheel for the rest of this post, loads its other reusable elements from a /parts/ directory using get_template_part(), we can use the same idea for its modals. Consider the following markup for a basic “log in” modal:

<div class="modal">
    <div class="modal-container">
        <button class="modal-close">X</button>
        <div class="modal-content">
            <h1>Please Log In</h1>
            <!-- Log in form, etc... -->
        </div>
    </div>
</div>

Now, rather than copy-pasting this into multiple templates or writing an overly complex template tag, we can simply save this markup into the /parts/ directory as a file called modal-login.php. Then, we can add this line to any template to make this modal available:

<?php get_template_part( 'parts/modal', 'login' ); ?>

I like that naming scheme simply because it’s easy to keep the template parts of each type organized, but that’s entirely up to you. The point is that we can quickly and easily call that little snippet of modal code and display it when needed.

AJAX Those Modals

So now we can load our log in modal template part in any template that we know will need the log in modal. Great! But even better would be to never load the modal’s markup at all until someone specifically calls for it. This is where AJAX comes in.

The first step is to make the AJAX request with jQuery and handle its response. Consider the following:

The loadModal function accepts the name/slug of a modal and calls for an AJAX response containing the requested modal’s markup. It then appends that markup to the <body> tag.

Next, we need some PHP to interpret that AJAX request and serve up the appropriate modal template for jQuery manipulation:

This function goes about turning on output buffering so that we can use the now-familiar get_template_part() function to load the requested modal (the ‘modal’ variable, passed from the jQuery AJAX call).

Lasty, we can add a click event to certain anchors or buttons or…well any element, really. We can utilize our own ‘data-modal’ attribute to specify which modal we want that particular element to load. Then, we can add the following jQuery:

These three methods provide us with an easy-to-implement and flexible way to use modals in our themes without getting stuck loading a bunch of unneeded markup at the end of every page. Let me know what you think of this and other methods in the comments and feel free to suggest improvements!

And as always, keep your modals accessible and responsive at all times…