While debugging plugins or themes I will often come across a notice / warning / error which doesn’t really provide useful debugging info.
Notice: get_current_site_name is deprecated since version 3.9.0! Use get_current_site() instead. in /wp-includes/functions.php on line 3835
I understand there is a reference to
get_current_site_name somewhere that needs to be changed, but there are many occasions where I have no idea where to look. I have a 75% success rate in getting to the root having some knowledge of what existing themes and plugins do in the background and it allows a quick find and fix. However the other 25% of the time I just have to live with the error because I have little time to dig around hundreds of files.
Is there a way to determine the plugin / theme file where these messages are actually coming from?
This is where the rule of avoiding bloat applies best. You should ask yourself why is it that you have so many errors generated with the code you use. In theory you should not fix the errors but wait for the author to fix it as if you fix it yourself you basically forking the plugin/theme.
More specific to your question, the answer is that it is probably impossible to have it right better than 90%. You can use the “query monitor” plugin to get stack trace, but even stack trace will have only limited value for non trivial situation. For example you might get an “undefined index” type of error when accessing an array element which is a result of DB access bug that happens when a value is being saved, and which you see the symptoms of it only when it is used.
And since finding and fixing non trivial errors is not trivial, and having errors is always a possible gateway to security breaches or general site malfunctions, you should just not use plugins and themes that leave you figuring this kind of things alone by not having timely updates or good effective support.
You can search through the installed files in different ways to find occurrences of the function name that is giving the errors/warnings. Here’s 3 ways:
Download all installed files via FTP. Use a text editor with a Find in Files feature that searches subfolders (eg. TextPad.) This is the slow way, unless you keep a local copy already in which case it’s the fast way.
Login to your server via SSH and use a search command from the command line.
cd /home/USERNAME/web/DOMAIN/ (path below installation)
fgrep -R "FUNCTION_NAME" public_html (where public_html is the install dir)
I think it’s also possible to have the error messages output more information about the error through altering the PHP configuration or error settings, but that is more advanced option I’ll leave that for further research.
My last resort in such cases is to temporarily add a call to the PHP debug_print_backtrace() function at the file/line # indicated in the warning message.
By examining the output of
debug_print_backtrace() you can see the call stack that lead to the warning message being generated. Some times the call stack is pretty deep and it still takes a while to figure out what is going on.