A WordPress Guy

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.