Bringing the queue to WordPress

In Laravel you have the concept of queues, where you push a job in to the queue and a queue worker executes jobs asynchronously one by one. This is a great feature of Laravel.

At OSM Aviation we send a great amount of emails from our website. Sometimes we might need to send thousands of emails at the same time. This is an operation that would get real slow real fast; an ideal job for a queue.

Sadly, WordPress does not have such feature. The wp_mail function is a fire and forget kind of feature. Luckily there are many smart people out there, and there is a solution for features.

Finding the perfect solution

During my search for WordPress Queues I first found a solution which runs through wp-cron. This however ended up as a bottle-neck when sending many emails and ended up bringing our whole site down for a couple of hours. Not optimal for a mission-critical website.

A promising solution was a neat plugin created by A5hleyRich. This took care of the queue problem, but it had some shortcomings. There was no CLI, so it was not ready for production. Based on this great plugin I found a hidden gem in MailChimp for WooCommerce plugin. They had created a command for WP-CLI that ran a queue worker. They had also implemented a “failed_jobs” feature which could prove handy if something went wrong. None of these solutions took care of mail problem though. So I would have to wire something up myself.

Putting it together

I found this to be a fun little exercise in using WordPress’ pluggable functions. Since wp_mail can not be short-circuited, I figured I could just create my own wp_mail function that would be used in favor of the one in WP core. I took the original wp_mail function from core, and created it as a new function called wp_real_mail. This would send e-mail directly via the credentials provided in the application.

The wp_mail function’s only task would be to push anything thats sent through it to the new Queue system. Using the great work from the MailChimp-plugin this function boils down to two lines.

E-mails sent via the website is now served up using a queue, allowing us to send as many e-mails as we need in one go without having to worry about it taking several minutes to execute. Actually, since June we’ve sent over 15000 emails using this new queue feature and haven’t had a single mail that hasn’t been sent.

The queue worker is run on the server by Supervisor, so it is restarted when it crashes.

Check it out now

It has all been bundled up in a plugin that is availiable on Github, along with its documentation. Since it replaces the wp_mail function I recommend you put in your `mu-plugins` directory.

Check it out on Github now!

The DOM router improved

I’ve previously written about my port of the DOM router which is bundled with the Sage starter theme.

This handy little mofo has been used on all my client projects for the past 2 years, and I couldn’t be happier.

Something that has annoyed me, however, is that it requires jQuery. There’s not reason jQuery was needed in the first place, but back then I jQueried all the things.

Last week I spent a couple hours one night to port the port to a more usable module. It was also a neat project to write Vanilla-ish javascript.

The result is DumDum.

DumDum is a ES2015 class and has all the same properties as the old jQuery DOM Router.

You can import/require it to your project. Or simply load up the distribution file to use the browser global.

Read more on Github

Actions and filters in Laravel

I really like the way events work in WordPress. It’s just really simple how you can hook into difference points in your code.

Yes, Laravel has it’s own event system. But I found this to be both confusing and hard to use. While classes are all fine and dandy, I do feel there are such things as too many of them. I also like the idea of events being triggered on hook names.

So that’s why I made Eventy (yes, stupid name, but that’s what I got).

Eventy is the WordPress action & filters in Laravel. You add actions/filters in your code, and add listeners to them later.

Check out Eventy on Github!

Blade for WordPress

Lately I’ve been working on an internal project that we’ve chosen to build on Laravel. Laravel is packed with amazing things like the Eloquent ORM and the general “easyness” of the API. The most amazing thing, however, is the Blade templating engine. I love this thing!

You can easily extend templates and include them with a breeze. It really helps you with your rapid front-end development.

So, I’m in love with Blade, but I’m primarily a WordPress developer. Sucks to be me right?

Well, no, not really. There are some existing options on how to use Blade in your WordPress theme.

Like the Blade for WordPress plugin, or even the CutlassWP WordPress theme (which uses the functionality from the said plugin and is Roots-based). These are great, but the thing is.. They use a really old version of Blade. In fact. It is the Blade that was bundled with Laravel 3. There’s been two iterations of Laravel since then, and in that also Blade.

The other thing is that I’ve gotten used to my own starter theme, so I’m not really feeling like switching to a new theme and start an all new workflow. I should be able to use the latest version of Blade, and I should be able to implement it in my own theme.

So, why not create my own Blade for WordPress?

I really like using Composer for handling my dependencies, so I decided to make it a class one can include in projects.

It kind of works the same way those other alternatives work, but does not require you to install another plugin or switch out your starter theme.

Have a look! It’s over at Github.

My starter theme

Working as a professional WordPress developer I’ve tried a number of different starter themes, but the common denominator is that you always end up changing most of the theme. This is fine, and I think you should. But the workflow of most of these themes are poor.

I really like creating better workflows for myself and my colleagues. Stuff like grunt and gulp excite me, and I like the challenge of making it work like I imagine things in my head.

Say hello to my little friend!

I love Foundation, Roots (now Sage) and Gulp. And I love them together. Back when I started creating my starter theme, Roots was built solely on Bootstrap (meaning LESS) and it used Grunt. I know that with the newest release of Sage, they’ve taken a huge leap towards becoming framework agnostic. This is awesome, and I’m probably going to be using Sage as the basis for a future version of my starter theme.

The theme is simply called AnunaStart. Because I work at Anunatak and, well, it’s a start for my projects.

Right out of the box, you’ll recognize most of what’s in the olds Roots, but with some changes that has made my developer life easier.

Gulp!

Gulp is friggin’ awesome. You can do so much stuff with it. The sky is the limit. Gulp is the main engine of my starter theme. It builds the CSS, it concatenates the javascript, it grabs my vendor scripts and it watches for changes.

One cool thing about AnunaStart is the file called vendors.json. This file is watched by Gulp, and is added amongst the script files. This is neat if you have an external library you’ve downloaded via Bower (or something else), which you want added. Simply add the paths (relative to the vendors.json) to the files and they are automagically added to the mix.

Roots

AnunaStart is based on Gromf, which is based on Roots. Meaning it’s Roots-Bootstrap-Grunt+Foundation+Gulp. Roots has an awesome theme wrapper, which helps you stick to the principles of DRY; don’t repeat yourself. You do not have to use the get_footer() and get_header() functions in every single one of your templates. I love it!

DOM-based Router

AnunaStart of course ships with my plugin: jQuery DOM Router. This little thing is kinda cool. It fires javascript based on what classes your body has. Read more about it in my blog post about it.

..and loads more

AnunaStart is packed with stuff I use in my everyday development. Off-Canvas Menu, WCAG 2.0 and ACF integration are just the tip of the mountain.

Anunastart is on Github. Check it out. I’ll love to hear your thoughts on it!

jQuery DOM Router

For a while I’ve been using my own fork of the Roots (now Sage) starter theme for most of my WordPress projects. The theme is packed with awesome twists of the WordPress we all know and love. We have the Theme Wrapper, which sticks with the D.R.Y. (Don’t Repeat Yourself) principles. And one thing I especially fell in love with, a DOM-based router.

What is DOM-based Routing?

The DOM-based Routing is based on a concept by Paul Irish from 2007. In short terms it fires javascript based on classes set to the body-element.

This is clean enough for most people, but I always the syntax felt a bit cluttered, both in Roots and the snippet from Paul Irish.

Enter jQuery DOM Router

I decided to make a jQuery plugin which works in the same way as Roots’ DOM-router, but has, in my eyes, a much cleaner syntax, and moves the logic out of the main script file. It shall be called jQuery DOM Router.

One major difference from what Roots’/Paul’s method does, is that jQuery DOM Router works on live changes to the `<body>` element. As soon as you add a class to your body element, the JavaScript you’ve set up will fire.

How does it work?

First of all you include jQuery.

<script src="http://ajax.googleapis.com/ajax/libs/jquery/2.0.0/jquery.min.js"></script>

Then include the plugin code.

<script src="dist/jquery.dom-router.min.js"></script>

Now you can go ahead and call the plugin. Simply use the name of the class to fire on as the name of a property in an object passed to the plugin. If something is to be fired on no matter what, you create a property named `common`. Class names with dashes are read with underscores by the plugin, so a class of `big-cakes-for-you` would be `big_cakes_for_you`.

$(document).router({
    classname: function() {
        // fire your js when the body has class "classname" when the page loads
    },
    common: function() {
        // code put inside the common property will be executed on all page loads
    }
});

And I mentioned, it responds to live changes. So, check out this example.

<html>
  	<head>
    	<title>My Awesome DOM Router</title>
  	</head>
  
  	<body class="home">
    
		<h1>jQuery DOM Router Example</h1>
		
		<button id="add">Add class</button>
		<div id="container">
		</div>

		<script src="http://ajax.googleapis.com/ajax/libs/jquery/2.0.0/jquery.min.js"></script>
	

  	</body>
</html>

See the Pen XbZjrQ by Tor Morten Jensen (@tormjens) on CodePen.

In this example only the javascript under “common” and “home” are executed, which is understandable as we only have the “home”-class on our body. But looks what happens when we press the “Add class”-button. The code under “laters” is fired. Note that code is only fired once during each request, so if you add the class, remove and then add it again, it will have no effect other than the first time.

jQuery DOM Router is on Github. Enjoy!