My First WordPress Plugin Patch: Wibiya Toolbar

This post was published 9 years 10 months 20 days ago. A number of changes have been made to the site since then, so please contact me if anything is broken or seems wrong.

The beauty of using WordPress instead of Blogger is, in a nutshell, the freedom that comes with using an open system instead of a closed one. Under Blogger, I had very little freedom to extend the platform. Everything I could do had to be added by someone from Google, with the exception of a few JavaScript- and Flash-based sidebar widgets. Under WordPress, I have access to literally thousands of open-source plugins to modify, extend, and replace the functionality of the site.

The beauty of using this open system is that if something doesn’t work the way I want it to, I am free to simply change it; every plugin is editable from within WordPress’ administrative back-end, and the core code is also hackable (though I don’t like messing with it because upgrades will break changes). When I discovered that the Wibiya Toolbar (or Wibar) was showing on the mobile version of the website (which is generated by MobilePress, another good plugin), I simply looked in the source of Wibiya’s plugin to see how the JavaScript for the toolbar was being inserted.

I found that instead of using the wp_enqueue_script() function as WordPress plugin developers are supposed to do, the Wibiya developers simply used echo to output a <script> tag. That explained why only the JavaScript for the Wibar was loading on the mobile site. Rewriting the plugin to use the official WordPress script-injection method solved the problem.

The original relevant code was:

add_action('get_footer', 'filter_footer');
add_action('admin_menu', 'wibiya_config_page');

function filter_footer() {
    $wibiya_toolbarid = get_option('WibiyaToolbarID');
    $wibiya_enabled = get_option('WibiyaToolbarEN');

    if ($wibiya_toolbarid != '' and $wibiya_enabled) {
        echo '<script
        src="http://cdn.wibiya.com/Loaders/Loader_'.$wibiya_toolbarid.'.js"
        type="text/javascript"></script>';
    }
}

I rewrote it just a little bit. My changes were pretty trivial, really. I changed the function name to be namespaced (including the plugin name) just so it’d be less likely to conflict with another plugin. I also switched actions to enable wp_enqueue_script() to work (get_footer is called too late) and added a check—if( !is_admin() )—to keep the toolbar off of admin pages, preserving the original behavior of the function (and the sanity of anyone using the modifications).

In short, wp_enqueue_script() takes five parameters, three of which are optional. The first two are the $handle and the $src, which specify a name for the script and its source address. Then come $deps (dependencies; Wibiya has none, so set to false), $ver (version; also false because it’s irrelevant), and $in_footer (set to true because the toolbar should be inserted above the </body> tag).

So with my changes, the code block above becomes:

if( !is_admin() ) {
    add_action('wp_print_scripts', 'wibiya_filter_footer');
}
add_action('admin_menu', 'wibiya_config_page');

function wibiya_filter_footer() {
    $wibiya_toolbarid = get_option('WibiyaToolbarID');
    $wibiya_enabled = get_option('WibiyaToolbarEN');

    if ($wibiya_toolbarid != '' and $wibiya_enabled) {
        wp_enqueue_script( 'wibiyabar',
        'http://cdn.wibiya.com/Loaders/Loader_'.$wibiya_toolbarid.'.js',
        false, false, true );
    }
}

Following some light testing, I submitted an idea to the Wibiya feedback forum, where my update is currently being reviewed by the company. Hopefully, the change will be included in a future version of the Wibiya WordPress plugin. After all, it changes nothing for Wibiya but works wonders for compatibility with other plugins.

I’ll just bet that this won’t be the last time I’ll send a patch to a plugin developer. I enjoy reporting bugs and coming up with fixes too much to not do it. 😉