Etwas regelmäßiger blogge ich zur Zeit auf mannaz.cc — wer also mehr von mir lesen will, sollte sich dort umschauen. Danke!

Feel free to Flattr this post at flattr.com, if you like it.

BlogcrafterChris on blogcraft, 2010. | Kleine Schaffenspause (Permalink) | Keine Kommentare bisher | Add to del.icio.us
Post tags: pause

Eine der wesentlichsten Änderungen ist übrigens, dass die Single-Installation und WordPress μ (WPMU, Multi-User Variante) nun wirklich miteinander verschmolzen sind. Das erinnert an die Zeiten, wo Microsoft ihre Desktop- und Server-Schiene von Windows zusammengeführt hatte.

Ab sofort lädt man sich also nur noch eine Version von WordPress herunter und kann dann bei der Installation angeben, ob man lieber ein Einzelblog oder eine Mehrbenutzer-Umgebung à la wordpress.com erstellen möchte.

Wer seine aktuelle Installation aktualisiert, bekommt übrigens davon nix mit, die vorhandene Umgebung bleibt so, wie sie ist. Ein nachträgliches Umschalten ist eben sowenig vorgesehen.

Weitere Neuerung ist für Neulinge von Interesse: die Entwickler haben nach vielen Jahren nun auch das Standard-Theme geändert; das gute alte Kubrick hat ausgedient und an seine Stelle tritt nun ein Theme namens Twenty Ten.

Nebst kleinerer Änderungen am Admin-Interface sind die weiteren Neuerungen eher technischer Natur und meistens nur für Entwickler interessant. Spannend wird es nebenbei nun auch, wie kompatibel die alten Plugins sind bzw. wie schnell neue Versionen nachziehen, die z. B. dann auch von der neuen API Gebrauch machen, die einige Annehmlichkeiten zur Individualisierung bringen. So soll es nun leichter sein, Hintergründe, Menüs und Shortlinks anzupassen. Das werde ich mir die Tage genauer anschauen und hoffen, dass dann u. a. auch die Entwicklung für WP Statscraft schneller voranschreitet.

Im Allgemeinen wäre es daher auch ratsam, einige Tage mit dem Upgrade auf Version 3.0 zu warten, denn erwartungsgemäß verstecken sich einige Fehler in größeren Versionssprüngen, die dann noch gefixt werden müssen. Ich freue mich dann also schon auf Version 3.0.1 und 3.0.2 und so weiter und so fort … ;o)

Zum Abschluss noch das von wordpress.org zur Verfügung gestellte Video zu WordPress 3.0 – die Einführung (englisch):

(Kleiner Tipp: Wenn möglich, das Video in HD-Qualität anschauen.)

Feel free to Flattr this post at flattr.com, if you like it.

So, die re:publica 2010 ist vorbei, es waren 3 spannende Tage gewesen.

Und dieses Jahr habe ich doch einiges mitgenommen, was dann die kommenden Wochen auch verbloggt werden kann.

Etwas, dem ich mich z. B. ausführlich annehmen will, ist Slow Media und Slow Design. Und natürlich auch der aktuellen Entwicklung im WWW, der Echtzeit von Informationen und Nachrichten, die natürlich auch die Blogs betrifft.

Aber es gibt definitiv noch mehr interessante Themen, die ich beackern werde.

Feel free to Flattr this post at flattr.com, if you like it.

So, noch genau 6 1/2 Stunden, dann ist es wieder soweit: die bereits zum vierten Mal stattfindende Bloggerkonferenz in Berlin — re:publica 2010!^[01]

Ich werde nun noch schnell ein bisschen schlafen und dann hoffen, nachher gut aus dem Bett zu kommen. (Aber vielleicht verpasse ich auch einfach die Eröffnung …)

Und wer bis dahin noch einmal nachschauen möchte, was in den vorhergehenden Jahren so passiert ist …

re:publica — Historie:

• http://re-publica.de/10/
• http://www.re-publica.de/09/
• http://re-publica.de/08/
• http://wiki.re-publica.de/index.php/Dokumentation07 (keine reguläre Blog-Archivseite vorhanden)

Feel free to Flattr this post at flattr.com, if you like it.

Da ich persönlich danach gefragt wurde, wie ich denn auf meiner Startseite das Auflisten der letzten Beiträge je Kategorie bewerkstelligt habe, stelle ich einfach mal den Code-Schnipsel aus dem Theme hier zur Verfügung.

Ich nenne das Ganze einfach mal DCN CatLooper.

Der Code ist zwar für WordPress ausgelegt, kann aber sicher auch als Vorlage für andere CMS/Blogsysteme dienen.

Ich habe den Code zum einfacheren Übernehmen als Datei hinterlegt: dcn-catlooper.php

Einfach mit Rechtsklick “Speichern unter …” auswählen, abspeichern und die Dateiendung auf .php reduzieren (oder Code gleich in den richtigen Abschnitt des Themes kopieren).

Viel Spaß damit!

Feel free to Flattr this post at flattr.com, if you like it.

Seit kurzem gibt es nun eine offizielle App für WordPress auf Android — WordPress for Android, womit sich wunderbar auch mehrere WP-Installationen verwalten lassen. Diese Android-App findet ihr entweder im Market, wenn ihr direkt nach wordpress sucht (sie heisst identisch und ist von Automattic Inc.), oder mit eurem Android-Handy nachfolgenden QR-Code scannt (sofern ein Barcode-/QR-Scanner bereits installiert ist – OkoTag funktioniert ganz gut, da dann automatisch in den Market gewechselt wird):

Was kann man mit der WordPress-App machen?

Grundsätzliche Verwaltungsaufgaben in den Bereichen Kommentare, Posts und Pages. Eigentlich auch die drei wirklich wichtigen Dinge, die man dann auch eventuell mobil erledigen möchte. Wobei den meisten wohl schon mit dem Kommentar-Management geholfen sein sollte; interessanterweise ist es auch der erste Tab nach dem Einloggen.

Kommentare

Comments können genehmigt, wieder auf unmoderiert gesetzt, als Spam markiert oder beantwortet werden. Direkt neue Kommentare zu schreiben ist nicht möglich (auch nicht über den Posts-Abschnitt).

Posts

Bei Posts kann man sich eine Vorschau oder die Kommentare zum Beitrag anzeigen lassen. Eine Bearbeitungsfunktion ist auch mit an Bord. Titel, Inhalt, Tags und Kategorie kann eingestellt und modifiziert werden. Auch der Status kann zwischen veröffentlicht oder nicht gewechselt werden (Häkchen setzen bzw. entfernen), leider kann kein Datum verändert werden, sodass eine zeitgesteuerte Veröffentlichung nicht möglich ist. Mit dem Plus-Symbol unten in der linken Ecke lässt sich auch prima ein neuer Post anlegen.

Zum Bearbeiten stehen einem nur Quicklinks für Fett, Kursiv, Links und Zitatblöcke als Hilfe zur Verfügung, alles weitere muss manuell eingetippt werden (HTML-Ansicht, kein WYSIWYG!). Bilder lassen sich von der SD-Karte aus hinzufügen. Ein auf dem Android neu angelegter Post, der nicht veröffentlicht wurde, wird zuallererst als Entwurf lokal gespeichert! Dies sollte man nicht vergessen, da man sich sonst später sicher dumm und dämlich sucht im WordPress und dort nix vorfindet.

Aber man hat hier auch weiter gedacht: lokale Entwürfe lassen sich zum Blog übertragen ohne sie damit gleich zu veröffentlichen. Dazu einfach in der Posts-Übersicht auf den Entwurf langdrücken (= lange gedrückt halten) und die Hochlade-Funktion auswählen. Ungetestet aber sich analog funktioniert es wohl dann auch mit Posts, die man gleich veröffentlichen will. (Es steht dann in der Übersicht der Hinweis direkt unter dem Titel, dass der Beitrag publiziert werden soll.)

Pages

Zu den Pages muss nichts weiter gesagt werden, es verhält sich alles analog zu den Posts. Nur hier fehlen Tags und Kategorie-Auswahl gänzlich. Wer bei Pages also mit Tags arbeitet, muss dies dann im Blog nachholen.

Fazit

Alles in allem eine schon gut durchdachte und gelungene App, die dadurch überzeugt, dass sie problemlos funktioniert. Das wpToGo hatte mich leider nicht sehr überzeugt.

Übrigens: es ist egal, ob man ein selbst gehostetes WordPress oder ein WordPress.com-Blog eingibt, die App unterstützt beides.

Nochmals der Code in klein:

Also: ausprobieren!

Original-Infos unter http://android.wordpress.org/

Feel free to Flattr this post at flattr.com, if you like it.

Feel free to Flattr this post at flattr.com, if you like it.

Statscraft

Feel free to Flattr this post at flattr.com, if you like it.

Ausgangsbasis ist die unter WordPress Codex geschilderte Funktion wp_list_comments() und die Möglichkeit, dadurch eine Kommentarliste eines bestimmten Typs anzeigen zu lassen.^[01]

Voraussetzung ist daher, dass man sich mit Theme-Development in WordPress auskennt!

Ich musste leider zwei unangenehme Dinge feststellen:

1. Die Variable $comments_by_type scheint nicht mehr zu existieren, die alternative Variante im Kommentar auf sivel.net hab ich erst gar nicht probiert, da sie im Codex nicht dokumentiert scheint und es also eher experimentiell wäre.
2. Das Zählen nach Typen funktioniert nicht, sondern die Standardfunktion gibt nur die Summe aller Typen zurück.

Nun gibt es zumindest für die Zählproblematik bereits einige Lösungen, aber das saubere Trennen ist damit nicht automatisch gelöst. Denn: die obige if-Abfrage lässt meinen Codeblock nicht ausblenden oder nicht anzeigen (hängt davon ab, ob Verneinung drin oder nicht, es gibt im Netzt BEIDE Varianten). Nämlich egal ob Kommentare vorhanden sind oder nicht, $comments_by_type bleibt für jeden Typ IMMER leer. Ergo: nutzloses Zeug!

Nun habe ich mal durch Debugging herausgefunden, was denn die $comments so enthält, und prompt viel mir auf, wie des Rätsels Lösung ist, und zwar für beide Probleme gleichzeitig!

Im Array $comments sind alle Kommentare jeglichen Typs hinterlegt, und das ist cool. Damit kann man gleich eine Menge anstellen.

Ich übergebe die $comments einer eigenen Funktion (die dann in der functions.php des Theme hinterlegt ist) und werte erst einmal den ganzen Kram aus. Das Schöne nebenbei: es muss mich noch nicht einmal die Verschachtelung kümmern, sofern man diese nutzt, denn die Ebenentiefe steckt als Wert im jeweiligen Kommentar drin und wird erst durch WordPress selbst ausgewertet.

Was macht die Funktion?

Sie geht das Array $comments durch und zählt jeden Kommentar, der einem bestimmten Typus entspricht, also alle Kommentare oder Tweetbacks oder Pingbacks oder Trackbacks oder Pings allgemein (also Ping- und Trackbacks). Diesen Wert liefert es als Rückgabewert und schon haben wir zwei Fliegen mit einer Klappe geschlagen. Wenn der Zähler größer Null ist, dann haben wir also Kommentare und lassen erst somit die Auflistung beginnen. Zudem können wir den Wert auch als Anzeige nutzen — Blogger sind statistikgeil und machen gern Schwanzvergleiche.

Code und Beispiel

Der Code:

Funktion count_comment_type() [theme/functions.php]: count_comment_type (PHP-Code)

Beispiel-Einbindung:

Beispiel-Codesnippet in der theme/comments.php: count_comment_type in comments.php

Nachdem was ich bisher so gesehen habe, finde ich meine Lösung sehr praktisch und klein ist sie zudem auch noch. Ich verwende sie jedenfalls in einem selbst erstellten Theme auf einem anderen Blog und bin damit sehr zufrieden. Ein Beispiel könnt ihr in diesem Beitrag auf mannaz.cc sehen, wo alle Typen auftreten.

Was die Funktion nicht macht!

Die Funktion kann nicht wie comments_number()^[02] einen schönen Text zurückliefern, dies sollte aber mit ein bisschen Geschick selbst zu bewerkstelligen sein. Und: Sie zählt nicht alle Typen aufsummiert; auch das kann man selbst erledigen, indem man die jeweiligen Aufrufe vor die ganzen Schleife packt und die Einzelergebnisse selbst addiert. Ich brauchte das bisher so nicht und daher wurde dies nicht implementiert.

Für PHP-Kenner: um Ressourcen zu sparen, verwende ich in der Funktion eine Referenz auf $comments (siehe das & vor $c in der Parameterliste); also vermeidet es tunlichst, irgendetwas mit der Variable $c anzustellen! Nur abfragen und belassen!^[03]

Möge euch der Code zu Nutze sein!

Für Fehler und einer dadurch zerstörten WordPress-Installation übernehme ich keine Haftung!

Feel free to Flattr this post at flattr.com, if you like it.

Folgender Artikel ist etwas für technisch interessierte Leser. Ich schildere hier meine Erfahrung mit dem Webserver nginx, dem FCGI-Dienst spawn-cgi und einem darauf laufenden WordPress.

Dass das Blogsystem WordPress nicht unbedingt sparsam mit den Ressourcen umgeht, ist mittlerweile fast allen klar. Dem zu einem fast vollwertig gewachsenen CMS spendiert man auch immer fleißig weitere Funktion

alitäten, viele Dinge, die früher als Plugins installiert werden mussten, wandern in den Kern. Und dennoch wird der eine oder andere Blogger auch weiterhin seine Plugins installieren, da WordPress halt nicht die perfekte eierlegende Wollmilchsau ist. Dies alles geht natürlich immer zu Lasten der Performance. Es wird mehr RAM benötigt, auch die PHP-Version muss nun mindestens 5 (5.1?) sein, und die Ladezeiten beim Besucher schnellen da gern mal in die Höhe. Mit den falschen Plugins können das mal mehrere Sekunden sein, gefühlt wie Minuten!

Aber ich hab nun die Erfahrung gemacht, dass es auch anders geht. Doch nicht jedem ist dieses Glück beschieden. Denn: man muss schon am besten einen eigenen Server haben (ein VPS^[01] geht auch).

Warum?

Die Lösung für ein wirklich flottes (und auch RAM schonenderes) WordPress liegt halt auch in der darunter liegenden Architektur, die verwendet wird. Das Gespann Apache mit mod_php ist jedenfalls aus meiner Sicht schon die denkbar ungünstigste Variante, die aber sicher in den meisten Fällen auf Webservern zur Anwendung kommt. Fast jeder Webhoster wird diese billige Lösung nutzen – sehr wohl auch zum eigenen Leidwesen! Da es nämlich auch anders geht und die Anbieter so auch bessere Qualität liefern könnten.

Nun kann man zwar weiterhin auf Apache bauen, aber für PHP eine andere Schnittstelle nutzen: FCGI, FastCGI oder ein vergleichbarer CGI-Wrapper wären Alternativen. Getestet habe ich das jetzt nicht (also Apache+FCGI), aber ich vermute stark, dass hier durchaus das eine oder andere Megabyte an RAM gespart wird, ohne Caching nutzen zu müssen (was wohl eh nicht so trivial ist – damit beschäftige ich mich wohl auch erst später).

Nun sollte man wissen, dass aber auch der Apache selbst nicht unbedingt zu den sparsamsten Webservern gehört, außerdem ist er auch manchmal recht träge. Es gibt da draußen viele, viele andere Programme, die auch ihren Dienst tun. Okay, manche Funktionen werden dann nicht zur Verfügung stehen, aber mal Hand aufs Herz: wer von euch weiß überhaupt, was die Webserver-Kiste denn wirklich kann? Und dann noch die ganzen Module beim Apache … da ist man manchmal auch froh, wenn der Server einfach nur das macht, wofür er gedacht ist: Seiten ausliefern!

Kleines Wunder: nginx

Und das tut dann auch die nun von mir verwendete Alternative und nennt sich nginx. Dieses feine Stück Software kommt ursprünglich aus russischen Landen, erfreut sich aber nun einer wohl weltweiten Beliebtheit. Weil er schlank ist, weil er kaum Ressourcen beansprucht und weil er eigentlich sogar etwas mehr kann als der Apache: er ist nicht nur ein reiner Webserver sondern auch ein guter Proxy. Viele große Seiten oder Dienste verwenden wohl auch schon den nginx zum Verteilen der Lasten (denn das kann er auch so ganz nebenbei – Stichwort Loadbalancing). Nun interessierte mich vordergründig nicht der Proxy oder Loadbalancer, sondern der Webserver und dessen Leistung – denn auf einem einzigen Server gibt es zumindest nicht zu viel zu verteilen an Last. Zum Thema Proxy komme ich aber noch einmal, dass brauchen wir nämlich dann doch noch in einer anderen Form.

Mein Zwischenbericht lautet bis hierher: der nginx ist verdammt schnell! Und klein! Und ich will behaupten, dass er auch unter großer Beanspruchung dem Apache haushoch überlegen sein wird.

Schnell, schneller, spawn it!

Doch damit es nicht nur bei statischen Seiten so schnell geht, muss also hinter dem Webserver auch das PHP vernünftig ackern. Und das erreichen wir im Falle von nginx nicht mit einem simplen PHP-Modul wie im Apache, sondern hier muss man schon noch ein wenig mehr Hand anlegen. Ich habe mich für die Variante mit spawn-fcgi entschieden, da es dazu einige englischsprachige Anleitungen gab und diese CGI-Variante wohl auch mit eines der vielversprechendsten ist, es gibt noch einen anderen FCGI-Server, der mich interessiert, den ich aber erst zu späterer Zeit testen werde (fpm soll der Testkandidat sein, wer hier schon Erfahrung gesammelt hat, gern her damit!).

Beim nginx geht dieser Übergang auch recht einfach, theoretisch ist die Lösung eine Art implementierte Proxy-Geschichte. Tatsächlich kann die CGI-Anwendung sogar auf einem anderen Server laufen als der Webserver! Die Grundkonfiguration ist meist in der default-Site hineinkommentiert, andernfalls einfach die vielen Beispiele im Netz nehmen, da man hier oftmals einen ungeschriebenem Standard folgt. Also für eine Site einfach mal die CGI-Konfiguration vorbereitet und weiter geht es mit dem CGI-Dämonen, der da werkeln soll.

Der Helfer spawn-cgi ist meistens im Paket für einen anderen leichtgewichtigen Webserver vorhanden, dem lighttpd. In Ubuntu z. B. muss man also diesen installieren (er muss aber dagegen nicht laufen, kann also -falls er automatisch starten sollte- getrost deaktiviert werden). Dann frickelt man sich den spawn-cgi so zurecht, dass er als Dienst läuft und auch bei einem Reboot automatisch gestartet wird. Ganz nebenbei kann man dann auch mal die php.ini für die CGI-Variante anpassen, da diese Konfiguration nicht unbedingt dieselbe wie für den Apache sein muss. In allen gängigen Linux-Distributionen wird nämlich gern eine ini-Datei für die möglichen drei Anwendungsfälle vorgehalten: Apache, CGI und CLI (die Konsolenvariante).

Wenn man nun ausreichend getestet hat, dass der spawn-cgi läuft, dann sollte man nun alles zusammen testen. Nicht vergessen, die neue Konfiguration der Site im nginx durch einen Restart selbigen zu aktivieren. Mit der phpinfo()-Funktion geht der Test ganz gut und man bekommt auch alle nötigen Infos der Umgebung gleich mit.

WordPress, it’s your turn!

Jetzt kann man endlich ein WordPress installieren. Achja, wer die schönen Permalinks haben will, muss nochmal kurz Hand anlegen. nginx bietet keine .htaccess-Unterstützung, aber im Falle von WordPress braucht man ohnehin nur eine simple Rewrite-Regel, die ruhig fest in die Konfiguration eingearbeitet werden kann. Den Rest übernimmt WordPress zum Glück von allein dank internem Rewriting.

Was mir sofort auffällt: die Reaktionszeiten sind beeindruckend! Es fühlt sich fast so an, als wenn man auf einem lokalen System testet.

Nachdem ich WordPress eingerichtet und einige Plugins installiert und aktiviert hatte, war ich vollends überzeugt, den richtigen Riecher gehabt zu haben.

Im Schnitt kann ich sagen, dass WordPress nun nur noch rund die Hälfte des RAMs frisst als via Apache mit mod_php und dafür auch noch schneller reagiert als der Bruder im Indianerdorf. Und dies, obwohl wir jetzt auf dem Server auf Prozessebene vielleicht eher einen Schritt zurück gemacht haben (nginx-Prozess und spawn-cgi-Prozess), was aber auch wieder ein Vorteil ist. Denn durch die Trennung von Webserver und FCGI-Daemon habe ich auch etwas mehr Flexibilität gewohnnen, da ich Pferd und Sattel beliebig wechseln kann anstatt ein Pferd mit festgeschraubtem Sattel zu nutzen. Klar, ich könnte auch das Schlachtross Apache weiter verwenden, aber ich will einen schnellen Gaul statt Limousine mit Pool. Letzteres ist zwar chic, aber ersteres im Internet wohl wichtiger.

Fazit

Ich werde wohl mit vielen meiner Projekte umsatteln. blogcraft läuft zwar noch auf dem Apache, aber z. B. mein privates Blog mannaz.cc rennt bereits mit dem hier geschildertem Szenario. Mit einem Testblog werde ich wohl auch mal andere FCGI-Dienste wie den erwähnten fpm testen, um auf der Ebene auch noch mal separat vergleichen zu können. Doch mit dem spawn bin ich schon sehr zufrieden.

Mein Webdesign-Gedanke setzt sich nun auch technisch fort, denn ich mag minimalistische Sachen. Man kann vielleicht dann nicht soviel rumspielen, aber dies ist in Produktivumgebungen wohl auch weniger ratsam.

Was man jetzt noch mit Caching-Möglichkeiten wie memcached & Co. rausholen kann, bleibt bei mir auch noch offen. Bisher sehe ich da aber auch noch keinen Bedarf, da alles sowas von flott und flüssig geht, dass ich wohl noch reichlich Zeit habe, mir da noch was anzulesen und dieses zu testen.

WordPress funktioniert übrigens reibungslos. Dass z. B. keine .htaccess zum Tragen kommt, stört überhaupt nicht, es sei denn, man verwendet Plugins, die darauf aufbauen, was bei WordPress-Caching-Lösungen durchaus der Fall ist. Mit der hier geschilderten Lösung sollte der Blogger aber ohnehin erst einmal ohne WP-Cache oder WP Super Cache auskommen können.

Zusammenfassung der technischen Details

• Webserver: nginx
• FCGI-Dienst: spawn-cgi (im lighttpd enthalten)
• WordPress mit einigen Plugins
• RAM und Geschwindigkeit – Vergleich
  • Blog auf Apache mit mod_php: rund 25 MB (in Spitzen hatte ich auch mal bis zu 50 MB!)
  • Blog auf nginx mit spawn-cgi: 50 % weniger RAM-Verbrauch! Dafür aber auch gefühlte 1000 % schneller!

Wer sich dafür interessiert, wie das technisch im Detail funktioniert, melde sich hier in den Kommentaren. Bei genügend Feedback werde ich dann ein Tutorial erstellen, da es im deutschsprachigen Raum kaum gute Anleitungen hierzu gibt.

Auch noch offene Fragen können wir hier gemeinsam klären, da es hier ja schon hochtechnisch hergeht.

Feel free to Flattr this post at flattr.com, if you like it.