WordPress Multisite

Published 2013-11-03, 23:00

Today I spent some time reading up on WordPress Multisite. It was born out of WordPress MU and included in the Core of WordPress since version 3.0, but I never got around to really understand and use it. Here we go:

Information

Plugins

Special Cases

Future

Summary

Multisite seems to work fine but sometimes behaves a bit strange, especially if you want to do special things that it’s not (really) supposed to do. The documentation lacks a lot (note to myself: maybe help) and the not-in-the-focus development from MU to Multisite causes lots of problems with old blogs posts, strange wording and information, confusing everybody. So I’m going to try using it.

Performance-Optimierung am Beispiel: betamode.de

Published 2012-03-22, 20:07

Ich habe mich ein wenig mit Performance Optimierung von Webseiten beschäftigt. In den nächsten Tagen und Wochen werde ich einige Beiträge dazu veröffentlichen. Den Anfang macht diese Beschreibung des Optimierungsvorgangs von betamode.de:

Beispielseiten für Optimierung

Ausgangssituation

Erste Beobachtungen und Auswertung

Optimierung

Anwendbare Regeln aus High Performance Website Sites:

Rule 1 – Make Fewer HTTP Requests

Folgende Bilder können zusammengefasst werden:

Schritte:

Ergebnis

Rule 3 – Add an Expires Header

Mit W3 Total Cache lässt sich sich das wunderbar erschlagen.

Ergebnis

Rule 6 – Put Scripts at the Bottom

Das Analytics-Script ist zwar schon ganz unten, aber noch das alte synchrone. Also mal das neue besorgen und einbauen.

Ergebnis

Rule 10 – Minify JavaScript (+ HTML + CSS)

Javascript gibt es keines, aber für Minify von HTML und CSS kann einfach W3 Total Cache konfiguriert werden, fertig.

Ergebnis

Dann zum Abschluss noch ein bisschen serverseitiges Caching um DB-Anfragen und so weiter zu minimieren mit W3 Total Cache.

End-Ergebnis

Tadaa, schnell.

Pingfix 0.4b gleich hinterher

Published 2006-09-06, 00:17

Für Eilige: Neue Version 0.4b unter http://betamode.de/wp-pingfix/

Mein gestern veröffentlichtes Plugin Pingfix kam eigentlich ganz gut an. Dummerweise hatte ich jedoch einen kleineren Bug übersehen, der das Löschen alter Entwürfe teilweise mit einer unschönen Fehlermeldung quittierte. Dieser wurde nun behoben.

Zudem äußerte Boris Bedenken gegenüber einem voll beschreibbaren (chmod 777) „wp-content“-Verzeichnis. Zurecht. Ich hatte die Funktion ohne großes Nachdenken aus einem anderen Plugin übernommen.

Deshalb hat Pingfix nun einen eigenen Ordner für die Logfiles, der bei der Installation jedoch von Hand erstellt werden muss. Der Name des Logfiles ist ab sofort auch vom (verschlüsselten und gekürzten) Datenbankpasswort abhängig, so dass der Dateiname des Logfiles nicht mehr erraten werden kann. Dadurch wird es vor Zugriffen von außen geschützt.

Die nun aktuelle Version 0.4b, und die aktualisierte Installationsanleitung, gibt es wieder unter: http://betamode.de/wp-pingfix/

Aktuelles zu Pingfix: http://betamode.de/kategorie/projekte/pingfix/

Endlich: WordPress Pingfix 0.4(a)

Published 2006-09-04, 10:16

Man glaubt es kaum, aber heute habe ich es endlich geschafft Version 0.4 meines WordPressplugins „PingFix zu veröffentlichen: http://betamode.de/wp-pingfix/

Der Leser fragt sich nun sicher, was dieses PingFix eigentlich tut und wieso er das braucht. Die Antwort von der Pingfix-Seite:

PingFix verbessert und erweitert die WordPress-Pingfunktionen für Pingservices, Trackbacks und Pingbacks.

Aha. Etwas genauer:

Mit PingFix sendet ein Beitrag nur dann Pings, wenn er erstmalig im Weblog veröffentlicht wird, nicht bei jeder kleinen Änderung am Text. Beiträge, die erst in der Zukunft auf dem Blog erscheinen sollen, senden auch erst dann ihre Pings. Nicht schon, wenn der Beitrag geschrieben wird. Zusätzlich werden alle Pings zur besseren Kontrolle in einem Logfile protokolliert.

Welche Blogger brauchen das Plugin?
Meiner Meinung nach vor allem Blogger, die ihre geposteten Beiträge häufig editieren (Wer tut das nicht…) oder zu geplanten Zeiten veröffentlichen – diese Vorgänge werden durch das Plugin nämlich korrigiert und beschleunigt.

Bisher ging es doch auch ohne, wieso brauche ich nun plötzlich ein Plugin?
Mit dem Plugin läuft alles ein wenig „korrekter“ und besser ab: ein Ping bei erstmaliger Veröffentlichung reicht; ein Ping macht erst Sinn wenn der Beitrag veröffentlicht ist. Zudem gibt es nun ein schickes Logfile in dem die Pings protokolliert werden.

Download & Anleitung: http://betamode.de/wp-pingfix/
Aktuelles zu Pingfix: http://betamode.de/kategorie/projekte/pingfix/

Direkte Korrektur: Version 0.4a

Nach einem Hinweis von Frank Bültge ist mir aufgefallen, dass ich PingFix gar nicht auf Kompatibilität mit WordPress 1.5.x getestet hatte. Tatsächlich nutzte eine Unterfunktion erst ab WordPress 2.0.x verfügbare Funktionen – deshalb habe ich gleich eine korrigierte Version 0.4a hinterhergeschoben. Jetzt müsste es auch mit der alten WordPress-Version funktionieren.

Aktuelle Version

Die hier besprochenen Versionen von Pingfix sind nicht mehr aktuell. Aktuelles zu Pingfix findet sich in der Projektkategorie Pingfix.

WordPress-Plugin: Relative Dates for WordPress

Published 2006-08-02, 00:58

Relative Dates is a simple plugin for WordPress that displays the date of your posts as the time elapsed since it was posted (based on the date that the user is viewing the post; i.e., „Posted 2 weeks, 1 day ago“).

http://justinblanton.com/projects/relativedates/

WordPress-Sicherheit: nonce?

Published 2006-07-17, 03:02

Wer ein wenig mit dem WordPress-Admininterface (>= 2.0.3) herumspielt findet früher oder später im Quellcode ein seltsames hidden Field:

<input type="hidden" name="_wpnonce" value="b6f49bd123" />

Für was das gut ist, wird hier erklärt: http://asymptomatic.net/2006/06/01/2370/what-is-all-this-nonce-sense/

Pingfix: Der doofe WordPress-Option-Cache…

Published 2006-07-09, 23:47

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 😉

Ping-Probleme mit WordPress

Published 2006-06-13, 00:27

WordPress hat bis zur aktuellen Version 2.0.3 diverse Probleme und Fehler in den 3 Pingfunktionen Ping-Services, Trackback und Pingback:

  1. Zukünftige Posts pingen sofort nach Klicken des Buttons „Veröffentlichen“ (Publish), nicht erst zum Veröffentlichungsdatum
  2. Nutzt man die XML-RPC-Schnittstelle (zum Beispiel mit Blogdesk) sind die Pings eher Glücksache
  3. Editierte Posts pingen erneut die Ping-Services an
  4. Bei Problemen mit den Pings gibt es keine Benachrichtigungen, Erklärungen oder Logfiles
  5. Der Nutzer muss warten bis die Ping-Services abgearbeitet sind

Wie schon in einem vorigen Post angekündigt arbeite ich an einer Lösung für diese Probleme. Die Punkte 1 bis 3 konnte ich mit „meinem“ Plugin schon beheben, an 4 und 5 arbeite ich noch. Wenn du Lust hast das Plugin zu testen, eine kleine Mail an mich und ich schicke das Plugin mal rüber.

Musstest du dich noch mit anderen Fehlern und Problemen bezüglich der Pingfunktionen herumärgern? Kennst du andere Leute die Probleme hatten? Ab damit in den Kommentarbereich, wenn ich schon dran sitze kann ich die sicher auch lösen.

Wie WordPress pingt…

Published 2006-06-10, 02:06

Ich arbeite gerade an einem Plugin das die Ping-Funktionen von WordPress ein wenig verändern und verbessern soll. Auf jeden Fall habe ich gerade erst wirklich verstanden wie WordPress 2.x es (teilweise) schafft, dass der Nutzer nach dem Posten eines Beitrag nicht auf das Abarbeiten von Trackbacks und Pingbacks warten muss:

echo '<iframe id="pingcheck" src="' . get_settings('siteurl')
.'/wp-admin/execute-pings.php?time='. time() . '" style="border:
none;width:1px;height:1px;"></iframe>';

Die Datei execute-pings.php wird, falls nötig, einfach per Iframe in den Footer des Adminbereichs eingebunden und kümmert sich dann um die Pings. Wenn also ein Trackback nicht direkt ankommt, erstmal noch ein wenig im Adminbereich herumklicken damit der Ping auch wirklich ausgeführt wurde.

Ich frage mich wieso nicht mehr register_shutdown_function genutzt wird wie noch in WordPress 1.5. Jemand Ahnung?

Jetzt gilt es „nur“ noch herauszufinden ob da nicht noch andere Funktionen sich um die Pings kümmern. Dazu aber in Kürze mehr…

WordPress-Plugin: Smart Update Pinger

Published 2006-05-26, 19:08

Smart Update Pinger sorgt dafür, dass WordPress nur bei neuen Postings die Pingliste durchgeht und alle Services anpingt.

Zusätzlich gibt es eine schicke Liste mit den Antworten der Pingservices. Diese hilft bei Problemen, oder wenn man einfach nur überprüfen möchte, was WordPress da nun in der Gegend herum gepingt hat.

(via: http://blog.beginnermillionaire.com/?p=63)

16 queries. 0,097 seconds.