The internals of a Premium WordPress Theme (Gonzo)

I purchased my first Premium WordPress theme called Gonzo at its 1.9.2 release. As of this blog post, the current version is 1.9.7 updated on June 29, 2015.

This theme has 8,602 sales at $49 per purchase (Not counting extended support). Now 8,602 sales * $49 = $421,498. That is of course without tax and fees, but still that is a lot of money even if you slice it in half, so this author must have made a pretty sweet theme.

On the outside it fit our purpose easily. A responsive design that kept that magazine style of blog posts on mobile to desktop screens. Additionally it had a multitude of customization allowed on articles and categories.

Like a Premium WordPress theme though, it came packaged with unneeded things. An entire review system, comments between Facebook/WordPress, BBPress connection, tons of widgets, extra short codes to enhance posts and more.

This post is about the internals though. Recently, I decided to create a custom WordPress plugin to build some additional functionality into our site. I wanted to leverage our current theme so I could blend it in perfectly. So I created a local install with our production theme. This OptionTree system was easy to export/import theme settings so the theme, without our menu system, was set-up locally.

So I opened up the Plugin guide from WordPress, and the first step was to enable debug mode.

Enabling WP_DEBUG will cause all PHP errors, notices and warnings to be displayed. This is likely to modify the default behavior of PHP which only displays fatal errors and/or shows a white screen of death when errors are reached.

This started the pain.

// Notice: register_sidebar was called incorrectly. No id was set in the arguments array for the "Sidebar" sidebar. Defaulting to "sidebar-1". Manually set the id to "sidebar-1" to silence this notice and keep existing sidebar content. Please see Debugging in WordPress for more information. (This message was added in version 4.2.0.)

// Notice: The called constructor method for WP_Widget is deprecated since version 4.3.0! Use __construct() instead.

My page was littered with 18 notices about random theme errors. So I took a look at the first one.

/** constructor -- name this the same as the class above */
function video_widget() {
    parent::WP_Widget(false, $name = 'Video Widget');	

This was a simple fix in reality, but how did this escape testing for the past few versions (Including the Gonzo current version 1.9.7).

Well, WordPress 4.3 is throwing the notices and that came out on August 18, 2015. This Gonzo theme hasn't had an update since then, so we can let that one slide. Even though, I don't know many PHP developers still using PHP4 style constructors. The correct solution is this.

/** constructor -- name this the same as the class above */
function __construct() {
    parent::__construct(false, $name = 'Video Widget');	

On to the next error.

register_sidebar was called incorrectly. No id was set in the arguments array for the "Sidebar" sidebar.

A quick Google search brought up the function reference for this call. We can see that WordPress 4.2 now triggers E_USER_NOTICE for using this method incorrectly.

Lets look at a block of code in our theme that led to this.

if ( function_exists('register_sidebar') ) {   
		'name' => 'Sidebar',	
		'before_widget' => '<li id="%1$s" class="omc-widget %2$s">',	
		'after_widget' => '</li>',	
		'before_title' => '<h3 class="widgettitle"><span>',	
		'after_title' => '</span></h3>'   

if ( function_exists('register_sidebar') ) {   
		'name' => 'Footer Column 1',	
		'before_widget' => '<div id="%1$s" class="omc-footer-widget %2$s">',	
		'after_widget' => '</div>',	
		'before_title' => '<h4>',	
		'after_title' => '</h4>'   

My initial impressions after reading this was simply stumped. First off, there is no need to run function_exists on every sidebar to register. You could group these 6 sidebars under one function_exists. Though, I'm not sure why this is even wrapped in a function_exists call. If this fails, your theme will have no sidebars, thus no location to insert widgets which doesn't seem possible in a WordPress envirnonment.

There is a register_sidebars() function designed for multiple sidebar registrations. This wouldn't work completely here, because some of these sidebars are in different locations (header, footer and sidebar).

However back to the notice (error). This theme is missing the 'id' => 'unique-id' on each sidebar. This error I can't excuse easily. Following the Theme Testing Process step 1 says "Fix PHP and WordPress errors" detected by WP_DEBUG. WordPress 4.2, which added this notice, came out on April 23, 2015. The latest Gonzo release as of this post should have had this patched.

At this point, the blaring notices on top of the page are gone - we can now sign into the admin panel. Though, after clicking on "New Post" we are met with some interesting console errors.

GET http://localhost:8080/home/ibotpeaches/Projects/PHP/wordpress/wp-content/themes/gonzo/includes/classes/meta-box/js/color.js [HTTP/1.1 404 Not Found 4ms]

GET http://localhost:8080/home/ibotpeaches/Projects/PHP/wordpress/wp-content/themes/gonzo/includes/classes/meta-box/js/gonzo.js [HTTP/1.1 404 Not Found 2ms]

For some reason, this system is trying to load two files (color.js and gonzo.js) using a wrong URL path. So a quick grep for gonzo.js returns

functions.php: wp_register_script('metabox-js-gonzo', get_template_directory_uri() . '/includes/classes/meta-box/js/gonzo.js');

includes/classes/meta-box/meta-box.php: wp_enqueue_script( 'rwmb-ollie', RWMB_JS_URL . 'gonzo.js', RWMB_VER );

So which one of these is wrong?

The first one gives:


That looks right.

RWMB_JS_URL must be wrong. So we dig into that and we get:


Yeah that isn't right. We are loading assets, not getting file path references.

Looking at the code that is responsible for this.

// Define plugin URLs, for fast enqueuing scripts and styles
if ( ! defined( 'RWMB_URL' ) )
    define( 'RWMB_URL', plugin_dir_url( __FILE__ ) );
define( 'RWMB_JS_URL', trailingslashit( RWMB_URL . 'js' ) );

I shouldn't have to touch this though, this is a dependency inside of Gonzo. I wonder how the author handled this, maybe they defined RWMB_URL ahead of time. Lets grep for that.

~ grep -r 'RWMB_URL' *
functions.php:define('RWMB_URL', trailingslashit(get_template_directory() . '/includes/classes/meta-box'));

Sure enough we found it in functions.php.

// Re-define meta box path and URL
define('RWMB_URL', trailingslashit(get_template_directory() . '/includes/classes/meta-box'));
define('RWMB_DIR', trailingslashit(get_template_directory() . '/includes/classes/meta-box'));

I think I know what happened here. A copy and paste without testing. After looking at the docs for get_template_directory I see in the notes that you must use get_template_directory_uri to obtain the URI.

A 4 character fix later, we are back in business loading those two files. So now I figured I would try out some of the short codes this theme offers. I click the "Insert Alert" button in editor and met with some interesting errors.

Okay, the first one is WordPress, but the rest are not.

I mean, what is even going on here? This doesn't look themed or styled at all. It looks like the web in 1999.

Above is the default link pop up that WordPress provides.

So why is Gonzo looking so bad?

Why why why. I can't understand it. This theme for all 6 short codes load its own HTML via a PHP page instead using the established and consistent UI that WordPress offers. I understand a custom pop up may be needed for complex operations, but these are just textboxes and an occasional listbox.

Including your own themed pop up forces you to manage the dependencies you have included, build the entire pop up UI, including keeping the API up to date since you are manually hooking into events that would otherwise be handled by WordPress. This as we can see, caused some troubles and left this theme with no styling.

Since I haven't used these shortcodes, I unregistered their buttons on the editor.

So let's switch gears. Something in this theme was eating our gallery images into their own format. We prefer to use the Jetpack Gallery, so needed to find out what was happening.

There was a 106.04Kb file called scripts.js being loaded on the frontend that had some javascript I needed to change. 106.04Kb? That is bigger than jQuery, so must be a lot of packages.

It wasn't too hard to figure out why. This scripts.js file loads

  • Fitvids 1.1
  • ElastiSlide v1.1.0
  • Flexslider v2.2.2
  • usagelog
  • jQuery Easing
  • Backstretch
  • prettyPhoto v3.1.6
  • Gonzo User Ratings
  • ElastiSlide (yes different than previous)

Now I might be off on this, but I see in multiple other places in this theme wp_enqueue_scripts() which queues scripts/styles that need to be used on the page. I don't use a background image or the gonzo rating systems. That means I can remove two of those dependencies. Maybe this theme should have detected that and not simply fed the same massive styles.js file to everyone. When we are talking mobile load speed, clearing 30KB worth of scripts is well worth it.

A few funny things I found while digging through this theme on my adventure to fix some bugs.

While reading scripts.js, I noticed this line.


Does sdfsdf stand for something I don't know? Or was this a keyboard mash for a class name.

Additionally, I found this block of code.

 * Register meta boxes
 * @return void
function YOUR_PREFIX_register_meta_boxes()
  // ...
add_action( 'admin_init', 'YOUR_PREFIX_register_meta_boxes' );

It says YOUR_PREFIX. At this point, I'm not even surprised.

This next one is in the dependency that Gonzo uses.

I guess this author's meaning of a CDN is hotlinking images from imgur. I feel bad for anyone who uses this feature if/when those links die.

Some closing notes.

  1. All these tests were done on WordPress 4.4.2 with Gonzo 1.9.7 clean.
  2. I did the above tests with a clean download of 1.9.7 Gonzo.
  3. Plugins installed: Akismet & Hello Dolly (default on install)
  4. Yes this post was published in 2018 when research was done in March 2016.

The drive behind this post was simply aggravation. A weekend I had planned to hack a cool plugin was limited by first theme bugs and then my continued investigation into that theme.


  • 3/13/2016 - Emailed author asking for comment on post.
  • 3/14/2016 - Author responds saying "will fix everything asap".
  • 3/14/2016 - Author asks for "a week or so" to update things.
  • 4/19/2016 - Emailed author asking for update.
  • 4/20/2016 - Author responds "most things are fixed".
  • 3/11/2018 - Release article as no new version has been released in over two years.