Category: Programming

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.

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.