Update: Beim Gegenlesen meines Eintrags kam mir dann doch die Idee, wonach ich googlen sollte, deswegen ist dieser Thread eigentlich auch schon wieder erledigt. Nun hab ich's aber schon mal aufgeschrieben, und vielleicht interessiert es ja auch andere. Siehe unten.
Mal eine Frage für Fortgeschrittene mit etwas Zeit zum Tüfteln: Ich richte gerade eine lokale WP-Installation ein und habe dazu mal spaßeshalber WP_DEBUG auf true stehen. Bisher gingen fast alle Plugins erfreulicherweise ohne Deprecated-Meldungen durch, aber nun habe ich eine Meldung, aus der ich nicht schlau werde. Das hier wird ausgegeben:
ZitatNotice: has_cap wurde mit einem Parameter oder Argument aufgerufen, der seit Version 2.0 veraltet ist! Die Benutzung von user_level in Plugins und Themes ist veraltet. Nutze stattdessen das Abfragen von roles oder capabilities. in D:\webapps\wp_test\wp-includes\functions.php on line 3321
Die Zeilennummer kann man ignorieren, das ist die Zeile, wo die Meldung generiert wurde. Dieser Aufruf kommt offenbar aus der has_cap-Funktion, aber wie finde ich jetzt raus, wo genau has_cap mit dem falschen Parameter aufgerufen wird?!
Empirisch würde ich es auf das "Lightbox 2"-Plugin schieben (http://stimuli.ca/2010/02/07/lig…-for-wordpress/). Wird es aktiviert, taucht die Meldung auf, deaktiviere ich es, ist sie wieder weg. Nirgends im Plugin-File wird die has_cap-Funktion allerdings aufgerufen. Und wenn ich mal durch die gesamte Quelle von WP suche, finde ich auch nur sehr wenige Core-Dateien, welche die Funktion überhaupt benutzen, und noch weniger davon, welche die Funktion so nutzen, dass es theoretisch eine Zahl als Parameter sein könnte.
Im Livesystem für die Kunden kommt WP_DEBUG dann natürlich aus, aber mich interessiert das jetzt doch, woran es liegt und wie man heraus kriegt, woher der Aufruf kommt. Kann man sich da irgendwie einen Stacktrace anzeigen lassen, ohne gleich einen Debugger anwerfen zu müssen (damit habe ich mich bisher immer noch nicht wirklich angefreundet...)?
Antwort: Klar, googlen nach "PHP stacktrace". Damit kommt man zur schönen Funktion "debug_print_backtrace()". Diese gibt genau den Stacktrace aus, aus dem man sehen kann, über welchen Aufruf man zu dieser Funktion kam.
Wenn es schnell und dirty sein soll, kann man einfach wp-includes/functions.php öffnen und das in die deprecated-Funktionen einfügen (Zeilen 3230 bis 3326). Für eine dauerhaftere Lösung kann man sich in der functions.php oder an anderer geeigneter Stelle eine Methode für die Hooks "deprecated_function_run", "deprecated_file_included" und "deprecated_argument_run" definieren und darin den Stacktrace generieren lassen.
In diesem Fall wurde add_options_page mit dem Argument "10" statt "manage_options" aufgerufen. Habe dem Plugin-Autoren Bescheid gesagt, aber da der gerade in Indien ist...