Scheduled Blocks

With the new Gutenberg editor for WordPress (coming in 5.0), your content will be made up of blocks. Each paragraph, image, quote, heading (and a lot more) are all discrete pieces of information which Gutenberg calls blocks.

WordPress natively has the ability to schedule an entire post for a specific future date and time (which may or may not always be reliably adhered to, but that’s a different story). There are plugins that allow you to schedule when a post should be ‘unpublished’ – i.e. no longer publicly available.

However, what if you wanted only part of your post – say a paragraph or two – to go live (or stop being live) at a specific time and date? Technically possible with shortcodes, but that’s going to get ugly real fast. And, well, shortcodes are part of WordPress past. What about WordPress future?

This is where scheduled blocks comes in.


Add a custom sidebar panel to Gutenberg

WordPress 5.0 will ship with a brand new content editor dubbed Gutenberg. It’s one of – if not the – largest changes to WordPress in the last… ever (?). With change comes anxiety and because this is the Internet, this particular change comes with opinions. Lots and lots of opinions. This post is going to take a massive sidestep around those opinions, and instead focus on something that I haven’t seen published anywhere. I’m going to show you how to add a custom sidebar panel to Gutenberg that can apply to your own custom blocks or, importantly, to existing blocks (whether they be provided by WordPress core, or other plugins)


WordPress Page Templates in Plugins

This used to be a tricky problem to solve involving ‘fooling’ WordPress into loading the right template from its cache etc. However, for about 12 months now – since 4.7 – it’s relatively trivial to load a WordPress page template from a plugin. Here’s how:


 * Add the Page Template to the dropdown in the Edit Screen.
 * @param array $templates The current list of page templates
 * @return array Modified list of page templates
function theme_page_templates__register_page_template( $templates ) {

    $templates['your-custom-template'] = 'YOUR CUSTOM TEMPLATE';

    return $templates;

}// end theme_page_templates__register_page_template()

add_filter( 'theme_page_templates', 'theme_page_templates__register_page_template' );

 * When the user has selected our custom page template, ensure WordPress
 * loads it from the correct location here in the plugin.
 * @param string $template path to current template being requested
 * @return string path to template
function page_template__load_page_template_when_required( $template ) {

    // Determine if this is our template being requested
    $post          = get_post();
    $page_template = get_post_meta( $post->ID, '_wp_page_template', true );

    // Bail if this isn't our template being requested
    if ( 'your-custom-template' !== basename( $page_template ) ) {
        return $template;

    // OK, our template is being asked for. Let's load it from here in the plugin.
    $dir      = plugin_dir_path( __FILE__ );
    $template = $dir . '/templates/your-custom-template';

    return $template;

}// end page_template__load_page_template_when_required()

add_filter( 'page_template', 'page_template__load_page_template_when_required' );

The first filter – ‘theme_page_templates’ adds the template to the dropdown in the edit screen. The second – ‘page_template’ – picks up when WordPress is deciding which template to show on the front-end.

Simple, yet pretty powerful, stuff.

WordPress shortcode API breaking changes in 4.2.3

This post is not the normal faire for this blog. Normal programming will return shortly (I had to create a new category called ‘Rants’ so that says a lot, I think).

I’m frustrated.

I am so conflicted with the shortcodes API change. I understand it’s a security fix, and that is the trump card. I’m fully cognizant of the fact that this change hasn’t affected a huge, huge number of sites and that’s a really great thing. I’m also cognizant of the fact the way in which the API was being used wasn’t the envisaged way (using shortcodes in attributes) and that, to a lot of experienced people, doing so is just a bit, y’know, silly.

However, this is a breaking change to an API. An API that has existed for a long time and as such is being used in many, many different ways.


Namespaces in WordPress development

As more and more developers come into the WordPress space (a truly wonderful thing) — many of whom transition from other ecosystems — I often hear or read about how antiquated those developers find WordPress coding practices. You don’t have autoloading? Or dependency management? Or… you get the idea. “Wait… you can’t even use Namespaces in WordPress development? How adorable.”

One of the key reasons – I believe – WordPress has become so incredibly popular is its continuing commitment to backwards compatibility. The changes they make to the core of WordPress very, very rarely cause issues for those upgrading. In fact, one of the finest pieces of coding in WordPress core is the automatic updater. It covers practically everything and is an absolute triumph. You simply can’t do that if you’re worried about breaking things.

I’ll talk more about why that applies in this case especially in a short while, but let’s ensure we’re all on the same page. Whilst this topic can be a little dry, I’m going to explain by example.


From PHP-FPM to HHVM on Ubuntu

As a developer I enjoy using the latest and greatest…things. And, as a WordPress developer, I enjoy seeing how I can use the latest and greatest with the content management system I use on a day-to-day basis. Today I moved this very site from using PHP to HHVM. Here’s how.


Setting up WordPress on HHVM on Digital Ocean

Note: This is a long tutorial (Over 4500 words) on how to set up WordPress on HHVM deployed with Capistrano and Composer. The actual process took me about an hour from start to finish. I’ve tried to be as complete as I could, but please leave comments if you see anything wrong or things that can be improved.

Also, I have absolutely no idea who my audience is for this post, so I apologise in advance if the level of verbosity isn’t quite for you. That being said, you will need to be at least relatively comfortable on the command line and have a basic understanding of how WordPress works – especially the wp-config.php file.

First up, let’s start with a few cautionary notes. HHVM is not finished. It still doesn’t support absolutely everything that native PHP does (it supports pretty much most of the stuff you should be using, though). If you use some crazy-ass WordPress plugins or some bonkers theme, it may well not be supported. It’s unlikely, but possible.

Second, let me make this absolutely clear; I am not an expert at this sort of stuff. I’m not a sysadmin. I’m not a devops overlord. I’m not a low-level engineer of any kind. I am, however, a guy who enjoys playing with the latest stuff and, after playing with this, I was so blown away by how fast it was, I thought I’d share my experience.

Third, this website – – doesn’t run on this stack just yet. I will be migrating to it fairly soon. Update: This site now runs on this stack. You can read the post about how I migrated from PHP to HHVM. I’ve set up several sites on this stack however, just not this one. I’ll probably write up a separate tutorial for switching from PHP-FPM and nginx to hhvm and nginx in the future.


Memcached for WordPress on Ubuntu 14.04

If you’re unsure of what an object cache is, or what memcached is, your first port of call should be Scotty’s article on the subject.

WordPress has built-in support for a PHP object cache. However, it only exists temporarily – for a single page load. The best way to explain this is to think about options. When a page loads, WP loads all options from the database (technically all ‘autoloaded’ options, which is the default). Any later request for get_option() will call from the in-built object cache meaning no more hits to the database.

However, if you want this to be more persistent, you need to set up one of several solutions. One is setting up a memcached server. Sounds complicated. It kinda is…but, thanks to people who are much, much smarter than I am, the process of setting up memcached for WordPress is now simple. In order to get this working, you need to do two or three things;

  1. Install memcached on your server
  2. Place a config file in the correct location
  3. (sometimes) Adjust your wp-config.php file


Composer packages and WPMU Plugins

I am by no means a composer expert. In fact it was something that Ale at Briteweb introduced me to a little over 9 months ago. So whilst the method that I’m describing below most definitely works – and is stable and solid – it is by no means the only, or indeed possibly best way to accomplish this task.

Composer packages, by default, are placed into their own directory, within the ‘install path’ that you specify. If you use the wpackagist repository then you have access to the wordpress-muplugin type. Unfortunately, WordPress Must Use (MU) plugins – by default – must be in the root of the mu-plugins directory (which by default is mu-plugins in your wp-content directory, but can be defined using WPMU_PLUGIN_DIR and WPMU_PLUGIN_URL ). This means that, without any modification, any composer package that is installed into the mu-plugins directory simply won’t work. Bummer.


Determine MySQL Database Size

When you work with fairly large databases, it’s often useful to know the size of one of them. For example, should you wish to take a full dump – you need to know if you have enough space on the drive you wish to keep it, and, in order to do that, you’ll need to know the size of your database. Or, you may just want to know how much of your drive is being used up by the database so you’ll know if it should grow quickly, that you’ll have enough space.