Oh, wie schön! Nach der Aktualisierung meiner WordPress-Installation auf die neueste Version (3.1) steht nun im Frontend eine Admin-Bar zur Verfügung. Über die Leiste am oberen Bildschirmrand hat man direkten Zugriff auf die wesentlichsten Funktionen. Verlinkt sind diese mit dem Backend:
Dashboard, Profil
Artikel, Seiten
Kommentare
Widgets & Menüs
Aktualisierungen
Eine ähnliche Menüleiste gibt es bei Buddypress schon seit geraumer Zeit und auch dort fand ich die Funktioalität wirklich gut.
Weiterhin erstrahlt das Backend in einem etwas freundlicheren Farbton. Prima!
– 28. September 2010Eingestellt unter: IT, Kurioses
Etwas überrascht habe ich gerade den Artikel zur Einstellung des Microsoft-Dienstes Windows Live Spaces gelesen und musste mir erstmal die Augen reiben. Microsoft stellt seine Blogplattform, auf der Nutzer ihr Online-Tagebuch pflegen konnten, ein und empfiehlt die Migration zu WordPress.com.
Abgesehen davon, dass ich WordPress für Blogs nahezu alternativlos im Raum sehe, verwundert mich die Empfehlung von Microsoft doch.
Sei es drum – für die Migration existiert ein Tool, welches durch eine Anleitung (in Kooperation Microsoft – Automattic, WordPress-Entwickler und Plattformbetreiber WordPress.com entstanden) untersetzt den Umzug erträglich gestalten soll. Da ich Windows Live Spaces nicht getestet habe, erlaube ich mir kein Urteil über die Nutzbarkeit der Plattform wünsche aber trotzdem einer hoffentlich großen Userzahl viel Spaß mit ihrer neuen WordPress-Oberfläche in einer OS-geprägten Anwendung.
Auch wenn gerade im Kurztest unter www.windowslive.com/spaces eine Webseite zu sehen ist, die nicht auf die Einstellung dieses (dort angebotenen) Dienstes schließen lässt, gehe ich (begründet durch den Blick in den Kalender, der für heute nicht den 1.4. anzeigt) von der Korrektheit der durch Golem recherchierten Information aus. Dort ist auch ein Verweis auf spaces.live.com zu sehen (was nicht zu meiner Recherche gelinkt ist und folglich ein anderes Angebot darstellen könnte).
Nachdem ich mittlerweile von mehreren Seiten auf meine hübschen Bilder mit der eher mäßigen Usability der Galerie hingewiesen wurde und vom SEO-begeisterten A-Blogger Stefan M. zu nächtlicher Stunde nochmals eine auffordernde Mail erhielt, habe ich mich doch nochmal (mit freundlichem Hinweis aber letztlich eigener Kraft :P) auf die Fehlersuche bezüglich der Kombination von Nextgen und jQuery Lightbox begeben.
Die Lösung des Problems? Man nehme einfach ein funktionierendes Plugin. Beim letzten Versuch hatte ich leider wenig Glück mit der Auswahl, so dass ich jetzt und hier “WP jQuery Lightbox” empfehlen kann.
Neben der optisch etwas hübscheren Darstellung haben sich nun folgende wesentliche Verbesserungen ergeben:
Die Navigation befindet sich innerhalb des sichtbaren Bereichs.
Mausfaule Besucher können mittels der Pfeiltasten in den Galerien navigieren (wie ich finde eine großartige Funktion).
Beim Schließen eines Bildes springt der Browser nicht mehr zum Seitenanfang (wie ich fand das größte Manko).
Jetzt müsste ich eigentlich die Zugriffe in den Galerien monitoren um zu prüfen, ob der Gewinn an Usability sich tatsächlich in längeren Besuchszeiten auswirkt.
Ich schmöker gern und regelmäßig bei Perun im Blog – einerseits, weil man dort immer wieder gute Tipps zum Thema WordPress erhält und andererseits weil der Blog konsequent über künftige Neuerungen der Software informiert.
Heute war wieder ein “Feature” dabei, welches mir noch nicht unter die Finger gekommen ist und jetzt meine Laune erhellt.
Unter den Profileinstellungen lässt sich das Farbschema des Backends wechseln. Das klingt wenig spektakulär, gibt der Anwendung jedoch einen neuen, frischen und irgendwie viel freundlicheren Anstrich.
Ich möchte die (hoffentlich endliche) Performance-Story fortsetzen. Dass WordPress nicht die performanteste Lösung ist, dürfte hinreichend bekannt sein – die Ladezeiten waren jedoch deutlich explodiert, so dass es Handlungbedarf gab. Part I der Geschichte führte zwar zu Verbesserungen, brachte jedoch nicht das erwünschte Ergebnis.
Etwas ärgerlich war der Umstand, dass sich über die Arbeiten der letzten Zeit ein kleines Fehlerchen in der .htaccess eingeschlichen hat und somit das Caching-Plugin (WP-Supercache) nur noch extra Load verursacht hat. Tatsächlich wurde bei jedem Aufruf ein neuer Snapshot erstellt, dieser jedoch nicht ausgeliefert :-) Dieser Task wäre nun abgehakt und sollte einiges an Ressourcen freisetzen.
Darüber hinaus kommt nun eine weitere Möglichkeit des Cachings zum Einsatz: Scriptcaching. PHP wird bekanntermaßen zur Runtime compiliert, was unter dem Geschwindigkeitsgesichtspunkt ganz sicher nicht die optimale Lösung ist. Der Einsatz von eAccelerator scheint auf die ersten Blick und die ersten Performancetests eine gute Wahl, wobei ich mit der Kundgabe von Freudensprüngen lieber noch eine kurze “Testphase” abwarte.
Was passiert? Die compilierten PHP-Scripte werden gespeichert, so dass nicht bei jedem Aufruf die Notwendigkeit zum Compilen entsteht. Ich erwarte mir davon eine (hoffentlich deutliche) Reduktion der CPU-Load.
Ich wünsche meinen Lesern einen schönen 4. Advent!
– 9. Dezember 2009Eingestellt unter: Allgemein, IT
Meine letzten Abende bestanden zu größeren Teilen aus der Ursachenforschung für die mitunter doch erheblichen Performancepotenziale dieser Seite. Nachdem Google die Kenngröße nun sichtbar in die Webmaster Tools integriert hat und mein schlechtes Gewissen vorher schon grenzenlos war, musste ich mir doch etwas Zeit dafür gönnen.
Kurze Vorgeschichte: nach langer Zeit des Shared Hostings habe ich die Domain (nicht zuletzt der großartigen Möglichkeiten hinsichtlich der Konfiguration) auf einen VPS (Virtual Private Server) umgezogen. Getreu dem Motto “nur Mut” war dies schnell getan. Leider waren die Defizite doch erheblicher als ich vermutet hatte.
Nach einigen Sessions, in denen die Konfiguration noch einen deutlichen “Schliff” erhielt, war es für den Moment erträglich wenn auch nicht zufriedenstellend.
Die Stellschrauben sind begrenzt – angreifen kann man prinzipiell:
am Webserver selbst (Apache2) – apache2.conf, httpd.conf
am Datenbankserver (MySQL) – my.cnf
an der Skriptsprache (PHP) – php.ini
an der Anwendung (WordPress) – Caching, Plugins, …
Damit wären die wesentlichen Punkte behandelt. Sie fragen sich nach dem Effekt? Gefühlt schonmal deutlich – in Zahlen schwer messbar, da die Umgebungsparameter (Gesundheitszustand Hostsystem, Anzahl zeitgleicher Zugriffe,… ) einen nicht unwesentlichen Beitrag leisten.
Nun stellt sich die Herausforderung auf eine etwas andere Art und Weise: in Abhängigkeit von der Tageszeit ist die Performance mal ok und eben mal nicht. In Zahlen bedeutet das, dass Sie, werter Leser, zwischen 0,7 und durchaus auch mal 10 Sekunden warten müssen, bis die Inhalte auf dem Server zusammengesetzt sind – der Download ist (breitbandig) in einer wenig spürbaren Zeitspanne abgeschlossen – die Bandbreite sollte also nicht der Flaschenhals sein. Bis zwei, vielleicht auch drei Sekunden liegt man damit ansich im WordPress-Schnitt – zumindest bei etwas besser besuchten Seiten. Mehr erscheint mir allerdings ungünstig, fühlt sich der geneigte Surfer doch schon nach wenigen Sekunden genötigt, nochmal zu klicken oder die Seite zu verlassen.
Und nun? Ich werde die Szenarie noch etwas beobachten – wenn alles nix hilft, muss eben doch eigene Hardware her. Sofern Sie diese Zeilen gerade lesen und Interesse an “Hardware-Sharing” haben, können Sie gern per Mail mit mir in Kontakt treten :-)
Das ganze hat gefühlt etwas von “Simons Cat” – frustrierend und erheiternd zugleich – in diesem Sinne also einen schönen Abend!
