Monthly Archives: December 2014

Using namespaces in WordPress themes and plugins

I consider myself a relative newcomer to WordPress plugin and theme development, but I have programmed in PHP for more than a decade. That said, my first attempts to create a theme and plugin consisted of taking someone else’s work and tweaking it till it did what I wanted it to do. In short, the classic hacker’s learning process.

I’ve now moved on to the next phase of the learning process — applying ideas from work in other applications to WordPress. That means getting rid of stuff in my themes and plugins that I thought I needed but don’t really need, and tailoring each kind of project to their specific requirements.

One idea drilled in the WordPress documentation is namespacing. It’s not called that specifically because WordPress has been around long enough to predate PHP’s support of namespaces. But in exploring tutorials on theme and plugin development, I saw a lot advice about giving functions a unique prefix. In other words, use naming conventions to enforce a namespace.

Many enterprising developers have encapsulated their plugins with object-oriented programming, a practice to which I adhere myself. But the first versions of my plugins resulted in some unwieldy and oftentimes long-winded naming.

For example, the Musicwhore.org Artist Connector for WordPress prefaced class names with Musicwhore_Artist_Connector_, Musicwhore_ or some variation of the two. The file names followed suite, with such names as musicwhore_artist_connector_db_driver.php and musicwhore_artist_connector_post_meta.php.

To reign all this verbosity, I looked to the PHP Framework Interop Group standards for a bit of guidance. WordPress doesn’t follow the PHP-FIG recommendations, but it doesn’t mean there aren’t any good ideas there. One of them is the use of PHP namespaces.

The WordPress plugin environment is rightly concerned about naming collisions — my function named setup should have no effect on someone else’s similar function named setup. At the same time, something cryptic as mwac_setup is hardly readable.

PHP namespaces allows me to carve a place where my readable names won’t collide with anything else, perhaps even WordPress core itself!

This example is a very abbreviated form of what I use in the Musicwhore.org Artist Connector.

namespace VigilantMedia\WordPress\Plugins\Musicwhore\ArtistConnector;

Setup::init();
Settings::init();
Rewrite::init();

I’ve encapsulated my initialization tasks as methods in individual classes and gave them simple names. Without namespacing, I would have had to resort to a naming convention.

Musicwhore_Artist_Connector_Setup::init();
Musicwhore_Artist_Connector_Settings::init();
Musicwhore_Artist_Connector_Rewrite::init();

A classic WordPress example would forgo namespaces and classes altogether.

function musicwhore_artist_connector_setup() {
     add_action('init', 'musicwhore_artist_connector_init');
}

function musicwhore_artist_connector_settings() {
     add_action('admin_init', 'musicwhore_artist_connector_settings_init');
}

function musicwhore_artist_connector_init() {
    // Initialization tasks go here.
}

function musicwhore_artist_connector_settings_init() {
    // Initialization tasks go here.
}

The example with namespacing demonstrates an idea common to web frameworks: don’t repeat yourself. Time-honored WordPress naming conventions tend to be very repetitive.

Namespaces work well with organizing widgets, template tags and the functions.php file in a theme. The twentyfifteen WordPress theme, for example, uses traditional naming conventions to emulate namespacing.

function twentyfifteen_entry_meta() {
    // ...
}

function twentyfifteen_categorized_blog() {
    // ..
}

Object-oriented programming can simplify this organization.

class TemplateTags {

    public static function entry_meta() {
        // ...
    }

    public static function categorized_blog() {
        // ...
    }
}

Now say you have a child theme based on twentyfifteen. You can still create a TemplateTags class without having to use naming conventions to distinguish itself from the parent theme.

namespace WordPress\Themes\TwentyFifteen {
    class TemplateTags {
        public static function entry_meta() {
            // ...
        }

        public static function categorized_blog() {
            // ...
        }
    }
}


namespace WordPress\Themes\TwentyFifteenChild {
    class TemplateTags {
        public static function entry_meta() {
            $output = \WordPress\Themes\TwentyFifteen\TemplateTags::entry_meta();
            // ...
        }
    }
}

Namespaces have been available in PHP since version 5.3, which reached end-of-life support back in August 2014. So they should be very well supported on servers keeping up with PHP upgrades.

All in with WordPress

About a year ago, I described a massive relaunch of all my personal web projects from a custom solution to WordPress and Drupal. At the time, I said Drupal code had better readability than WordPress, and I also said Drupal’s strict naming conventions in the global namespace emulated object-oriented programming.

Today, Drupal is no longer part of my stack.

I moved all my blogs over to WordPress back in November. Part of it is professional need — my office is migrating a particular Drupal site to WordPress, and I wanted to get a feel for how such a migration would happen. Mostly, I just prefer the user interface of WordPress over Drupal.

I’ve also created custom plugins for both systems, and while the “Drupal way” has far more structure, the WordPress system of hooks is incredibly versatile. It took less time to create a connector plugin to the Musicwhore.org artist database in WordPress than it did to create a similar connector in Drupal for my record label Observant Records.

Drupal loves abstractions and does everything it can to shield developers from its inner workings. That can really get in the way if something goes wrong far below the surface of the abstractions. It also makes its database schema probably more complex than it should be.

WordPress, by contrast, has a surprisingly compact database schema. So compact, in fact, that the opposite problem occurs — database tables doing multiple duties. In some instances, WordPress code is too tightly coupled to its database.

Neither Drupal nor WordPress has a particular good template system, but I found WordPress to be slightly more readable than Drupal. Or maybe the widget system in WordPress has a better user interface than the block system in Drupal. Conceptually, they operate very similarly.

As a result of all this work, I find myself getting drawn deeper into the WordPress platform. Am I slowly becoming a specialist in one application instead of being a general PHP developer? And should I be reluctant to adopt such a role?