Ever since WordPress 4.5 rolled off the press there have been numerous complaints about websites breaking. Numerous reports are coming into our Store Locator Plus forums and support email telling us “our map broke when they updated our website”. The problem? jQuery. To be more specific the problem is not jQuery but how some plugins and themes implement jQuery in WordPress.
One of my sites had problems displaying password protected content this morning. The site worked fine, but after supplying the password on the protected content the content area was blank. It turns out JetPack plus some missing PHP modules on my Linux server were the culprit.
How did I find the issue?
WordPress debugging. This is usually my first stop when trying to isolate a WordPress problem. Go to the root install of your WordPress site and edit the wp-config.php file. Look for the line:
While you are in there turn this on as well. This will allow you to quickly turn this feature on-and-off and then investigate the debug.log file in the wp-content directory. You don’t want to leave debug mode on with a site that visitors are accessing.
When I make these edits I prefer to copy both lines and set one of them to false while leaving the other true, then comment out the pair of lines I am not using. That makes it easy for me to go in and turn debugging on/off by swapping the leading comment (#) marker.
Now go to the offending page on your site. You should have the errors logging to the ./wp-content/debug.log file which will give you some hints.
In order to properly render protected content JetPack uses the XML Dom Document processor. Make sure you have installed php-xml on your server.
The other package JetPack uses heavily is multibyte string support. Make sure you have php-mbstring installed.
On Red Hat flavored Linux variants you can get everything in order by using these commands:
yum install php-xml
yum install php-mbstring
service httpd restart
Make sure you execute the restart on the web server so the PHP modules are loaded properly.
This may not fix the issue on your server, but the debugging and module searches may help some of you.
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.
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.
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.
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.
With WordPress it is very easy to debug the activation process of a plugin and get a detailed log file of exactly what is going on. I use this method to look at activation problems with Store Locator Plus on various servers. Most often I uncover server security settings that are too strict, memory issues, or even blocked MySQL connection requests on mis-configured shared hosting environments.
How can you do the same? Easy. I only have FTP access to many of these client sites, which means you should be able to employ the same technique.
Enable WordPress Debug Logging
Login to your server using your FTP client.
Download the wp-config.php file. Hopefully you’ve moved this out of the root directory of your website (that is noted in various security articles on this site). If not it will reside in your web root.
Find the line:
Edit that line and add another to the wp-config file to turn on logging:
Now you can go and activate your plugin or run whatever other things are causing you problems. I find it best to only chase one problem at a time and empty/delete the debug log file between tests.
After you’ve tested the issue, such as activating a plugin, go get your log file with FTP. Download the file in your ./wp-content directory named debug.log. This contains any errors and warnings generated from within WordPress.
When you are done make sure you turn OFF debug logging so you don’t slow down your site and fill up your disk storage.
Edit these two lines and put the file back on your server.
I know… what the HECK am I doing publishing a new plugin with all this work on Store Locator Plus and MoneyPress still to be done, right? Well, this plugin is going to save me a LOT of time. That is important as a sole developer, marketer, tech support agent, and publisher. Anything that I work on for a day that saves me 3-hours/day down the road is a good return on investment, IMO.
The latest plugin is an addition to Debug Bar. It is free and readily available in the WordPress Plugin Directory. It allows plugin and theme publishers, like me, to take advantage of the slick Debug Bar UI to output my custom debugging information. When Debug Bar is on and active my plugins can now output debug information into the hidden/out-of-the-way debug bar panel.
What does this mean for the other plugins?
I can start ripping out a TON of custom code for my own debugging UI. I can also reduce almost every 3-to-5-line segment of debugging output code to a single line that calls the output method in the Debug My Plugin tool. The other plugins become lighter and more efficient and my debugging process is made a whole lot easier.
Even better, if a customer is having a problem with a plugin they can install Debug Bar + Debug My Plugin and peek “under the covers” as well. They can see what is going on without intrusive interruptions in the regular admin interface, which is what my current debugging output has been doing.
I’m sure Debug My Plugin will be updated along the way as I find myself using it more & more.
Busy day today for a Saturday. I guess that is to be expected when it rains and is 50-degrees all day. Makes for a good “stay in and be productive” day. So what did I work on today?
Well, I started out working on Store Locator Plus. But I had issues. A bad tech-karma day where stuff just decide to break all day. My DNS kept going out. I had to reboot my computer. Twice. And the updates to Store Locator Plus were giving me problems. Then my website started lagging. Damn computer gremlins. They seem to travel in flocks and land on a different house or business every few days.
Debug My Plugin
That is a new plugin I’ve written for WordPress. I’ll publish it if my system stays online long enough for me to get it out to the Internet. I wrote that because I had a few things mis-behaving in Store Locator Plus and was tired of patching in var_dump or print_r all over the place, then going back to rip it out. Since I learned about Debug Bar the other week I figured I’d use that.
Except there are either no simple plug-and-play plugins out there to add your own debugging, I’m too stupid to know how to use them, or I’m just plain lazy. Probably a combination of all 3. I decided it would be faster to write my own add-on to Debug Bar to do what I wanted than keep searching through trial-and-error and digging through poorly documented and commented Debug Bar ad-ons.
One thing was obvious. Developers HATE documentation. Most developers I’ve met and certainly from what I’ve seen in the innards of some of the dozen Debug Bar add-ons I’ve downloaded, the trend follows a lot of plugin developers. The readme files that tell you about the product are sparse at best. Inline code docs? Yeah, not really.
So my new add-on pack with a LITTLE documentation is going to be submitted tonight in hopes that some other plugin devs may find it a useful way to throw their debugging messages out into Debug Bar and keeping their code minimalistic when it comes to handling debugging UI elements.
While I was trying to figure out why my site was so slow I decided to nix the bloated plugin I was using to track Alexa and other site health stats. I went looking for something a bit lighter but still functional. Sadly I once again ran into a bunch of defunct, unsupported plugins. I’m asking the authors why they stopped development so I can learn more about the market. Here is what I found… or didn’t find… as the case may be:
So what did I land on? I’m playing with “List Rank Dashboard Widget”. Recently updated and has the metrics I want, though it could use some more features. Maybe I’ll help him out with that if he’s interested.
Store Locator Plus Updates
I’ve been coding more Store Locator Plus updates. Mostly lightening the code and adding new debugging hooks while I try to get some things out for paid customer support requests. Finding out when other plugins are breaking things has been a chore. Hoepfully adding Debug Bar plus Debug My Plugin to broken customer sites will help expedite the process when I need to see what is going on, and possibly save the customer a support fee if they can “look inside” by adding a couple of admin-only plugins to their site.
Not that my computer if patched up and my Internet appears back to normal I can get back to coding.
One of the sessions I attended at WordCamp Atlanta had some very useful information for developing and debugging WordPress plugins. Another had useful information on speeding up sites with transients. And another touched on security issues. Almost every session that went a little deeper into the tech side of WordPress mentioned a plugin that they all used… Debug Bar.
One of the sessions had a brief blurb on what Debug Bar does and what it looks like. In short, it throws a small “Debug” link up on the admin menu bar. Hidden under that little debug button is a treasure trove of useful site debugging information. This is NOT something you want to have up and running at all times on a production site, but for a development site it is a God-send. No longer will I be writing dozens of hooks in my code and cluttering up the UI with debug output expansion boxes… even though I spent some time building a jQuery based expandable div for that over the past few months. Debug Bar is a much cleaner UI experience, and based on what I’m seeing in the plugin directory it is full of hooks and filters I can tap into with my plugins.
Getting and Prepping for Debug Bar
As with any plugin, getting and installing Debug Bar was simple. Go to the admin panel / plugins page to get the add new process started. Type in “debug bar” and there it is, right at the top of the listing. Install and activate.
However, one thing I immediately noticed is the documentation is very sparse. No links to an external site for more info. No instructions on configuration. I guess that is the built-in litmus test. If you can’t figure out how to get debugging setup, how to use the plugin, or where to go next then you shouldn’t be playing with it.
In fact, I feel that is a good point.
If you don’t know what this plugin could be useful for, don’t understand what an SQL query, global variable, or memory dump is from PHP then DO NOT INSTALL THIS. For one thing it could be used to exploit your site if you do not lock this down. In fact I’d not put this on a live site unless I was having serious site problems I could not sort out on my staging/development server (you DO have a staging site for your mission critical business site, right?).
OK, so you’ve got the plugin. but do NOT make that the only thing you do. You need to feed that thing AND you should be using the built-in debugging resources you’ve got built into the core WordPress product…. setup your environment for debugging. Again, only in a development or staging system.
If you cannot figure out where to put these elements in the wp-config file then you should stop now. Do not play with this unless you know what you are doing. If you have a clue then you are going to make your WordPress debugging and research a LOT easier. I cannot believe I did not know about this sooner… but at least I know about it now.
Ok, Got It… Now What?
Now you can start using the Debug Bar and the micro-system of associated add-on packs to gain more insight into your WordPress installation. By default the plugin shows you some basic site metrics that can be useful such as your server name, current PHP version, current MySQL version, and how much RAM is being used by the WordPress process for the page you are viewing at the time. You can also get the Object Cache hits (and misses) on any page. On a page that is processing request variables? It will show that plus any matching rewrite rules from your permalink structure. Nice things to know.
Here is a default view on my dev box on a basic Store Locator Plus page. I see that the initial page rendering “hit” adds about 2MB to the memory footprint. I’ve been playing with reducing the memory footprint of the wpCSL framework I use to help render pages, so I’ll be very interested if the swap in the code logic reduces the memory. This one piece of information saves me a lot of extra code debugging inserts and keeps my code lighter. Already worth the 5 minute install and configuration of Debug Bar.