[wp-hackers] Best practices for hunting depreciated functions.
fris at fris.net
Sun Apr 24 16:52:29 UTC 2011
I myself found a cool plugin that makes it easy, its called logpress, got it
off codecanyon, cost a couple bucks, but definitely worth it.
From: wp-hackers-bounces at lists.automattic.com
[mailto:wp-hackers-bounces at lists.automattic.com] On Behalf Of Christopher
Sent: Sunday, April 24, 2011 12:43 PM
To: wp-hackers at lists.automattic.com
Subject: Re: [wp-hackers] Best practices for hunting depreciated functions.
When I'm developing new plugins I run a full mirror of my sites on a
localhost to test the plugin across multiple datasets and structures, but
the secondary benefit is that I can use the cross file search capacity of my
editor to quickly do a bulk search across thousands of files.
I'm 100% sure that you're right, there must be a better way to handle this
and I'd love to know how but for me, the fastest way to detect depreciated
functions is oddly similar to your own.
On 2011-04-24, at 1:36 PM, Claude Needham wrote:
> Recently I attempted my first plugin.
> As part of the debugging process I turned on debugging so that I could
> keep one ssh session open with a tail on the error log -- thus showing
> me any errors and warnings.
> To my surprise any warnings and/or errors generated by my fledgling
> plugin were buried deep in a morass of warnings about depreciated
> First of all let me say that the plugins I am using are pretty main
> stream. These are plugins found on most of the "Top Ten" lists. I'm a
> little disappointed that some of these plugins persist in using
> functions depreciated many versions back. But that is not my question
> at the moment.
> My question here is about any tricks of the trade that folks use to
> find where a function is actually being used. Most of the error
> messages listing depreciated functions. Below are two examples of the
> problem that I am running in to.
> [Sun Apr 24 11:19:27 2011] [error] [client xx.xx.xx.xx] PHP Notice:
> load_plugin_textdomain was called with an argument that is
> <strong>deprecated</strong> since version 2.7 with no alternative
> available. in /home/xxxx/public_html/wp/wp-includes/functions.php on
> line 3389, referer:
> [Sun Apr 24 11:19:42 2011] [error] [client xx.xx2.xx.xx] PHP Notice:
> get_bloginfo was called with an argument that is
> <strong>deprecated</strong> since version 2.2! The <code>home</code>
> option is deprecated for the family of <code>bloginfo()</code>
> functions. Use the <code>url</code> option instead. in
> /home/xxxx/public_html/wp/wp-includes/functions.php on line 3387,
> I double checked wp-includes/functions.php and it is definitely not
> using load_plugin_textdomain. :) In order to find which plugin might
> be using the depreciated function call it is necessary to grep my
> entire tree looking for any occurrence. I can do this, but it seems
> like there must be a debugging option available that would somehow
> give a peek into the call stack or in some other way point toward the
> function that contains the depreciated element.
> Assuming that I find all the plugins that are generating the error
> messages, is deactivation of these plugins the only means available to
> clean up my error log so that it becomes easier to see those errors
> and warnings generated by my code?
> I'm assuming other developers have come up against these issues during
> development. Hence, I'm assuming there must be standard practices for
> dealing with this.
> Claude Needham
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
Online Portfolio - http://christopherross.ca Personal Blog -
Fredericton - 506.238.4661
San Diego - 858.201.4912
wp-hackers mailing list
wp-hackers at lists.automattic.com
More information about the wp-hackers