Was die Leichtigkeit betrifft: Ich wünsche mir einfach nur, dass es mal wieder weniger RAM verbraucht, denn ein gepimptes WordPress verschlingt bei mir ohne PHP-Caching und -Optimierung gut und gerne mal 50 bis 70 MiB RAM!^[01] Das war früher nicht so, zumal Webhoster auch gern das Limit bei 32 oder gar noch weniger MiB RAM ansetzten. Und ja, WordPress selbst konsumiert das meiste davon selbst, aber auch ein Redesign der Plugin-Maschinerie würde hier sicher noch Einsparungen bringen.

Zurück zur Auswertung der WordPress-Versionen:

Als Untersuchungsgrundlage benutze ich nur die englischen Archive im ZIP-Format. Zudem liste ich hier nicht alle Versionen auf, sondern ausgewählte Meilensteine bzw. Bugfix-Releases.

Schritt 1 — Wie groß sind die Archive?

Folgendes wurde dabei zu Tage gefördert:

MiB = 126.976 Byte (IEC-Präfixe zur Basis 2; Umrechnungsfaktor: 1024)

                         Datei      Größe  Steigerung
-----------------------------------------------------
       wordpress-0.71-gold.zip  0.220 MiB     --.-- %
     wordpress-1.0.1-miles.zip  0.265 MiB     20.69 %
   wordpress-1.5-strayhorn.zip  0.338 MiB     27.61 %
           wordpress-1.5.2.zip  0.349 MiB      3.06 %
             wordpress-2.0.zip  0.576 MiB     65.21 %
          wordpress-2.0.11.zip  0.611 MiB      6.11 %
             wordpress-2.1.zip  0.810 MiB     32.53 %
             wordpress-2.2.zip  0.931 MiB     14.99 %
             wordpress-2.3.zip  0.993 MiB      6.68 %
             wordpress-2.5.zip  1.304 MiB     31.30 %
             wordpress-2.6.zip  1.442 MiB     10.51 %
             wordpress-2.7.zip  1.764 MiB     22.36 %
             wordpress-2.8.zip  2.240 MiB     26.98 %
             wordpress-2.9.zip  2.399 MiB      7.09 %
             wordpress-3.0.zip  2.828 MiB     17.88 %
             wordpress-3.1.zip  2.953 MiB      4.42 %
           wordpress-3.1.2.zip  2.953 MiB      0.01 %
-----------------------------------------------------
Steigerung von Version 0.71 zu 3.1.2:       1344.68 %

Wie man gut erkennen kann, gab es teilweise erhebliche Steigerungen in der Archivgröße, das wird sich auch sicherlich in der entpackten Ordnergröße widerspiegeln, aber dazu gleich mehr.^[02]

Spannend finde ich hierbei einfach mal, das sich von der ersten Version bis zur aktuellen eine Vervielfachung um mehr als das 13-fache stattgefunden hat.

Hinweis zu den Größenangaben: Ich rechne grundsätzlich nur mit dem Faktor 1024 (IEC-Präfix, Basis 2), da dies auch alle Betriebssysteme tun, mit dem Faktor 1000 (SI-Präfix, Basis 10) rechnet eigentlich nur die Wirtschaft, die uns damit gern verwirrt. Mi steht dabei für Mebi-, was das Äquivalent zum SI-Präfix Mega- ist. Aber das ist ja eigentlich auch ein völlig anderes Thema …

Schritt 2 — Wie groß sind die Versionen im ausgepackten Zustand?

e-Größe gibt in der Liste die entpackte Größe an:

                        Archiv    e-Größe   Steigerung
------------------------------------------------------
       wordpress-0.71-gold.zip  0.603 MiB      --.-- %
     wordpress-1.0.1-miles.zip  0.863 MiB      42.95 %
   wordpress-1.5-strayhorn.zip  1.021 MiB      18.35 %
           wordpress-1.5.2.zip  1.053 MiB       3.14 %
             wordpress-2.0.zip  1.653 MiB      57.03 %
          wordpress-2.0.11.zip  1.765 MiB       6.75 %
             wordpress-2.1.zip  2.337 MiB      32.40 %
             wordpress-2.2.zip  2.756 MiB      17.93 %
             wordpress-2.3.zip  2.953 MiB       7.14 %
             wordpress-2.5.zip  3.987 MiB      35.04 %
             wordpress-2.6.zip  4.360 MiB       9.36 %
             wordpress-2.7.zip  5.383 MiB      23.44 %
             wordpress-2.8.zip  6.840 MiB      27.07 %
             wordpress-2.9.zip  7.293 MiB       6.62 %
             wordpress-3.0.zip  7.925 MiB       8.67 %
             wordpress-3.1.zip  8.236 MiB       3.92 %
           wordpress-3.1.2.zip  8.237 MiB       0.02 %
------------------------------------------------------
Steigerung von Version 0.71 zu 3.1.2:        1365.07 %

Interessant ist hier auch schon einmal das Endergebnis: nahezu die selbe Steigerungsrate wie bei den gepackten Archiven, mit nur einer minimalen Abweichung; also fast das 14-fache von der ersten bis zur aktuellen Version.

Wie man erkennen kann, sind die Kompressionsraten in ähnlichen Bereichen, manchmal konnte mehr oder weniger gut komprimiert werden, aber an der generellen Steigerung über die Zeit verändern diese ziemlich wenig. Im Schnitt sind die zip-Archive entpackt rund 3× so groß. Die tar.gz-Archive sind übrigens nur unwesentlich kleiner als die zip-Pedants, also viel mehr Kompression ist aus dem PHP-Quellcode wohl nicht herauszuholen.

Ich habe zur Sicherheit einmal auch das erste und letzte Archiv entpackt und deren Größe mit dem Unix-Befehl du überprüft, bis auf eine kaum spürbare Abweichung stimmen die Zahlen direkt aus den Archiven (der tatsächlich verbrauchte Plattenplatz hängt unter anderem auch vom verwendeten Filesystem ab).

Fazit

Letztlich bleibt, dass WordPress sich im Größenumfang immer nur erweitert. Jede Nachfolgeversion, egal ob Hauptversion (0.x, 1.x, 2.x, 3.x), Minor-Level (zweite Stelle) oder gar Patch-Level (dritte Stelle; Bugfix-Releases), wurde immer nur größer und größer. Der bisher langlebigste Zweig 2.x hat dabei den höchsten Zuwachs erlebt, von anfänglich mal rund 1,8 MiB auf letztlich 7,3 MiB, stolze 5,5 MiB mehr, oder als Faktor ausgedrückt rund 4 Mal so groß.

Bei der Rate dieses Zweiges würde uns am Ende vom 3.x-Zweig eine 32 MiB große Installation erwarten und in Version 4 würde dann die 100-MiB-Marke dann auch endlich durchbrochen.

Was man bei der ganzen Rechnerei nicht vergessen darf: das ist nur eine blanke Installation von Dateien! Keine Datenbank-Größe mitgerechnet (hätte mir zum Testen jetzt dann doch zu viel Zeit in Anspruch genommen), keine Plugins oder eigene Themes, keine hochgeladenen Dateien.

Allein der Speicherplatzverbrauch von blogcraft.de liegt aktuell bei 312 MiB (bin ich gerade selbst erstaunt), die Datenbank umfasst dank Statistik-Plugin auch einige zig Megabyte, wobei ich die entsprechenden Tabellen auch einmal von Zeit zu Zeit leere, da MySQL+Wordpress auf kleinen System irgendwie gerne lahmt, wenn die Datenbank zu groß wird.

Wer keine Statistiken irgendwelcher Art sammelt oder irgendwas mitloggt, der kann die Datenbankgröße aber in aller Regel vernachlässigen, da Texte im Vergleich zu Bildern z. B. viel weniger Platz in Anspruch nehmen.

Fotoblogger sind hier also im Nachteil, die interessieren sich dann aber auch nicht mehr für den Verbrauch einer Blanko-Wordpress-Installation. ;o)

asaaki on blogcraft, 2011. | WordPress, Versionen und Größen (Permalink) | Keine Kommentare bisher | Add to del.icio.us
Post tags: 0.71, archiv, Größe, Speicher, Verbrauch, wordpress, Wordpress 3.1.2

Vorab: Automattic ist die Firma, die das Hosting für WordPress sowie für das offizielle Plugin- und Theme-Verzeichnis bereitstellt, natürlich ist das auch die Firma, die die Entwicklung vorantreibt und koordiniert.

Nun zur Problematik mit dem Datenhunger: Zweimal am Tag fragt jede WordPress-Instanz (egal ob Single oder Multisite) die Server von wordpress.org, ob es neue Versionen für WordPress, Plugins und Themes gibt. Seit neuestem gibt es nun im Pluginverzeichnis auch etwas mehr an statistischen Daten, die aber bei mir und anderen Fragen aufgeworfen und ein mulmiges Gefühl hinterlassen haben (siehe oben verlinkten Beitrag). Da Automattic diese Server bereitstellt, erhalten sie unheimlich viel Einblick in die aktuelle WordPress-Landschaft, was nachfolgend kurz beleuchtet wird …

Während man zwar durch ein Plugin auch die Aktualisierungsabfrage komplett deaktivieren kann (z. B. hiermit), hat man aktuell keine Möglichkeit, die Datenflut für die Abfragen selbst einzudämmen. Unsere Blogs funken nicht einfach nur nach Hause, sie machen sich ganz schön nackig dabei!

Wenn man sich mal die wp-includes/update.php um die Zeile 58 anschaut, dann wird einem bereits schnell klar, dass ohnehin regelmäßig viel zu viele Daten an wordpress.org übertragen werden. (Dies ist nur der API-Call für den WP-Core!)

Aber die ganze Datei birgt weitere interessante Offenbarungen.

Spannender wird es nämlich dann bei Plugins/Themes, wo man im Quellcode nicht sofort erkennt, was für Daten da übertragen werden. Nach kurzer Nachforschung vermute ich aber (korrekterweise), dass auch hier unheimlich viele Daten übermittelt werden (siehe Datei wp-admin/includes/plugin.php, function get_plugin_data(), die definitiv auch durch wp_update_plugins ebenfalls mit aufgerufen wird).

Dank PHPXref (Ref für WordPress) oder einer guten IDE kann man schon mal schnell die ganzen Querverknüpfungen aufspüren, jedoch muss man für genaue Daten und deren Fluss mal eine Entwicklungsumgebung bedienen und den Debugger anwerfen, da die Kommunikation eben nicht transparent im Code hinterlegt ist. Der Kommentarblock aber verrät schon vieles:

  38   * Plugin data returned array contains the following:
  39   *        'Name' - Name of the plugin, must be unique.
  40   *        'Title' - Title of the plugin and the link to the plugin's web site.
  41   *        'Description' - Description of what the plugin does and/or notes
  42   *        from the author.
  43   *        'Author' - The author's name
  44   *        'AuthorURI' - The authors web site address.
  45   *        'Version' - The plugin version number.
  46   *        'PluginURI' - Plugin web site address.
  47   *        'TextDomain' - Plugin's text domain for localization.
  48   *        'DomainPath' - Plugin's relative directory path to .mo files.
  49   *        'Network' - Boolean. Whether the plugin can only be activated network wide.

Verknüpft mit Plugin-Status, WordPress-Version und der Quell-URL/IP weiß Automattic also, welche Plugins ich wann und wo (aktiv) benutze.

Wer mag, kann ja mal einen kompletten und ausführlichen Trace vollziehen, ich hoffe, dabei wird dann niemandem schlecht. Mir ist’s aber schon beim Gedanken daran …

Also werden alle 12 Stunden aktuelle Daten an api.wordpress.org gesendet, wie meine Plugin- und Theme-Zusammenstellung ist, auch die WordPress-Version inklusive einiger Laufzeit-Umgebungsdaten wie PHP-, MySQL-Version und noch so einige für den Update-Vorgang irrelevante Daten.

Ich befürchte, Automattic weiß schon viel zu lange viel zu viel über unsere WordPress-Installationen und die verwendeten/aktiven Plugins. Und dass sie nun mit uns Plugin-Entwicklern endlich diese Daten im gewissen Umfang teilen, ist dann sicherlich nur ein Gnadenakt!

<ironie>
Ich verbeuge mich demütigst und erfurchtsvoll!
</ironie>

Fraglich ist eigentlich, warum man den Versionscheck nicht der jeweiligen WordPress-Instanz überlässt statt dem API-Server alle Infos zu schicken. Aus meiner Sicht bedarf es ja nur des eindeutigen Plugin/Theme-Namen bzw. eine informationsfreie/datenarme Anfrage für die zuletzt aktuelle WordPress-Version (ggf. ist der Sprachcode in der Anfrage noch zulässig).

Wenn ich das so recht bedenke, muss man hier eigentlich ein Plugin für die anonymisierte Aktualisierung entwickeln, auch eine Art Update-Proxy-Dienst fiele mir da spontan ein …

asaaki on blogcraft, 2010. | [WordPress] Automattics Datenhunger (Permalink) | Keine Kommentare bisher | Add to del.icio.us
Post tags: anonym, API, api.wordpress.org, Automattic, proxy, update, wordpress, wordpress.org, wp_update_plugins, wp_update_themes, wp_version_check

Gestern kam ich ja auf die wahnwitzige Idee, den zugrunde liegenden Ubuntu-Server von 9.04 auf 10.04 LTS zu aktualisieren. Zur Aktualisierungsmaßnahme gehörte dann aber auch, dass ich von dem für mich etwas sperrig anmutenden Zend-Server weg und wieder auf eine schlankere PHP-Basis umschwenken wollte. Dies tat ich auch. Dabei installierte ich PHP-FPM (http://php-fpm.org/), welches sich mit Ubuntu 10.04 auch wesentlich einfacher einrichten ließ (habe ich schon auf einem anderen Server erfolgreich erprobt). Der Vorteil bei FPM ist, dass damit umständliche CGI-Serverumgebungen vermieden werden und die PHP-Prozesse gekapselt laufen (also kein mod_php oder sonstwie tief in den Webserver verankerte Lösungen).

Wer selbst ein Setup mit nginx und PHP-FPM auf Ubuntu 10.04 LTS aufsetzen will, sollte sich folgende Anleitung zu Gemüte führen und diesen Kommentar berücksichtigen, welcher die beschriebene Vorgehensweise wesentlich vereinfacht.

Kurzanleitung:

1. PHP-ppa von brianmercer dem Repo hinzufügen [∞]
2. apt-get update
3. apt-get install php5-cli php5-common php5-suhosin
4. apt-get install php5-fpm php5-cgi
5. restart von nginx und php5-fpm
6. fertig!

Ggf. noch weitere PHP-Module nachinstallieren und php-fpm feinjustieren. PHP-FPM kann zwar selbst mehrere Gruppen verwalten (die man dann z. B. unter verschiedenen Ports oder Sockets anbietet), aber ich hab mich auf einem anderen System dazu entschlossen, init.d-Skript und Konfiguration zu splitten und mehrere unabhängige Instanzen aufzusetzen — es ist sicherlich nur eine Pseudo-Failsafe-Lösung, aber wenigstens wird nicht gleich die ganze CGI-Umgebung abgeschossen, falls ein FPM komplett abschmiert. (Wer jetzt noch mit mehreren phys./log. Servern und SAN arbeitet, kann hier sicherlich echte Failsafe-Lösungen aufsetzen; aber wer hat schon das Geld dafür?)

Nachdem ich dann alles gefixt und zum Laufen bekommen habe, ist mir dann doch aufgefallen, dass der Zend-Community-Server offensichtlich wirklich gut optimiert und die WordPress-Instanzen somit effektiv wenig RAM verbrauchten.

Mit PHP5 und FPM kam ich bei blogcraft und den vielen, vielen Plugins auf über 80 MiB RAM-Verbrauch, nach Deaktivierung und Deinstallation wirklich nicht benötigter Plugins lag ich immer noch im Bereich von 70 bis 75 MiB RAM. Also musste doch ein PHP-Cache her. Den hatte ich bereits schon installiert, aber noch nie benutzt, es war XCache, welches auch im Ubuntu-Repo zu finden ist (php5-xcache; Projektseite: http://xcache.lighttpd.net/). Diese Erweiterung für PHP muss man definitiv auch noch konfigurieren, da die Default-Einstellungen nicht zu gebrauchen sind, außerdem sollte man sowieso gleich den Admin-Zugang einrichten, damit man sich von der Arbeitweise des XCaches überzeugen kann.

Auch dies gestaltete sich wesentlich einfacher als gedacht, und die Speichernutzung reduzierte sich damit schon einmal um weitere Bytes, dennoch lag der Verbrauch immer noch bei rund 60 bis 66 MiB, was mir immer noch viel zu viel erschien. Aber man sollte XCache auch ein bisschen Zeit geben, da anfangs nur der Opcache für WordPress greift und die ersten PHP-Dateien überhaupt in dem RAM zwischengespeichert werden muss (wobei der Code wohl zudem noch in Maschinen(?)-Code übersetzt wird, was man beim XCacheAdmin gut daran erkennen kann, wenn in der Compile-Spalte ein yes steht). Letzlich kam ich noch auf einen Wert um die 40 bis 48 MiB.

Jetzt macht es aber im Falle von WordPress nicht nur Sinn, den reinen PHP-Code zu cachen, sondern auch häufig genutzte Variablen-Inhalte (die sich teilweise auch kaum ändern, z. B. Optionen), hierzu muss man aber WordPress selbst erst einmal beibringen, den XCache zu nutzen, denn dieser mischt sich bei Variablen eben nicht automatisch ein (sinnvollerweise!).

Hierfür gibt es nun auch ein “Plugin”, welches man nachinstallieren kann, leider nicht im WordPress-Plugin-Verzeichnis und leider auch nur in einer vielleicht etwas überalterten Fassung, aber immer noch lauffähig, wie mir scheint. Die Leute von neosmart haben sowohl für XCache als auch andere PHP-Caches/-Acceleratoren die nötigen object-cache.php Dateien geschrieben, die man einfach in /<wordpress>/wp-content/ ablegt.

Download: http://neosmart.net/blog/2007/xcache-and-eaccelerator-plugins-for-wordpress/

Eventuell hilft es, wenn man in der wp-config.php auch die Konstante define(‘WP_CACHE’, true) einträgt, da ich nicht glaube, dass WordPress von allein den Object-Cache aktiviert und nutzt.

Wenn man nun einen Blick in die XCache-Statistiken wirft, wird man sehen, dass nun auch der var-Cache endlich gefüllt wird.

Und nun kommen wir dann zur abschließenden Betrachtung des RAM-Verbrauchs: im Admin-Bereich zeigt sich, dass dieser nun auf rund 20 bis 22 MiB gesunken ist.

Fazit: Nach Plugin-Entschlackung und PHP-Caching eine Reduktion um den Faktor 3 bis 4!!!

Ich habe zwar kein Vorher-Nachher-Test mit ApacheBench durchgeführt, aber zumindest der Langzeit-Test im Nachhinhein ließ mich dann doch beruhigt schlafen:

ab -n 100000 -c 5 http://mannaz.cc/

Concurrency Level:      5
Time taken for tests:   6683.970 seconds
Complete requests:      100000
Failed requests:        3
   (Connect: 0, Receive: 0, Length: 3, Exceptions: 0)
Write errors:           0
Total transferred:      3989386433 bytes
HTML transferred:       3933317996 bytes
Requests per second:    14.96 [#/sec] (mean)
Time per request:       334.198 [ms] (mean)
Time per request:       66.840 [ms] (mean, across all concurrent requests)
Transfer rate:          582.87 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:   238  334  69.2    332    1502
Waiting:      238  334  69.2    332    1502
Total:        238  334  69.2    332    1502

Percentage of the requests served within a certain time (ms)
  50%    332
  66%    375
  75%    399
  80%    413
  90%    428
  95%    431
  98%    435
  99%    439
 100%   1502 (longest request)

Einige Schlussbemerkungen:

Wählt den XCache-Speicher nicht zu klein!

Wer einen eigenen dedizierten Server gemietet hat, sollte genügend Ressourcen verfügbar haben, den opcode- und den var-Cache entsprechend großzügig zu gestalten. Hierbei sollte man etwas testen; gute Ergebnisse erzielte ich erst dann, als der Cache soviel fasste, dass er nicht zu 100% ausgelastet wurde.

Dabei musste ich aber mehr als nur eine WordPress-Instanz in die Kalkulation einbeziehen. Der spannende Part bleibt dabei vorerst nur der opcache, der dann sozusagen den kompletten WordPress-Code UND die Plugins fassen können sollte, ohne zu ächzen.

Schaut euch einfach an, was ihr so grundsätzlich an freien RAM habt und spendiert dem Cache einfach eine gute Portion davon. Je mehr PHP-Anwendungen ihr auf dem Server laufen habt, desto mehr Code muss zwischengespeichert werden, das zieht RAM, klar, aber es macht sich am Ende in der Leistung und Geschwindigkeit bemerkbar! Bei einem Hetzner EQ4 mit 8 GiB RAM, der vielleicht sonst eh nur idled und kaum RAM verbrät, kann man den Cache also auch mal überdimensioniert riesig gestalten. Nach einigen Tagen einfach mal im XCacheAdmin nachschauen, wie viel letztlich wirklich verbraucht wird und dann ggf. nachjustieren, falls der RAM an anderen Ecken fehlt.

WordPress-Caching-Plugins: diese könnt ihr zusätzlich installieren. Beispielsweise, um statische HTML-Seiten generieren zu lassen, die den Server somit noch weniger belasten, auch gibt es einen MySQL-Query-Speicher, der die Abfragen-Anzahl minimieren sollte und damit ebenfalls den Server schont (siehe: http://wordpress.org/extend/plugins/db-cache-reloaded/; von mir noch nicht getestet).

Und immer mal von Zeit zu Zeit ein Auge auf den tatsächlichen Verbrauch werfen, nach Flaschenhälsen schauen, nachjustieren und ggf. andere Lösungen suchen. Für PHP-Caches gibt es nebst XCache auch noch den eAccelerator, APC (welcher bei PHP 6 dann in den Kern aufgenommen werden soll) und weitere Lösungen. Auch ist der Zend-Server sicher eine Option, mir gefiel sie aber nicht so sonderlich, wobei Apache-Nutzer sicherlich durch die transparente Einbindung profitieren, da für sie kein Mehraufwand in der Webserver-Konfiguration ansteht.

Wer nicht zu den glücklichen Server-Mietern oder -Besitzern gehört: Schaut doch einfach mal, ob euer Hoster dennoch eine PHP-Cache-Lösung anbietet, selbst testen könnt ihr das z. B. mit der phpinfo()-Ausgabe.

asaaki on blogcraft, 2010. | PHP, php-fpm und xcache (Permalink) | Ein Kommentar | Add to del.icio.us
Post tags: 10.04, 9.04, apache, APC, cache, CGI, eAccelerator, LTS, mod_php, nginx, object-cache.php, PHP, php-fpm, ram, server, ubuntu, wordpress, WP_CACHE, XCache, zend

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/

asaaki on blogcraft, 2010. | WordPress für Android (Permalink) | Ein Kommentar | Add to del.icio.us
Post tags: android, android.wordpress.org, app, Automattic Inc., Market, QR, QR-Code, wordpress, Wordpress for Android, wpToGo

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!

asaaki on blogcraft, 2010. | Nach Kommentartyp filtern und zählen (Permalink) | 3 Kommentare | Add to del.icio.us
Post tags: $comments, $comments_by_type, anzahl, Code, Codesnippet, comments.php, comments_number(), count_comment_type, filtern, functions.php, funktion, hack, kommentare, PHP, pingbacks, pings, template tags, theme, trackbacks, trennen, tweets, wordpress, wp_list_comments(), zählen

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 …

asaaki on blogcraft, 2009. | WordPress 2.8.6 Update (Permalink) | Keine Kommentare bisher | Add to del.icio.us
Post tags: 2.8, 2.8.5, 2.8.6, bugfix, fix, press this, release, security, sicherheit, update, upload, wordpress, XSS

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.

asaaki on blogcraft, 2009. | Abhärtung für den WordPress 2.8 Zweig (Permalink) | Keine Kommentare bisher | Add to del.icio.us
Post tags: 2.8, 2.8.5, 2.9, beta, hardening, release, wordpress

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.

asaaki on blogcraft, 2009. | Sicherheitsupdate für WordPress – 2.8.3 ist raus! (Permalink) | Ein Kommentar | Add to del.icio.us
Post tags: 2.8.2, 2.8.3, release, sicherheit, update, wordpress, wpnff

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]

asaaki on blogcraft, 2009. | WordPress 2.8.2 schnell hinterher (Permalink) | Keine Kommentare bisher | Add to del.icio.us
Post tags: 2.8, 2.8.1, 2.8.2, bugfix, sicherheit, update, wordpress, XSS

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.)

asaaki on blogcraft, 2009. | Nächste WPNFF Edition (2.8.1) (Permalink) | Keine Kommentare bisher | Add to del.icio.us
Post tags: 2.8, 2.8.1, wordpress, wpnff