WordPress 3.5: Semmelstatz-Ausgabe bricht nach Referern ab

Wordpress-LogoNachdem ich zwei weniger aufwendig konfigurierte Blogs auf WordPress 3.5 aktualisiert hatte, musste ich feststellen, dass die Ausgabe des Statistik-Plugins „Semmelstatz“ nach der Ausgabe der Referer-Liste abbrach. Da ich an Semmelstatz hänge und kein anderes Statistik-Plugin eine derartige Übersicht liefert (auch wenn manche die Zahlen anzweifeln, aber dazu am Ende mehr), machte ich mich auf die Suche nach dem Fehler. Denn der ursprüngliche Entwickler Andreas „Redunzl“ Müller hatte die Arbeit an dem Plugin lange eingestellt, es war zwar von weiteren Personen übernommen worden, aber auch da hat sich seit 2011 nichts mehr getan. Also selbst Hand anlegen.

Da keine Fehlermeldungen geworfen wurden, ein Blick in den generierten Quellcode nichts ergab und auch Firebug in der Konsole keine Fehler meldete, machte ich mich auf die Suche nach möglichen Lösungsansätzen im Web. Und tatsächlich: offenbar sind etliche der mySQL-Abfragen sehr unoptimiert und können dazu führen, dass zuviel Speicher verbraucht wird. Dann wird das PHP-Speicherlimit überschritten. Bei mir liegt das bei 128 MB, bei manch einem Hoster deutlich darunter, deswegen ist das Problem bei anderen auch früher schon aufgetreten, bei mir erst mit der Installation von WordPress 3.5.

Auf der Suche nach einem offensichtlichen Fehler fiel mir auf, dass die Datenbankabfragen tatsächlich … na sagen wir mal … ineffektiv sind, weil viel mehr Daten abgerufen werden, als es nötig wäre. Und das, obwohl in den Einstellungen sogar Limits gesetzt werden können. Nur werden die dann in der eigentlichen mySQL-Query gar nicht verwendet. Ich fand in semmelstatz-statz.php in der Funktion sem_showKeyword():

$limit = $sem_options["statz_keyword_limit"];    
$results = $wpdb->get_results("SELECT referer, time, ip FROM $wpdb->statz 
WHERE referer != 'NULL' ORDER BY time DESC");

Da wird zwar das Limit aus der Konfiguration abgefragt, aber in der mySQL-Query nicht angewendet – und damit wird eine Menge überflüssiger Informationen aus der Statz-Datenbank geholt. Deswegen die Abfrage um ein Limit ergänzt:

$limit = $sem_options["statz_keyword_limit"];
$limit1 = $limit;    
$results = $wpdb->get_results("SELECT referer, time, ip FROM $wpdb->statz 
WHERE referer != 'NULL' ORDER BY time DESC LIMIT 0, $limit");

Daraufhin wurden mir allerdings nicht wie in der Konfig eingestellt zwanzig, sondern nur noch drei Suchbegriffe angezeigt, keine Ahnung, warum. Eine kleine Erhöhung des Limits brachte dann aber den gewünschten Erfolg:

$limit = $sem_options["statz_keyword_limit"];
$limit1 = $limit * 6;    
$results = $wpdb->get_results("SELECT referer, time, ip FROM $wpdb->statz 
WHERE referer != 'NULL' ORDER BY time DESC LIMIT 0, $limit1");

Und schon wurde wieder alles wie gehabt angezeigt:

suchbegriffe

Ein geändertes Plugin-Archiv hängt unten an (selbstverständlich alles ohne Gewähr und ohne Garantie auf Fehlerfreiheit, deswegen vor dem Einspielen: Backup. Bei mir klappts).

Noch eine Anmerkung zu den Zahlen, die Semmelstatz generiert. Ja, im Vergleich mit anderen Statistiklösungen sind die zu hoch. ich hatte aber mal einen Test gestartet, in deren Rahmen ich mehrfach unter verschiedenen IP-Adressen und mit verschiedenen Browsern von unterschiedlichen rEchnern zugegriffen habe. Google Analytics und Piwik haben nicht alle Zugriffe davon gezählt. Semmel schon. Von daher würde ich davon ausgehen, dass die Wahrheit irgendwo dazwischen Liegt, Mulder. Als Tagesüberblick über Besucher, Referer, Suchwörter und beliebte Posts bleibt Semmelstatz ein durchaus hilfreiches Plugin.

Ich gehe davon aus, dass weitere Optimierungen der mySQL-Abfragen möglich sind. Wenn ich Zeit habe, kümmere ich mich mal drum.

Download: Semmelstatz 3.3.2mod

WordPress-Logo Copyright Automattic

WordPress: Artikel im Frontend bearbeiten mit dem Plugin „Front-end Editor“

Ich hatte mich immer wieder darüber geärgert, dass ich erst umständlich den RichText-Editor in WordPress aufrufen muss, um kleinere Änderungen an WordPress-Artikeln vorzunehmen, beispielsweise zur Korrektur von Tipp- oder Flüchtigkeitsfehlern. Nun ahnte ich bereits, dass es Frontend-Editoren gibt, aber gerade habe ich eine Auswahl gesichtet und dann – endlich – einen davon installiert. Ich hätte es schon lange so einfach haben können …

Scribus und Jotschis Plugin trägt den simplen Namen „Front-end Editor„. Der besondere Charme daran ist, dass es den Aloha-Editor verwendet, der es ermöglicht, in fast beliebigen Webseiten Änderungen vorzunehmen.

Nach der installation sieht man im Frontend links neben der Mausposition einen Edit-Button, der immer dann auftaucht, wenn man sich über einem editierbaren Inhalt befindet. Das kann der Titel des Artikels sein, aber selbstverständlich auch der Text, weiterhin kann man auch Änderungen an Tags und Kategorien sowie weiteren Artikelparametern vornehmen.

Durch die Verwendung des Aloha-Editors editiert man im Artikel, der weiterhin in seinem üblichen durch CSS festgelegten Design angezeigt wird, also echtes WYSIWYG – grandios! Durch die Einblendung der Steuerkonsole des Editors hat man die Möglichkeit, Formatierungen vorzunehmen. Nach Fertigstellen der Änderungen klickt man einfach auf OK – oder auf „Abbrechen“ wenn man es sich anders überlegt hat.

Als Fazit muss man sagen, dass das Plugin Front-end Editor ein unverzichtbares Werkzeug für WordPress-Nutzer darstellt, denn damit ist es schnell und einfach möglich „mal eben“ Änderungen in Artikeln vornehmen zu können, ohne erst den vollständigen Richtext-Editor im Backend aufrufen zu müssen. Ich weiß gar nicht mehr, wie ich ohne das Plugin auskommen konnte, denn es erleichtert die Arbeit mit WordPress immens!

Man findet das Plugin auf WordPress.org

Screenshots von PhantaNews.de von mir, das gezeigte Bild von Terry Prat­chett (2007) von Mo­ro­bo­shi, aus Wi­ki­me­dia Com­mons, CC-BY,

Workaround für WPML-Darstellungsfehler im Admin-Backend

Im vorangegangenen Artikel habe ich mich über den nicht zufriedenstellenden Support im Zusammenhang mit dem Lokalisierungs-Plugin WPML geäußert. Inzwischen hat sich der Support dann doch nochmal gemeldet, die angebotene Lösung ist aber nicht wirklich akzeptabel. Vorgeschlagen wurde, dass ich „eine CSS-Datei in wp-admin/css“ anpassen solle. Welche Datei das sein sollte, darüber schwieg man sich aus, dabei ist es nicht so, als wären die bei jeder WP-Installation anders.

Zudem ist es sicherlich nicht sinnvoll, Änderungen an den WordPress-Core-Dateien vorzunehmen. Warum nicht ist einfach zu verstehen: beim nächsten Update werden diese wieder überschrieben.

Nochmal das Problem: Der Sprachwähler wird von Backend-Überschriften überlappt:

Ich habe deswegen einen Workaround umgesetzt und als Plugin programmiert. Auf diese Weise ist gesichert, dass das nächste Update die Änderung nicht überschreibt. Sollte man bei WPML das Problem irgendwann beseitigen und neue Versionen des Lokalisierungs-Plugins zur Verfügung stellen, kann der Nutzer mein Plugin einfach deaktivieren.

Um das simpel zu halten, wurde die Position des Sprachwählers ganz oben im Backend fix auf 500 Pixel von links gesetzt. Damit sollte sichergestellt sein, dass auch längere Seitentitel den Sprachwähler ebenso wenig überlappen wie die Optionsbuttons der jeweiligen Seiten.

Zur Installation das Plugin einfach über die WordPress-Plugin-Administration installieren (oder lokal entpacken und per FTP hochladen) und aktivieren. Sollte ab WP 3.1 funktionieren. Mir ist klar, dass man das elaborierter ausführen könnte, beispielsweise eine Option zur manuellen Angabe des X-Werts liefern, aber das ist wie geschrieben erstmal ein schneller Fix und Workaround. Eigentlich sollten die Damen und Herren von WPML das Problem durch eine aktualisierte Fassung ihres Plugins lösen.

Download: imagcon-wpml-fix.zip (ca. 1kB)