TagPHP

Notice: wpdb::escape ist seit Version 3.6 veraltet!

Bei der Aktualisierung einer WordPress Installation von 3.5 auf 3.6 erschien folgende Meldung mehrfach auf dem Dashboard


Notice: wpdb::escape is deprecated since version 3.6! Use wpdb::prepare() or esc_sql() instead. in /var/www/web4/html/wordpress/wp-includes/functions.php on line 2871 Notice: wpdb::escape ist seit Version 3.6 veraltet! Benutze stattdessen wpdb::prepare() or esc_sql(). in /var/www/project/wordpress/wp-includes/functions.php on line 2871

In Zeile 2781 der Datei “functions.php” steht jedoch die Funktion, welche die Meldung ausgibt. Von dem escape-Aufruf ist weit und breit keine Spur. Mittels grep habe ich dann nach allem was ” escape(” beinhaltet gesucht und manuell ersetzt.


grep -r ' escape(' ./

Die Herausforderung ist, das als Ersatz für wpdb::escape zwei Funktionen genannt werden. Welche davon jetzt die Richtige ist, habe ich abhängig davon gemacht, ob die Eingabe nur ausgegeben werden sollte, dann wpdb::prepare, oder in die Datenbank gespeichert werden soll, dann esc_sql.

Nachdem ich alle Dateien “behandelt” hatte, mit der Dateiendung php, erschien weiterhin die Meldung auf dem Dashboard. Erst das Auskommentieren der gesamten “escape”-Funktion brachte eine neue Erkenntnis:


Warning: array_map() expects parameter 1 to be a valid callback, class 'wpdb' does not have a method 'escape' in /var/www/project/wordpress/wp-content/plugins/broken-link-checker/includes/link-query.php on line 295
Warning: implode(): Invalid arguments passed in /var/www/project/wordpress/wp-content/plugins/broken-link-checker/includes/link-query.php on line 300

Der eigentliche Übeltäter scheint somit die Erweiterung “Broker link Checker” zu sein. Nachdem diese deaktiviert wurde, verschwand die Meldung. Die angepassten Dateien habe ich unverändert gelassen.

Bei meinem grep wurde die Datei “link-query.php” nicht aufgeführt, da “escape” per array_map aufgerufen wurde:


$s_parser_type = array_map(array(&$wpdb, 'escape'), $s_parser_type);

CoSchni#9: Deutsches Datumsformat in MySQL Datenbank ablegen

Bevor das Datum aus der Datenbank gelesen werden kann, muss es natürlich erstmal abgespeichert werden. Das DD.MM.YYYY Datumsforamt muss in das MySQL kompatible Format umgewandelt werden, damit später die von MySQL angebotenen Zeitfunktionen genutzt werden können. Die unten stehende Funktion erwartet ein Datum im Format 24.12.2000 bzw. kann auch noch eine Zeitangabe im Format HH:MM:SS bzw. 09:30:15 mit übergeben werden.

[PHP]
static function GermanToMy($date, $time =””) {

$d = explode(“.”,$date);

return sprintf(“%04d-%02d-%02d”, $d[2], $d[1], $d[0]).$time;
}
[/PHP]

CoSchni#7: Datum von MySQL nach PHP konvertieren

Immer mal wieder müssen Datums- und Zeitangaben aus MySQL gelesen und in PHP bearbeitet oder zur Augabe gebracht werden. Dabei stellt sich grundsätzlich die Frage wie speichere ich das Datum- bzw. die Zeitangabe in der Datenbank. Aus meiner Sicht gibt es nur eine korrekte Antwort: Datum- und Zeitangaben sollten immer MySQL bzw. in dem Datenbank spezifischen Format gespeichert werden. Die Speicherung des UNIX-Timestamp oder anderer Formate erhöht spätestens beim Debuggen den Aufwand enorm. Zudem können, wenn MySQL das Datums-Format nicht unterstützt, keine der nützlichen Time-Funktionen von MySQL benutzt werden.

Nachfolgend eine Funktion, die den übergebenden MySQL-String umwandelt:

[PHP]
static function MyToPHP($time, $withminutes = FALSE){

$unixtime = strtotime($time);

if($withminutes){
$stamp = date( ‘d.m.Y H:i:s’, $unixtime );
}else{
$stamp = date( ‘d.m.Y’, $unixtime );
}

return $stamp;
}
[/PHP]

Inside: Xing

Auf der Suche nach der API Dokumentation von Xing habe ich eine interessante Präsentation gefunden, welche u.a. ein paar Technologien hinter der Business-Plattform vorstellt, siehe http://www.slideshare.net/mark_schmidt/apientwicklung-bei-xing.


Gearman: http://gearman.org/
RabbitMQ: http://www.rabbitmq.com/

Grundsätzlich muss man sich wohl für einen API-Zugang bewerben, weitere Informationen dazu habe ich bisher nicht gefunden. Auf der Homepage habe außerdem noch einen Link zum Developer Blog entdeckt http://devblog.xing.com/.

Bug of the Day: Facebook Captcha

Bin jetzt gerade stark am grübeln ob es an meinem Rechner liegt, oder ich irgendwas verpasst habe. Daher würde ich euch bei Gelgenheit mal bitten in den Kommentaren zu hinterlassen, zu welchem Ergebnis ihr kommt. Der Versuchsaufbau ist ganz einfach.

1. NICHT bei Facebook angemeldet sein
2. So lange verschiedene Profile anklicken, bis die “Sicherheitskontrolle” kommt
3. Einfach auf “Absenden” klicken, ohne etwas einzugeben
4. Online Version des Profils wird angezeigt

Würde mich freuen, wenn mir jemand kurz das Verhalten bestätigen kann.

© 2021 BugBlog.de

Theme by Anders NorénUp ↑