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.

| improve this answer | |
  • Admittedly these are often errors created from my own plugin dev. I'm looking for a way to work out the bugs before live release to a network I run. – Jarmerson Mar 5 '17 at 8:52
  • in that case query monitor is a great resource, otherwise again, just knowing the symptom is not always enough to easily find the cause – Mark Kaplun Mar 5 '17 at 9:30
  • Whoa... Query Monitor is incredibly userful! – Jarmerson Mar 6 '17 at 0:24

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:

  1. 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.

  2. 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)

  1. Use a plugin that will search through all installed plugin or theme files from your admin area, eg. WP BugBot (full disclosure: written by yours truly for this very purpose.)

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.

| improve this answer | |
  • That also sounds promising. I will check it all out asap and circle back. I'll check out your plugin too 😊 – Jarmerson Mar 5 '17 at 6:26
  • Using Notepad++ : Find in Files was very useful. We don't support plugin or theme editors in WP admin so WP BugBot wasn't appropriate for our environment. Thank you for the feedback :) – Jarmerson Mar 6 '17 at 0:22
  • @Jarmerson No problemos, whatever works. :-) FYI just in the last update of that plugin, if DISALLOW_FILE_EDIT is set true (editors switched off), the plugin and theme search boxes are available from the core update screen instead. – majick Mar 6 '17 at 9:09

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.

| improve this answer | |
  • Perfect. I will try it on after dinner and get back to you. – Jarmerson Mar 4 '17 at 23:48
  • debug_print_backtrace() works well. I dug around a little on the PHP manual for this function and found getTraceAsString() which offers a stack output. if ( isset( $_GET['bug'] ) ) { echo '<style>ul li {margin-top:10px; padding:10px;}ul li:nth-child(odd) {background:#ddd;}</style>'; echo '<hr><h3>PHP Call Stack:</h3>'; $e = new \Exception; echo "<pre><ul>"; var_dump(preg_replace("/\n/", '<li>', $e->getTraceAsString())); echo "</ul></pre>"; die(); debug_print_backtrace(); } Any chance you can advise how to disable truncation of the file paths here? – Jarmerson Mar 6 '17 at 0:31
  • I did the same and found that answer as well. Wasn't able to get it working tho – Jarmerson Mar 6 '17 at 3:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.