Follow Jeff Sayre on Twitter

Important Developers’ Notice: Please deactivate WordPress Hook Sniffer for the time being

By

If you are using my WordPress Hook Sniffer plugin, I ask that you please deactivate it at this time and remove the modified plugin.php file–the one that comes with the plugin–replacing it with the original version that ships with WordPress. Make sure that you use the one that comes with the version of WordPress you are running.

I have been having a few issues with BuddyPress development over the past week. I went through all the usual techniques to isolate the issue, finally deactivating all my 3rd-party plugins. But, the issue remained. Finally, I wondered about my WordPress Hook Sniffer plugin. I realized that although it was deactivated, it might be negatively affecting the operation of WordPress if the modified plugin.php file that comes with the plugin had issues. I replaced the modified version of plugin.php with the original one that ships with my version of WordPress, and bingo, the issues went away. All I could think was crap—especially as I say this in the installation instructions:

“The modifications to WordPress’ standard Plugin API file are used exclusively for WordPress Hook Sniffer. They should not affect the functioning of the rest of WordPress.”

In fact, this statement is still technically correct. The culprit is that when I updated the modified plugin.php file for last week’s version 0.13 update to the WP Hook Sniffer, I failed to use the proper base plugin.php file. I used the one that ships with WP 2.9.2 and not WP 3.0. Even though I thought I had done a sufficient parity check between these two files, I had failed to notice a few important changes.

WordPress Core Developers please note: if you change a function you should indicate as much in the inline documentation. Please use the @version PHPDocumenter tag to indicate that the function has changed. The @since tag version indicator is not helpful if the function has changed.

What issues did I have that caused me to discover this problem? The WordPress “wp” action hook was not firing. Yep. That is a big problem, especially if you are doing development work. Interestingly enough, most of BuddyPress continued to function as expected, except for a few features that used to work but suddenly stopped working—right at the time I installed the updated version of WP Hook Sniffer. Of course, I failed to notice this for several days.

I have gone through the stock plugin.php file–with a very fine-toothed comb–and ferreted out all the changes. I am in the process of updating the modified plugin.php file that WP Hook Sniffer is required to use. I want to make sure that it is adequatley tested before releasing an updated version. Look for the updated version with a fixed plugin.php file to be available either Sunday or Monday.

With this pending update, WordPress Hook Sniffer will require WordPress 3.0. Therefore, if you want to use it in an older version of WordPress, you will have to install Version 0.12 of WP Hook Sniffer. Please note, I will only support the most recent version of WordPress Hook Sniffer.

I apologize if this has caused you to lose valuable development time. I know that I have lost several days of productive coding due to this issue. There were obviously some important changes between WP 2.9.x and WP 3.0. Even though I thought I had properly assessed potential changes within the plugin.php file, I had not. I guess I need more sleep, more caffeine, fewer late-night alien visits, or some combination of those three.

Article Comments

  1. Andy Bailey says:

    I noticed the same thing. I was using the hook sniffer to find the places to hook my custom functions in while I was integrating the amember plugin and noticed that log in links and other small functions were not working until I swapped the plugins.php file back/

    I was expecting some small issues anyway but, the good news is that I was able to use the hook sniffer info to quickly get to exactly what I needed. (I was so impressed I donated!)

    I am looking forward to the latest and greatest version because I envisage the need to use those cool geek-worth features when the project goes into overdrive, thanks for letting me know you’re still on the case…

  2. lol … I was *totally* wondering why WordPress was acting strange this week. In our case, var_dump() stopped giving formatted output.

    One possible improvement would be to have hook sniffer automatically replace the original WordPress plugins.php file on activation, and then restore it to the original file when the plugin is deactivated. That way, future problems will easily be found using first line debugging techniques. Don’t forget to handle the situation of the WordPress install being upgraded between hook sniffer activation and deactivation, to avoid restoring plugins.php to an out of date version.

    You also might want to think about taking a hash of the original plugins.php file during the replacement operation and blocking activation of hook sniffer if it doesn’t match the right value. That way, if WordPress is upgraded, overwrites the plugins.php file, and the plugin re-activates …and the newly upgraded plugins.php file has been modified from the previous version… the plugin will not activate.

    These are, of course, only suggestions. We’ll continue to enjoy wp hook sniffer no matter what you do to it. :)

    ^F^

    • Jeff Sayre says:

      foxly –

      Thanks for the suggestions and I’m sorry that you were experiencing strange behavior with WP/BP. I only wish that I had caught this sooner.

      As per your last idea, WP Hook Sniffer has performed that check since day one. Although, it does not do so during activation, it does so after activation so that it can display a warning message at the top of hook sniffer’s settings screen.

      I felt it best to let the plugin activate so as to provide a warning message but just not function—other than allowing settings to be changed. So, if the modified plugin.php file is not installed, it will not fire the routines that output the hook sniffer information. In the pending new version, I’ve taken it a step further by versioning the modified plugin.php file. WP Hook Sniffer will now make sure that not only the modified plugin.php file is installed, but also the proper version of that file.

      As to your first suggestion, I agree that reinstalling the original, stock plugin.php file upon plugin deactivation is a good idea. That way, people can simply activate hook sniffer when they need to figure out an action or filter hook firing issue and then when done, deactivate and rest assured that their stock WP install is as it should be—with no modifications to the plugin.php file.

      I will work on coding that into the upcoming version as well. :)

  3. […] Sayre wrote a post entitled ‘Important Developers’ Notice: Please deactivate WordPress Hook Sniffer for the time being&…which is worth paying attention to if you use the […]

Leave a Reply

Share on Twitter
Share on Facebook
Share on FriendFeed
Share on LinkedIn
Share on StumbleUpon
Share on Digg
Share on Delicious
Share on Technorati
Add to Google Bookmarks

Archives