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/

BlogcrafterChris on blogcraft, 2010. | Apple iPad (Tablet) vorgestellt (Permalink) | Keine Kommentare bisher | Add to del.icio.us
Post tags: android, apple, ipad, iphone, mannaz

Statscraft

BlogcrafterChris on blogcraft, 2010. | Kurzmeldung: Statscraft.de (Permalink) | Keine Kommentare bisher | Add to del.icio.us
Post tags: plugin, statistik, statpress, statpress seolution, statscraft, wp statscraft

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.

Obwohl zwischenzeitlich durch einige DNS-Umstellungen trotzdem eine Nichterreichbarkeit vorhanden war, leider. Denn man weiß nie so genau, wann die Anbieter da so ihre Aktualisierungen durchlaufen lassen. Und da man eine Domain in aller Regel nur über eine IP gleichzeitig erreichen kann^[01], war mir das Testen etwas erschwert. Und Wordpress mit Alternativ-URLs … na lassen wir das, das wird zu technisch.

Was beim Umzug die Sache erleichtert, ist der Vorteil eines “von außen” erreichbaren Datenbankservers, womit man nämlich mehr Zwischenschritte tätigen kann. Vorteil? Ja, denn das minimiert die Fehlersuche unheimlich, wenn es kleinere Portionen sind, die von A nach B transferiert werden. Und man kann anders vorgehen.

Mein gestriger Spontanumzug lief so:

1. Dateien von alten auf neuen Webspace kopieren — der einfachste Schritt
2. Auf dem Server (=neuer Webspace) dem Apache mitteilen, dass er eine neue Domain behandeln soll. (vhost anlegen, Apache reloaden)
3. Domain umkonnektieren auf den neuen Server
4. warten …
5. Hoffen, dass alles gut gegangen ist — was natürlich erfahrungsgemäß nie der Fall ist
   • Die .htaccess anpassen, da dort eine Anweisung drin war, die einen 500er verursachte (Notiz an mich selbst: der Server hat von vornherein mehr RAM für die PHP-Umgebung als der billige Webspace)
6. Blog testen, ob alles läuft. Merke: die Datenbank befindet sich noch auf der alten Umgebung (natürlich musste ich aber das “localhost” zu “blabla.dbserver.tld” umschreiben, da wir ja nicht mehr auf dem selben Server liegen)
7. Check, alles läuft rund. Nun kann die DB umziehen, denn Dateien und Grundkonfiguration machen keine Probleme mehr.
8. Datenbankumzug:
   1. DB auf altem Server sichern. Statt phpmyadmin eine Software nutzen, damit PHP-Laufzeitumgebung und der dahinter stehende Server einem bei großen Datenmengen keinen Strich durch die Rechnung machen! Ich empfehle hier die GUI Tools von MySQL (der MySQL Administrator und der MySQL Query Browser sind sehr gut und für Windows wie auch Linux erhältlich, kostenlos – siehe hier, bzw. Ubunties schauen mal im Repository nach)
   2. DB-Sicherung auf neuen Server einspielen — ich habe mich auch hier für die Variante per GUI Tools entschieden, dauert aber lange! Besser ist es wohl, das DB-Dump auf den Server zu laden und dort per Konsole (ssh) direkt einzuspielen, da diese nativen Werkzeuge dann doch schneller arbeiten. Aber ich hatte ja die Nacht Zeit und mir reichte der DB-Switch auch heute morgen.
   3. Wenn DB auf dem neuen Server ist, dann die wp-config.php anpassen und testen. Läuft wie n V8 — superb!
   4. Ggf. DB umbenennen und vllt. einen DB-User einrichten, der weniger Rechte hat als ein ALL PRIVILEGES-Nutzer, und dann auch nur auf der eigenen DB — Sicherheit geht vor!
9. Freuen wie ein Honigkuchenpferd, dass alles geklappt hat und keine schwerwiegenden Probleme auftraten. Okay, Erfahrung macht hier viel aus, da man so schneller an gewisse Fallstricke denkt und diese vermeidet.

Wie oben erwähnt, war der Umzug eigentlich nicht geplant, bot sich aber an, da ich nach und nach alle Seiten auf dem neuen, schnelleren und individualisierbaren Server umziehen will, sofern möglich. Webspace im Shared Hosting ist halt nie so schnell und gut, und haste mal n Kunden dabei, der eine CPU- oder RAM-intensive Site fährt, dann leiden alle auf dem Server.

Ebenfalls erwähnenswert: Wordpress ist mittlerweile so idiotensicher geworden, dass man auch nicht mehr auf server-lokale Pfade achten muss, denn wo Wordpress liegt, findet es meist selbst heraus, und eventuelle Pfade in der DB kommen so selten vor, dass es auch im Nachhinein kaum Probleme gibt (höchstens schlecht geschriebene Plugins). Wichtig: beim Umzug nicht auch noch etwas an der allgemeinen Ordner- oder Permalinkstruktur ändern! Gerade letztere ist eh ein Thema für sich, wo ich auch so meine Erfahrungen machen durfte.

Neben dem Umzug habe ich aber auch etwas optisch aufgehübscht. Angeregt durch einige Designs im Netz, die mich daran erinnert haben, dass ich ein Freund des Minimalismus bin, hab ich besonders den Header aufgeräumt und den Hintergrund weiß gestrichen. Da auch hier mehr der Inhalt als das Layout im Vordergrund steht, musste das Design natürlich weniger ablenkend umgestaltet werden. Ich sollte mir definitiv eine persönliche Theme-Spielwiese einrichten …

Das war es dann auch schon.

Wer Fragen zum Wordpress-Umzug hat oder ein bisschen Hilfestellung benötigt, kann mir hier gern einen Kommentar hinterlassen. Wenn die Frage auf einen Aspelt hinausläuft, der für viele interessant sein kann, dann widme ich dieser auch einen eigenen Beitrag.

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 …

Aber eigentlich wollte ich ja ganz woanders hin. Denn durch eine Welle im Sandkasten Google Wave — zu dem ich seit heut morgen Zugang habe — wurde ich auf etwas aufmerksam gemacht, das mir als biologischer Mann, wohl Natur gegeben, entgehen musste. Es gibt doch tatsächlich einen Frauenbrowser! Ja wohl, geneigter Blogleser, richtig gelesen: ein Browser für Frauen.

Natürlich wurde in der Wave auch ein Link mitgegeben, zu einem Artikel, auf der auch die URL geschrieben (aber nicht verlinkt!) wurde; so wollte ich mir doch gleich die Seite anschauen, die das geschlechtsspezifische Produkt anpreisen sollte .. und siehe da, es gibt wohl auch schon eine Geschlechtserkennung auf den Webservern:

Hm, also nicht einfach nur für Frauen, sondern definitiv nicht auch für Männer? Oder was hat das zu bedeuten?

Nunja, der Link konnte auch etwas falsch sein, also surfte ich die Startseite an und suchte nach “IE8″ (spart Buchstaben, obwohl “Frauenbrowser” sicher das Suchwort der Wahl sein muss). Schnell fand ich die richtige Zielseite und las und staunte und las die Kommentare und staunte noch mehr.

Nicht nur, dass Frauen offensichtlich von sich aus gar keinen “eigenen” Browser wollen oder wünschen, sondern gar regelrecht dagegen wettern oder parodistisch auch die Männervariante herbei imaginieren. Angeblich bevorzugen Frauen nebenbei auch lieber den Mac, statt den PC — was verwundert, denn der Artikel selbst liest sich doch mehr wie ein bezahlter Beitrag von Microsoft, die ja nun kaum merklich überall auch Werbung für Windows 7 machen.

Auch werden Web Slices als der letzte heiße Scheiß angepriesen. Natürlich kenne ich dieses Feature nicht, denn ich nutze schon seit Jahren alles andere als den Internet Explorer. Ja eher noch teste ich sämtliche anderen Browser wie Google Chrome (oder die etwas kommunikationssparsamere Variante Iron), Firefox, Safari oder Opera. Und die meisten lassen sich mehr oder minder ebenfalls so weit individualisieren, dass sowohl Frau als auch Mann als auch jegliches andere Geschlecht damit warm wird und arbeiten kann. Und das alles ohne ein festgelegtes Label.

Achja, ich habe den Internet Explorer dennoch drauf, weil ich ja immer mal das eine oder andere Layout dennoch auch auf diesem Browser teste. Ob ich mir jetzt aber den Frauenbrowser auch noch installieren muss, weil der ja vielleicht das Internet auch anders anzeigt als alle anderen … ich weiß nicht, ab einem gewissen Punkt wird auch mir alles mal zu viel.

Abschließender Hinweis (kein Disclaimer und auch kein Disclosure): Wie unschwer aus dem Artikel hervorgeht, ist der Autor ein bekennender Nichtfreund des Internet Explorers. Er will damit keineswegs die Arbeit des Hauses Microsoft grundsätzlich schmälern, ihren wirtschaftlichen Erfolg sowieso nicht (es ist nur der Neid, nicht selbst seit Anbeginn Aktionär gewesen zu sein). Jede/r möge sich selbt ein Bild machen und urteilen, was für ihn oder sie das richtige Instrument im Internet ist. Der Autor wollte nur feststellen, dass man es mit so mancher Entwicklung aber auch übertreiben kann und damit weit über das Ziel des Zumutbaren hinausschießen kann. Zum schweizer Onlinemagazin annabelle.ch kann der Autor gar kein Urteil geben, daher bleibt das Verhalten der Redaktion hier weitesgehend unreflektiert.

Hier kann sich jeder Interessierte selbst das Glanzstück anschauen: annabelle.ch Frauenbrowser — ja, ich weiß, dass ich damit die Seite pushe, aber soviel Spaß muss auch beim Google Ranking gewürdigt werden. ;o)

LOL-SEO / SEO-LOL – Spaß mit Suchmaschinenoptimierung!

1. SEO ist nicht schwer …
2. Mit nummerierten Texten ist SEO sogar leicht …
3. Und mit Farbe wird SEO super easy!
4. Die eigene Seite ist die beste Referenz der eigenen SEO-Tätigkeit.
5. Okay, lange Rede, gar kein Sinn — lest und -besser noch- schaut, worum es geht.
6. Zu Punkt 4 in Bezug auf Punkt 5 siehe diese Seite, mit der sich ganz schnell und leicht Geld im Internet verdienen lässt.

Ein Kurzartikel der fiktiven Kategorie “Spaß mit SEO!”

BlogcrafterChris on blogcraft, 2009. | LOL-SEO (Permalink) | 3 Kommentare | Add to del.icio.us
Post tags: LOL-SEO, SEO, SEO-LOL, SEO-Volk, Volks-SEO, VolksSEO

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.