Insights About Insights – And How I Fixed What Its Author Couldn’t
Somewhere between its version 0.4 and my WordPress update to 2.7, the Insights plugin stopped working for me. At least, it stopped working on my hosted blog. But it still worked on my local test server.
And when I say “It stopped working”, I really mean it. No matter what search mode I selected, be it “Images”, or “Videos”, or anything, it always showed me search results from my blog only. [toc class=toc-right]
Weird stuff indeed…
History Of Pain
I submitted a comment to the plugin author (to which I would gladly link, if the author wouldn’t hide all but the most recent couple of comments)1, and I saw that there’s more people who had the same problem. After the next couple of updates did not fix the issue, and facing the author’s persistence in not responding, I gave up and deactivated the plugin.
Alas, after a while I had to admit I could not live without it.
As I had no reason to believe the author would be more receptive for my issue this time, I decided I would give it a shot and attempt to fix it myself.
At this point, I should add that due to some curious twist of fate, I happen to possess a natural born talent for error analysis. In a way, when it comes to software code, I have an instinct for putting my finger right into open wounds. (So much so that I’ve been regularly able to detect a cause of error from hearing the symptoms on the phone and just looking at the code – often code that’s been written by somebody else.)
Anyway, I gave it a shot, and after having some real hard time messing with crappy formatted code (Gee, not even indentation was consistent!), I found the “open wound”.
Fixing Instructions
If you experience the same issues with the Insights plugin, here are instructions how to fix it. (Note that the fix relates to version 1.0 – the current version at time of this writing – or below. Newer versions may have the issue fixed2)
at the time of this writing, the current version of Insights is 1.0., )
- Open the file “insights.js” in the plugin sub-folder “js”
(that is: wp-content/plugins/insights*js/insights.js) - Search for the following code:
$("input[@name='insights-radio']:checked") - Replace it with:
$("input[name='insights-radio']:checked")
Note the removal of “@” inside the square brackets. “@name” is obsolete notation, depricated with jQuery 1.2, and unsupported as of jQuery 1.3!
After discovering the cause of trouble, I could easily deduce the mechanism by which it only failed to work on my server. Do you guess it?
Actually, it wasn’t the server as such. It was the fact that on my hosted server, the Google AJAX libraries plugin is active, while on my local server it is not, and hence the jQuery version pre-installed with WordPress is used. Combine that with the fact that Google provides the latest jQuery version (1.3.2 as of this writing), and WordPress 2.7(.1) comes with jQuery 1.2.6, and the puzzle is solved.
That is:
- jQuery 1.2.x still recognizes the old syntax, so Insights seemingly “works”.
- jQuery 1.3 drops it completely.
The simple conclusions:
- The original Insights won’t work with jQuery version 1.3 and newer.
- With the above fix, it will work with both.
Note that you should apply the fix described herein even if you do not use the Google AJAX libraries. One of the comming versions of WordPress is likely to upgrade to a newer jQuery, so your Insights will stop working when you upgrade WP (but chances by then are you’ll have forgotten about this article, and how to fix the problem).
Conclusion
With so many technologies involved in a website, it is hard to foresee all the interactions that could lead to faulty behavior. With plugins coming from different authors, developed and maintained independently, the phenomenon exponentiates. While software quality is important in general, it is even more important in a plugin world. This is true for internal software quality (think “code readability”, “maintainability”, and “clean design”) not less than for external quality. When the interactions with other plugins are unforeseeable, it is crucial that at least known interactions are valid. Like the interaction with the libraries directly used, ex. jQuery.
My final advice to the plugin author is: Know your tools! And respond to issue reports, too. Where there’s smoke, there’s a fire, too. Find it, and put it out. Or make a clear statement why you can’t or won’t do it.
To everybody else: Cheers and happy insights gaining!
- I actually submitted a question to the author how to access prior comments on the page, in the hope I would find helpful hints by co-commenters, but all I received was silence. That question of mine is pushed out of sight meanwhile, but I see other folks are not getting any help with their issues either. [↩]
- I wonder if the Insights author will give me credit after incirporating this fix. [↩]
Alternatively you could enforce the google ajax plugin to use a specific version (or major revision) of the jQuery library for your site.
Sometimes the plugin can highlight problems sooner than they would be found with WordPress upgrades as the libraries are updated on a different timescale (when Google updates them, rather than when WordPress does).
http://blog.clearskys.net/2009/01/04/fixing-javascript-compatibility-issues-with-the-google-ajax-plugin/
Hey Barry, that’s very true about highlighting problems sooner.
I know you can enforce a library, but then the above advantage is gone. And, one would miss on the super-cool jQuery improvements they made with their 1.3 version, especially the performance boost they gave it.
BTW, thank you for a great plugin. 🙂
I am glad you like the plugin that much. I get around 50-100 inquires daily and maintain almost 20 plugins hence sometimes no response. The change is implemented in new version 1.0.1
Vladimir, interestingly I just rescued your comment from my spam queue. Akismet thinks it’s spam.
Sometimes no response? You try to make the impression not responding is the exception, but my certain impression over the months since before last Christmas is that it increasingly became the rule. I’ve repeatedly noticed you giving thanks to positive comments and ignoring issue reports that have been right next to them (so you couldn’t have overseen them).
Worst of all, you don’t give credit where credit is due. You will have incorporated much of the user feedback into your plugins. (I know you have incorporated some of mine). But do you mention those people anywhere? Nope!
I already guessed you wouldn’t give me credit for doing the debugging and fixing the bug, but just silently take over my results. As I’ve discovered today, I assumed right. You didn’t.
BTW, just for the records: By omitting the credit for my contribution, you are basically violating the GPL – your own license of choice.
Honestly, the whole way you are dealing with information sucks!