Posted on

Debugging SLP with Debug My Plugin

Debug My Plugin Banner 570x188

The following video may be helpful to both the SLP Beta Test Group members as well as users that are thinking of using Debug My Plugin to debug their own plugins.     This video shows how the output of Store Locator Plus looks in the Debug Bar output panel and how to show request variables and debug counts.

Posted on

Debug My Plugin 0.9.1 How The ….

Debug My Plugin Banner 570x188

From deep within the “How the HELL did this ever work” camp comes the Debug My Plugin version 0.9.1 patch.  Yes, just moments (ok, hours) after the WordPress 3.6 compatible 0.9 patch.

While merrily going along debugging the latest Tagalong release… OK, not so merrily.  Debugging means something is not going as expected and thus debugging usually equates to less-than-merry parts of the coding profession.  At some point,  I realized the more than HALF of my debugging output was not showing up.    I quickly discovered  a typo in the Tagalong helper function, fixed it, and moved on.

Or not.

Something else was wrong.    The Tagalong tab was showing up in Debug My Plugin panels but there was no debugging text.   I started tracing the code stack.    I debugged the wpCSL framework used to build my plugins.  I traced and tracked every nuance of the pre-rendering cache, the internals of Debug My Plugin.  The guts of Store Locator Plus.  All was working as expected.

I got into Debug Bar and traced all those components.    Still working.

I put in a timestamp on all the calls so I could see the order things are being called in the action stack. The time resolution was not good enough, everything was happening at 02:20.   I added microtime() so I could see, to the microsecond, when stuff really happened.

That is when I discovered it.    The Debug Bar render method was being called WAAYYYYYY before most of the Tagalong code was being executed. Anything I was trying to put out to the debug screen was ignored.   But WHY?   This USED TO WORK.  What the heck!!!

So I did what any logical and seasoned programmer would do.   I found out where Debug Bar was hooking into the WordPress stack.  It happens to be hooking at the wp_after_admin_bar_render call.    I want to know WHERE that hook is called in the stack.   According to the WordPress API reference it is way down at the bottom of the call stack for an admin login, right before shutdown.  Well, guess what?  IT IS NOT DONE THAT LATE.  It is far, far earlier (you can read my explanation of this below).

But here is the super helping of AWESOME about that particular note.    How did I learn it was not actually called that late?  Google!   Yup, that’s right the wonderful search results of Google.  And you know what one of the top pages, in fact THE TOP PAGE, is that comes up when you search “wp_after_admin_bar_render” and “debug bar”?    Yup… you guessed it… my very own README file for Debug My Plugin.

What an IDIOT.

I read my very own notes…

“Turns out Debug Bar rendering is called somewhat early in the stack. At the action hook ‘wp_after_admin_bar_render’, as a matter of fact. Problem is, that renders BEFORE admin page contents are rendered. Reading the Action Reference you wouldn’t think that was the case… or I didn’t anyway… but it is. As such the variables I wanted to see were not dumped to the Debug Bar panel. Thus, I moved Debug Bar render() to the ‘shutdown’ action hook. This runs AFTER the entire admin page is built. Maybe there is a better place to hook it, but for me, that is what worked so that is where it lives. “

OMFG.  I just wasted over an HOUR tracing code to learn that the cause of the missing debug messages was not only something I had clearly come across before and though important enough to write a dissertation, I created the problem AGAIN in my very own DMP 0.9 patch I just released!!!

Turns out removing the action removal and add-back calls was NOT a good idea.  They are necessary.

Apparently the thing that changed in WordPress 3.6 that forced me to separate my DMP init routine and the panel addition hook to Debug Bar also meant that the order in which I REMOVED the original Debug Bar action hook needed to be changed.   Prior to version 0.9 ALL of the Debug My Plugin stuff waited until the action call “debug_bar_panels” before doing ANYTHING.     It just so happens that debug_bar_panels happens way AFTER  Debug Bar adds the render function to the wp_after_admin_bar hook.  When I called my init function with the WordPress init, like any normal plugin would do, it also moved my REMOVE the wp_after_admin_bar hook from Debug Bar to way BEFORE Debug Bar even added it.

Yup, that is right… I REMOVED an action hook before it was even added.

Guess what?   That doesn’t work very well.

That meant that the render method was called twice in Debug Bar and that is what caused it to break on my dev box, NOT the fact that I was moving the action call to shutdown.

Now that I spent nearly 2 hours tracing internal WordPress filter and action calls I have a great understanding of how that all works, builds the index keys, and all sorts of fairly interesting stuff I’ll never use.     Though I did re-prove to myself that action hooks and filters are 100% interchangeable.   They may have processed differently in the past but today add_action simply turns around and calls add_filter with the parameters you give it.   Same with remove_action.   Sort of makes sense and explains why there is not difference between what you can do and how you pass parameters to each.   I can see why you may want different semantics so that “action = do something” and “filter = change and return data”, but for all practical purposes they do the same thing “behind the curtain”.

Guess I better get off the computer and go do something brainless for the rest of the evening.     I’ve already created enough self-inflicted mayhem for the night and capped it off with one big “DOH!” moment.

Man, sometimes I feel like I’m a programming newb all over again.   Stupid computers.


Side note…

Time to get super-geek, super-geeky..

This is only going to be of interest of the uber geeks looking for info on wp_after_admin_bar_render.

So Where Is wp_after_admin_bar_render?

It lives in ./includes/admin-bar.php.  In particular it is called in the wp_admin_bar_render method which was added in WordPress version 3.3.0, according to the code docs.   The method only fires if you have the admin bar turned on, which makes sense with the Debug button hiding there on the UI.

However the problem with that, while a great concept for only showing stuff when the admin bar is rendered is that it is called in TWO places.   wp_admin_bar_render is called via the in_admin_header action hook (happens VERY EARLY in the process) and again in the wp_footer hook.

That means that any debugging output I want to do in my plugins would be flushed out with the in_admin_header call.

Thus, if Debug Bar really wanted to make sure it is only called if wp_admin_bar_render is active they could do this:

global $wp_admin_bar;

if (is_admin_bar_showing() && is_object($wp_admin_bar)) { add_action ('wp_footer',array($this,render),1001); }

That would be called MUCH later (though DMP would still lose the footer related debugging calls.. boo), would retain the LATE admin bar call hook only AND call it at the same time that the current hook to wp_admin_bar_render() is called… actually immediately after as the admin bar processor sets this up at wp_footer priority 1000.

Posted on

Debug My Plugin 0.9 via WordPress 3.6

Debug My Plugin Banner 570x188

Turns out WordPress 3.6 threw a wrench into the middle of my most-used debugging tool for my plugins, the Debug My Plugin add-on for Debug Bar.     I’m not sure what triggered the issue but a piece of code I knew was a kludge* finally broke with the new release of WordPress.    Something internally was either fixed or changed the call stack order.  Regardless my “creatively coded work-around” (a.k.a. my hack job) didn’t hold up.

As a result I had to rewrite the initialization stack of Debug My Plugin.   Rather than wiring in the hooks that invoked the add_action for admin_menu and burying them deep inside the Debug Bar call that runs when building the Debug Bar panels (debug_bar_panels) I had to setup a proper WordPress init on the Debug Bar plugin, instantiate my objects in the right order, and then connect all the DMP panels at the right time.

Surprisingly… or not really all that surprising when I think about it… my second piece of duct tape that was manipulating the wp_after_admin_bar_render hook in Debug Bar was causing even more problems, breaking the JavaScript panel manipulation.    Turns out removing that Debug Bar action isn’t such a great idea as it pretty much takes care of itself when you are invoking your panels and instantiating your own classes at the right time.

So after hours of twists and turns I can finally get back to using Debug My Plugin on a customer site that is having issues with Store Locator Plus 4.   Turns out I rely on DMP much more than I realized when a customer site is having issues and I need it to see what is going on internally in the plugin on his WP3.6 enabled site.

For those using Debug My Plugin, version 0.9 should keep the plugin working until the next WordPress release, 3.7, coming this fall and the 3.8 release that Matt is taking lead on that is supposed to be coming at year-end.

Posted on

Debug My Plugin 0.7 Released

Debug My Plugin Banner

The version 0.7 update to Debug My Plugin was released today, adding the Dutch (nl_NL) translation file provided by Jan de Baat.

Debug My Plugin is an add-on pack for the Debug Bar plugin created by the WordPress team.    Debug Bar combined with Debug My Plugin provides a less intrusive way to track the internals of plugins and themes while doing development.    Debug My Plugin is utilized heavily within the Charleston Software Associates plugins.


Posted on

Debug My Plugin Version 0.5

Debug My Plugin Banner 570x188

Debug My Plugin version 0.5 was released tonight with a new option that allows the timestamp to be turned on & off.

Debug My Plugin is the preferred method for debugging all CSA plugins.   Combined with Debug Bar, Debug My Plugin offers a non-intrusive way to get additional debugging and processing information from within the plugin.

The new feature allows various plugins, like the Tagalong add-on packs in Store Locator Plus, to output debugging information without the added clutter of the automatic timestamp.

Adding a new 5th parameter to the addMessage() or addPR() method and setting it to false will disable the timestamp.


Posted on

Daily Update : Debug My Plugin / PlugIntelligence / Store Locator Plus

I’ve been trying to get back into the “coding rhythm” after a lot of distractions recently.   Helping out at my son’s school swim lessons.  Counseling friends and family on business matters, family matters.  Business trips and other things that are very non-techie.     I’ve managed to get a few things done over the past week, despite only having a few hours here & there for coding.

Debug My Plugin

I just put out an update to Debug My Plugin, the Debug Bar add-on.   The most recent update adds the ability to create multiple panels within Debug Bar each with a different label.  This makes it easy to not only break up the debugging output into functional elements on the UI but also allows multiple plugins on the same site to use Debug My Plugin without co-mingling the debug output into one “dump screen”.

This is a new tool that I’ve been using to make debugging all my plugins, including Store Locator Plus, less intrusive in the user interface.    If you ever have the urge to check it out you can install Debug Bar and the Debug My Plugin add-on.    When you run Store Locator Plus you will see extra panels being added to the Debug button on the Debug Bar admin bar.     I only have a few panels in at the moment, but eventually all debugging will go into the Debug Bar interface.   It eliminates the UI clutter, which is very helpful when debugging UI issues.    It is also lighter than the custom debugging system that is wrapping inside the wpCSL framework that Store Locator Plus uses.     If you do try this out,  don’t do so on a public or production site.  It does slow things down a little and if your users have admin interface access of any sort they may be able to see internal data you may not want them seeing.


This is a plugin I created with a few hours of coding the other night.   It allows me to filter out the plugin search results from within my WordPress sites.    I use this to cut down on the “junk plugins” that WordPress returns.    The most useful filter I have in this plugin is “minimum tested version of WordPress”.   I’ve found that any plugin that has not been tested since the 3.3 release is very likely unsupported and not in active development.  For some searches this filters out a LOT of plugins I don’t want to look at.

The most recent release shows what filter parameters are set to on the top of every plugin search page.

A future update I’d like to add some day is the ability to turn the filters on/off with the “flick of a switch” right from the plugin search/results page.   Someday.

Store Locator Plus

I’ve done a couple of small patches for Store Locator Plus 3.11.2 that is coming out next week.   A CSS rule in default.css has been updated to fix positioning of the radius drop down menu on some themes.

The other new feature, which some people have been asking for, is the ability to use a shortcode to set the initial search radius for “immediately show locations”.

Woocommerce Premium Plugins System

This is a new add-on pack that I am writing for my own selfish reasons.   I need a way to support the Enterprise Subscriptions model that I’ve discussed on this blog before.    The only way to do that is to keep track of both the product and the VERSION of the product that people have ordered.    However there is NO PRODUCT that I can find on the WordPress eCommerce market that provides the feature set I need.   I’ve spoken to WooThemes, Cart66, and Easy Digital Downloads.  They all “get it” but nobody can offer a solution.

So I decided to write my own.  This is where most of my efforts are these days.

The goal is to great the Enterprise Subscriptions and then the Crowdfunding plugin so that I can generate enough income from the plugin sales to build out a lot of the cool new features people have been asking for.   While this is a distraction in the short term, in the long run I am hoping it provides the features I need on this site to support long term ongoing development of the Store Locator Plus ecosystem and spawns growth in some of the other plugins I have listed here.     If I can get this done properly that means I can contract some other programmers to help expedite the features that people are looking for.

With any luck I’ll have something cobbled together an usable within a few weeks.