market://search?q=pname:org.wordpress.android

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/

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.

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

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!

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.

Keine verwandten Posts vorhanden.

BlogcrafterChris on blogcraft, 2009. | nginx, PHP und Wordpress (Permalink) | Keine Kommentare bisher | Add to del.icio.us
Post tags: apache, CGI, FastCGI, FCGI, fpm, konfiguration, nginx, PHP, server, webserver, Wordpress

Nun, ich dachte zwar, mit der Version 2.8.5 wäre nun das Ende des 2.8er-Zweiges erreicht, aber scheinbar hat man doch noch eine weitere Lücke gefunden. Die Details dazu kann man in den Blogs zu Wordpress nachlesen (deutsch, englisch).

Da wohl zwei teilweise sehr kritische Stellen geflickt worden sind, ist eine Aktualisierung anzuraten. Zum einen betrifft es die “Press This”-Funktion, zum anderen die Upload-Funktion. Wer eines von beiden häufiger bzw. regelmäßig benutzt, kommt um das Update nicht herum, um ganz sicher zu fahren.

Viel Spaß beim weiteren Update-Marathon 2.8! Möge der Zweig 2.9 nicht ganz so buggy sein und uns mit monatlichen (oder gar wöchentlichen) Updates verschonen …

Die Version 2.9 steht bald in den Startlöchern und damit wird der 2.8er Zweig abgeschlossen. Wie schon früher üblich, wird noch einmal ein letztes Update herausgegeben, ein sogenanntes Hardening-Release, sprich: es wird nochmals abgehärtet, sicherer gemacht. Ist an sich eine gute Sache, zumal nicht jeder unbedingt gleich auf den nächst höheren Versionszweig aufspringen will. Oftmals muss man ja warten, bis z. B. auch alle Plugins durchgetestet sind, je nach dem, wie stark der Kern von Wordpress sich gewandelt hat und dementsprechend die Plugins angepasst werden müssen.

Wordpress 2.9 befindet sich bereits im Beta-Stadium und wird sicher in ein paar Wochen veröffentlicht (also ich hoffe jedenfalls noch dieses Jahr). Auf jeden Fall will man den Betatest einfacher gestalten und es wurde hierzu auch ein Plugin entwickelt. Eventuell werde ich mir dieses auch mal anschauen.

Infos zum Hardening-Release auf dem Wordpress-Entwicklerblog (englisch); Beta-Tester Infos und BT-Plugin hier.

Nur eine kurze Meldung:

In der Version 2.8.1 wurden wohl einige Dinge übersehen, diese wurden nun gefixt. Es handelt sich, wie bereits bei der Version 2.8.2 um ein Sicherheitsupdate und es wird daher dringend empfohlen, dieses zu installieren.^[01]

[UPDATE] Ich habe nun auch die Wordpress NoFollowFree Edition auf 2.8.3 gebracht, der Patch kann nun für die aktuelle Wordpress-Version heruntergeladen werden.

Kaum das die Version 2.8.1 von Wordpress in freier Wildbahn ist, lese ich soeben, dass nun auch bereits die nächste Aktualisierung verfügbar ist: ein sicherheitsrelevantes Update. Ich gehe daher davon aus, dass alle Benutzer des 2.8er Zweiges definitiv aktualisieren sollten.

Hier hat es also gar nicht sehr lange gedauert mit dem nächsten Bugfix, was mich etwas überrascht. Sonst sind sie nicht so schnell gewesen, dieses Mal hatten sie es dafür umso eiliger. Wer es also bisher versäumt hatte, sollte nun ganz gewiss auf Wordpress 2.8.2 updaten.^[01]

Wenn das weiterhin so häufig läuft, sollten die Entwickler statt der klassischen Updatemethode (komplett neues WP aufspielen) nun doch eine Art Patch-Update einbauen, auch wenn das System selbst recht schlank ist. Aber gelegentlich hört man ja von zerschossenenen Installationen während des Update-Prozesses. Je weniger Dateien ausgetauscht werden müssen, desto sicherer wird aber auch diese Methode.

Im Übrigen sollten sie beim eingebauten Update auch gleich das Datenbank-Backup mitanbieten.^[02]

Nun auch offiziell im wordpress.org-Pluginverzeichnis zu finden: http://wordpress.org/extend/plugins/wp-permalauts/

Wie hier auf der Pluginseite nachzulesen ist, wollte ich das nützliche Plugin wieder aufgreifen und der Allgemeinheit zur Verfügung stellen. Außerdem ist hiermit sichergestellt, dass es im Zweifelsfall weiterentwickelt werden kann. Wer weiß, ob in Zukunft immer noch alles so einwandfrei funktionieren wird wie bisher.

Der Bedarf ist ja da, denn gerade in der deutschen Blogosphäre muss man sich mit den Umlauten herumschlagen, die gerade in den URLs für Probleme sorgen. Und gerade Wordpress fabriziert eher unschöne Links, sodass man sich hier mit eigenen Konvertierungsregeln behelfen sollte.

Das Ursprungsplugin von otaku funktioniert zwar weiterhin, würde mich aber freuen, wenn das frische WP Permalauts auch seine Anhänger findet.

Also, informieren und installieren: WP Permalauts

Habe soeben eine neue Version von Statpress SEOlution veröffentlich. Wie gehabt, kann das Wordpress Plugin über das offizielle Repository von wordpress.org bezogen werden.

Infos zum Plugin Statpress SEOlution

Diejenigen, die bereits auf die nächste Wordpress Nofollowfree Edition warten, müssen sich noch ein wenig gedulden, denn diesmal möchte ich selbst auf die erste Bugfix-Version warten, in den letzten Tagen berichteten so einige hier und da, dass es beim Update auf die Wordpress Version 2.8 einige Probleme gab.

Daher habe ich den Patch auch noch nicht vorbereitet und ich werde die Version 2.8 damit überspringen. In den meisten Fällen mag es ohnehin ratsam sein, nicht immer sofort auf die nächst höhere Version zu gehen, wenn noch keine Erfahrungsberichte zum Produktiveinsatz vorliegen; gerne zeigen sich der eine oder andere Bug tatsächlich erst im Livebetrieb.

Im Übrigen überlege ich, auch nur noch den reinen Patch und keine vollwertige Installationspakete mehr anzubieten. Was meint ihr? (Stimmen von Befürwortern und Kritikern gern gelesen.)