Pingfix: Der doofe Wordpress-Option-Cache…
Veröffentlicht am 9.7.2006, 23:47 Uhr
Einige meiner Testnutzer berichteten von Problemen bei den Pings für ehemals in die Zukunft datierte Beiträge. Irgendwie wurden diese Pings mehrfach ausgeführt, teilweise alle 15 Minuten über den Zeitraum mehrerer Tage. Nicht gut.
Ich habe also den halben Nachmittag damit verbracht das Problem aufzuspüren, schlussendlich lag es am WP-internen Caching. Hier werden auch Einstellungen von Wordpress zwischengespeichert. Pingfix zweckentfremdet diese Datentabelle um die noch zu pingenden Einträge zwischenzuspeichern (Dadurch kann auf eine zusätztliche Tabelle oder Spalte in der Beitragstabelle verzichtet werden).
Über die Standardfunktion get_option() bekam PingFix nun also immer die zwischengespeicherten und teilweise nicht aktuellen Werte. Ich habe nun die get_option() kopiert und als PF_get_option() leicht modifiziert in PingFix übernommen.
function PF_get_option($setting) {
global $wpdb;
$row = $wpdb->get_row("SELECT option_value FROM $wpdb->options WHERE option_name = '$setting' LIMIT 1");
if( is_object( $row) ) { // Has to be get_row instead of get_var because of funkiness with 0, false, null values
$value = $row->option_value;
wp_cache_set($setting, $value, 'options');
} else {
return false;
}
return apply_filters( 'option_' . $setting, maybe_unserialize($value) );
}
Warum der Cache mit den Einstellungsoptionen nicht aktualisiert wurde, konnte ich übrigens nicht klären. Eine richtige Dokumentation oder ähnliches zu diesen Funktionen habe ich auch nicht gefunden. Was soll’s, nun passt alles. Hoffe ich ;)
Disallow ist tot.
Veröffentlicht am 6.7.2006, 17:54 Uhr
Gestern habe ich endlich einen Schlussstrich unter das Projekt Disallow.de gezogen:
Das war’s, hiermit beende ich das Projekt Disallow.
[…]
Die Inhalte hier auf Disallow.de im Blog und Wiki bleiben zu Dokumentationszwecken erhalten, vielleicht nützen sie ja irgend wem noch etwas.
http://disallow.de/blog/2006/07/05/disallow-ist-tot/
latin1_german1_ci oder latin1_german2_ci?
Veröffentlicht am 6.7.2006, 17:42 Uhr
Seit Version 2.6.x unterstützt phpMyAdmin die sogenannten Kollationen. Kollationen sind Zeichensätze und Sortierreihenfolgen nach denen zum Beispiel ORDER BY - Klauseln die Daten einer Datenbank sortieren. Es gibt 2 deutsche Zeichensätze, german1_ci und german2_ci. Der Unterschied ist im MySQL-Referenzhandbuch ganz gut dargestellt:
Die Sortierfolgen latin1_german1_ci und latin1_german2_ci basieren auf den DIN-1- und DIN-2-Normen. DIN ist das Deutsche Institut für Normung, also die deutsche Standardisierungsorganisation. DIN-1 heißt „Wörterbuchsortierung“, DIN-2 „Telefonbuchsortierung“.
- Regeln für latin1_german1_ci (Wörterbuchsortierung):
Ä = A
Ö = O
Ü = U
ß = s- Regeln für latin1_german2_ci (Telefonbuchsortierung):
Ä = AE
Ö = OE
Ü = UE
SMS-Versand mit Skype: 11,7 cent pro SMS
Veröffentlicht am 6.7.2006, 15:02 Uhr
Gerade erst über Svoogle.org drauf gestoßen:
Ab sofort können SMS-Nachrichten über Skype an Mobiltelefone raus versandt werden. […] Nach Österreich sind es zum Beispiel 13,6, nach Deutschland 11,7 und in die Schweiz günstige 10,2 Eurocent (alle Preise inkl. Mehrwertsteuer)
http://share.skype.com/sites/de/2006/05/skype_fuer_windows_25_beta_sms.html
http://www.skype.com/products/skypesms/rates/#listing-G
Sehr amüsant übrigens:
Die klugen Leute bei Skype haben sich jedoch eine tolle Sache einfallen lassen, mit der es möglich ist, dass die Nachrichten als Absender deine Mobilnummer tragen.
Ja sind die doch klug, tatsächlich eine Handynummer als Absender anzugeben *staun
Wordpress-Fehler: Falsche Zeitstempel bei Posts über XML-RPC-Schnittstelle - 2
Veröffentlicht am 5.7.2006, 03:53 Uhr
Ich habe mir den Fehler nun (natürlich) doch noch genauer angeschaut.
Erweiterung Analyse:
Ich habe mit dem Offline-Blogging-Programm Blogdesk weiter herumexperimentiert. Bei einem Post, der am 06.07.2006 um 03:11 Uhr veröffentlich werden soll übermittelt Blogdesk folgenden UTC-Zeitstempel:
<dateTime.iso8601>20060705T01:11:00</dateTime.iso8601>
In Zeile 551 der xmlrpc.php (und der Funktion dahinter) wird dieser jedoch wegen der fehlenden Zeitzone als Nutzerzeit (also +0200) behandelt (Zeile 673, wp-includes/functions-formatting.php). Somit werden diesem Zeitstempel nun erneut 2 Stunden abgezogen um eine GMT-Zeit ausgeben zu können, was dann zu den 2 fehlenden Stunden führt: 05.07.2006, 23:11.
Vermeintliche Lösung
Ich konnte leider nicht herausfinden, was xmlrpc und vor allem die MetaWeblogAPI hier eigentlich für ein Datenformat, mit oder ohne Zeitzone, UTC oder lokale Zeit, erwarten. Übermittelt man jedoch an die xmlrpc-Schnittstelle von Wordpress einfach den Zeitstempel mit der angefügten Zeitzonendefinition für UTC +00 (Z scheint auch irgendwie nicht zu gehen)
<dateTime.iso8601>20060705T01:11:00+00</dateTime.iso8601>
trägt Wordpress die korrekten Timestamps in die Datenbank ein.
Und das ist ja eigentlich alles, was ich erreichen wollte.
Wordpress-Fehler: Falsche Zeitstempel bei Posts über XML-RPC-Schnittstelle
Veröffentlicht am 1.7.2006, 17:53 Uhr
Mir ist gerade ein weiterer Wordpressbug aufgefallen:
Fehlerbeschreibung:
Wenn man einen Post per XML-RPC-Schnittstelle an Wordpress übermittelt, kommt es zu Problemen bei der Berechnung der intern von Wordpress genutzten Zeitstempel “post_date” (lokale Zeit) und “post_date_gmt” (Greenwich Mean Time).
Die Differenz sollte eigentlich 2 Stunden betragen, Wordpress berechnet jedoch einen Zeitunterschied von 4 Stunden. Ein Post der um 17 Uhr veröffentlich werden soll hat in post_date_gmt also nicht 15, sondern 13 Uhr stehen.
Auswirkungen:
Dadurch erscheint der Beitrag nicht erst um 17 Uhr auf dem Blog, sondern wird fälschlicherweise schon ab 15 Uhr angezeigt. Der angezeigte Zeitstempel des Beitrag hingegen ist in Ordnung.
Applikationen, die die XML-RPC-Schnittstelle nutzen, können also nichts dafür (eigene, Blogdesk). Fehlersuche dort wird wohl eher nicht zu einem Ergebnis führen.
Analyse:
Der Fehler steckt irgendwo in den Zeilen 560 bis 566 der xmlrpc.php oder den dort aufgerufenen Funktionen:
// Do some timestamp voodoo
$dateCreatedd = $content_struct['dateCreated'];
if (!empty($dateCreatedd)) {
$dateCreated = $dateCreatedd->getIso();
$post_date = get_date_from_gmt(iso8601_to_datetime($dateCreated));
$post_date_gmt = iso8601_to_datetime($dateCreated, GMT);
}
Nachvollziehen kann ich es allerdings nicht wirklich. Zu viel anderes im Kopf gerade. Hat jemand Lust, sich das genauer anzuschaun?
