I already wrote about the Opera Browser switching to the WebKit engine a while back in February, but at the beginning of April the story had become even more interesting: Opera is not simply going to switch to WebKit, but will work together with Google on a fork of the open source WebKit code, which is going to be called Blink. This makes a lot of sense and while Chrome and Opera will always remain completely seperate entities, they will be powered under the hood by the same engine adhering to the same standards.
Actually only a part of Webkit called WebCore will be forked to Blink, that actually excludes a Javascript engine, which Google has developed seperately as the open source project V8. This is the engine Opera will also use, and presumably contribute to, in the future. I like Opera because of its unique user interface and features no other browser has, but I must admit that I have been using Google Chrome at the same time especially for Google+ and Facebook, because on my old, but trusty notebook Opera doesn’t render these pages as fast and fluid as Chrome. So an Opera browser with Webkit and V8 inside is going to be very handy for myself, but it’s also going to make the work of web designers much, much easier. It can also be safely assumed that the look and feel of Opera is not going to change much even after the engines have been switched. Only one thing worries me… what is going to become of Dragonfly, the powerful developer tool of Opera? Since this is geared towards the old Presto engine, it might become obsolete.
There have been no Opera desktop versions with Webkit yet, but the Norwegian browser manufacturer has already released three beta versions of Opera for Android with Webkit implementation. These have become amazingly good and are even on low-powered tablets as fast as the old Opera Mobile, but there is still a bit of work to do on the new user interface. There is no bookmark management, only a barely functioning speed dial and progress indicators are still missing – but the rendering speed and low memory usage are so good that I’ve almost completely switched to the new Opera version on my tablet.
So Opera is going to have a very bright future with Blink on the Desktop and presumably also on Android devices. Now I’m anxiously waiting for the first Beta of Opera 14 – they’re going to skip version 13 not because of superstition, but simply to mark the big internal change. Opera has wisely refrained from giving a specific release date – but I’m sure it is going to happen sometime this summer!
Ich muß zugeben, daß ich als langjähriger Benutzer des Opera-Browsers zuerst ein bißchen von der Nachricht geschockt war, daß die norwegische Browserschmiede ihre eigene Rendering- und Javascript-Engines aufgeben und komplett auf Webkit umstellen will. Die erste Aus-dem-Bauch-Reaktion ist natürlich, daß Opera sich dadurch nicht mehr von der Konkurrenz unterscheiden wird, aber bei genauerer Betrachtung macht dieser radikale Schritt doch viel Sinn. Ein Webbrowser besteht ja nicht nur aus der Rendering-Engine – der Grund, weshalb ich Opera so gerne mag, ist die Benutzeroberfläche, an der sich durch den Austausch der Innereien nichts ändern wird. All die kleinen Annehmlichkeiten, die die anderen Browser nicht zu bieten haben, werden dadurch nicht verschwinden und Opera wird seine Individualität behalten.
Aus der Sicht des Webdesigners bin ich sogar erleichtert, daß ich für Opera in Zukunft keine Extrawurst mehr braten muß. Ich teste meine Webseiten zwar immer zuerst unter Opera und oft treten bei der Darstellung zwischen den verschiedenen Browsern dann auch kaum Unterschiede auf – aber meistens ist es dann beim Feintuning von Abständen via CSS meistens Opera, bei dem gelegentlich seltsame kleinere Diskrepanzen auftreten. Auf der anderen Seite ist mir aber Webkit auch nicht so fremd, als daß ich damit ein größeres Problem hätte – ganz im Gegenteil funktioniert jede meiner eigenen Webseiten und externen Projekte ganz hervorragend mit der Webkit-Engine.
Was ist aber mit der eigentlichen Geschwindigkeit von Webkit? Wie viele Leser wahrscheinlich wissen, arbeite ich ausschließlich auf sehr alten Computern – mein Arbeits-Notebook ist ein mittlerweile fast zehn Jahre alter Compaq N610c, der aber trotzdem für meine Zwecke völlig ausreicht. Opera hat sich gerade auch früher auf noch erheblich älteren Rechnern immer als der schnellste und ressourcenschonendere Browser von allen herausgestellt, aber ich muß zugeben, daß ich inzwischen für Google+ immer öfter auf Chrome ausgewichen bin, weil die Web-Oberfläche des sozialen Netzwerks damit einfach viel flüssiger läuft. Auch bei bei WordPress merkt man den Unterschied und gerade unter diesem Gesichtspunkt fände ich einen Opera mit Webkit-Engine keine schlechte Idee.
Die erste Opera-Variante, die mit der Webkit-Engine ausgestattet werden soll, wird ersten Berichten zufolge die Mobile-Version sein. Ob ich das gut finde, weiß ich noch nicht, denn auf meinem kleinen Android-Tablet hat sich Opera mit der eigenen Engine als schnellster Browser erwiesen und die Webkit-Browser eher als schwerfälliger. Vielleicht gelingt es Opera aber, einen richtig schnellen Webkit-Browser unter Android zu ermöglichen. Aber genauso wie bei der Desktop-Version wird man ja nicht unbedingt zu einem Upgrade gezwungen, denn zumindest unter Windows sind ja auch parallele Installationen von verschiedenen Opera-Versionen möglich.
Fazit: der Einsatz von Webkit wird bestimmt nicht das Ende von Opera bedeuten, ganz im Gegenteil – es ist eine große Chance für die Zukunft und deshalb werde ich dem Browser auch in Zukunft weiterhin treu bleiben.
Es ist mal wieder ein halbes Jahr rum und mit WordPress 3.5 ist vorige Tage das nächste große Update erschienen. Die Änderungen halten sich äußerlich wieder in Grenzen, geschraubt wurde vor allem in den Innereien – aber das ist ja kein Grund nicht zu updaten. Wie jedesmal habe ich wieder meine alten Tips zur Editor-Optimierung ausprobiert und wieder festgestellt, daß alles immer noch genauso funktioniert:
HTML-Editor: Der HTML-Quellcode-Editor verwendet schon seit Version 3.2 Consolas als Zeichensatz, aber die Zeilenhöhe ist immer noch zu groß. Die entsprechende CSS-Definition ist seit Version 3.3 in der Datei wp-includes/css/editor.css vorhanden: man kann unter textarea.wp-editor-area die Zeile line-height: 120%; hinzufügen oder auf einen anderen gewünschten Wert ändern.
Visual Editor: funktioniert genauso wie bei den vorherigen Versionen. Der Anzeige-Font des Visual Editors läßt sich immer noch nur über die CSS-Datei wp-includes\js\tinymce\themes\advanced\skins\wp_theme\content.css verändern. Dort genügt es, die Zeichensatzdefinition im Body-Tag von font: 13px/19px Georgia […] auf einen gewünschten Font wie Verdana zu ändern.
Get Shortlink: hat sich gegenüber V3.3 auch nicht geändert. Um die Beschriftung dieses zu großen Buttons, der auf kleinen Displays manchmal in die nächste Zeile umbricht, zu ändern, muß man in der Datei /wp-admin/edit-form-advanced.php nach dem Text “Get Shortlink” suchen (ist nur einmal vorhanden) und ihn auf eine kürzeren Text ändern. Deaktivieren läßt sich der Buttons übrigens auch, indem man im Jetpack-Plugin das Modul WP.ME-Shortlinks ausschaltet – aber das nützt nichts, wenn man die Shortlinks trotzdem braucht und der Button doch zu groß ist.
Und was wie üblich gesagt werden muß: ich übernehme keinerlei Garantie für diese “Hacks”, man sollte also schon wissen, was man tut, wenn man in den Innereien von WordPress herumbastelt.
WordPress 3.4 ist gestern erschienen, und die ganzen Upgrades waren doch nicht so Zeitintensiv wie ich gedacht hatte. Version 3.4 ist kein riesiges Update, denn soviel hat sich auf den ersten Blick gar nicht getan – gebaut wurde hauptsächlich unter der Oberfläche. Die Tips zur Editor-Optimierung, die ich seit jeder neuen Version wieder neu einbauen muß (und die natürlich immer noch nicht implementiert wurden), funktionieren auch mit der neuen Ausgabe, allerdings hat sich bei der ersten Bastelei etwas verändert.
HTML-Editor: Der HTML-Quellcode-Editor verwendet vernünftigerweise schon seit Version 3.2 Consolas als Zeichensatz, aber die Zeilenhöhe ist immer noch zu groß. Die entsprechende CSS-Definition ist jetzt in einer anderen Datei zu finden als in Version 3.3: in wp-includes/css/editor.css kann man jetzt unter textarea.wp-editor-area die Zeile line-height: 120%; hinzufügen oder auf den entsprechenden Wert ändern (bei meiner Installation war die Zeile schon da und stand auf 150%.)
Visual Editor: funktioniert genauso wie bei Version 3.3. Der Anzeige-Font des Visual Editors läßt sich immer noch nur über die CSS-Datei wp-includes\js\tinymce\themes\advanced\skins\wp_theme\content.css verändern. Hier genügt es aber jetzt, die Zeichensatzdefinition im Body-Tag von font: 13px/19px Georgia […] auf einen gewünschten Font wie Verdana zu ändern.
Get Shortlink: hat sich gegenüber V3.3 auch nicht geändert. Um die Beschriftung dieses oft zu großen Buttons zu ändern, muß man in der Datei /wp-admin/edit-form-advanced.php nach dem Text “Get Shortlink” suchen (ist nur einmal vorhanden) und ihn auf eine kürzeren Text ändern. Deaktivieren läßt sich der Buttons übrigens auch, indem man im Jetpack-Plugin das Modul WP.ME-Shortlinks ausschaltet – aber das nützt nichts, wenn man die Shortlinks trotzdem braucht und der Button doch zu groß ist.
Und was gesagt werden muß: ich übernehme keinerlei Garantie für diese “Hacks”, man sollte also schon wissen, was man tut, wenn man in den Innereien von WordPress herumbastelt.
Schon wieder über einen Monat Funkstille, aber diesmal habe ich einen besonderen Grund gehabt: das neue Template ist fertig und ich wollte vorher nichts neues mehr posten. Fast genau vier Jahre, nachdem ich Bibra-Online auf WordPress umgestellt hatte, gibt es jetzt ein Design-Facelifting: Version 3.0 der Webseite ist weniger eine komplette Umgestaltung als ein völliger technischer Neuaufbau des Templates, das ich nun komplett von Grund auf selbst geschrieben habe und dabei viele Probleme und Ungenauigkeiten beseitigen konnte. Wie ich schon im letzten Posting erwähnt hatte, gab es bei der Umsetzung vom HTML-Gerüst ins WordPress-Template ein paar Rätsel zu lösen, aber nachdem ich die letzten Nüsse geknackt hatte, ging es relativ schnell und streßfrei.
Der größte Unterschied befindet sich unter der Haube, denn das Template verwendet CSS3-Technik und benutzt für Zeichensätze, runde Ecken und Farbverläufe keine Grafiken mehr, sondern nur noch reinen CSS-Code. Dadurch ist vieles viel einfacher geworden und Sachen, für die vorher eine eigene Grafik notwendig gemacht haben, können jetzt durch eine kleine handvoll CSS-Befehle erzeugt werden. Sogar das Logo rechts oben ist keine Bitmap mehr, sondern nur ein CSS-Rahmen mit Farbverlauf und ein großer Buchstabe mit eingebundenem Font. Einen Nachteil hat das ganze allerdings: während die neuesten Versionen vom Firefox, Opera, Chrome und Safari problemlos damit zurechtkommen, klappt es mit keiner Version des Internet Explorers mehr, auch nicht 8 und 9. Deswegen gilt ab jetzt das, was ich schon vor einiger Zeit angekündigt hatte: diese Seite funktioniert nicht mehr mit dem Internet Explorer! Es ist im Moment noch keine Browserweiche eingebaut, aber in Zukunft werde ich wohl eine Warnung für Besucher anzeigen, die mit dem Microsoft-Browser unterwegs sind.
Die Änderungen an der Oberfläche halten sich in Grenzen, aber ich habe einige völlig redundante Elemente wie den ganzen Blog-Header rausgeworfen, das Logo ins Hauptmenü gesetzt und einige Links aus dem Header in die Sidebar gepackt. Statt Grafiken wird nun ein per @font-face eingebundener Zeichensatz für die Logos und Buttonns verwendet, für den ich leider den früheren Font, HandelGothic, nicht benutzen konnte, da ich keine Webfont-Lizenz für ihn besitze – stattdessen habe ich nach langer Suche bei Fontsquirrel Sansation gefunden, den ich schon für das Logo von Bibra-Medien benutzt hatte und der mir hier noch besser gefällt. Außerdem habe ich das Kommentar-Formular komplett neu gestaltet und viele kleinere Änderungen im Design gemacht, um die ganze Webseite ein klein bißchen professioneller aussehen zu lassen. Ganz konnte ich mich aber nicht von dem alten Design trennen, aber vielleicht kommt das mit Version 4.0 in ein paar Jahren.
Das Facelifting betrifft im Moment nur das Blog selbst – wenn man auf die anderen alten Seiten klickt, erscheint noch der frühere Header. Ich habe noch keine Lust gehabt, das zu ändern, weil sich der neue Header nicht ganz so einfach in das alte Frame-Layout einbauen läßt und ich dafür die alten Seiten nochmal überarbeiten müßte. Das kommt dann in Phase 2, die ich auf jeden Fall im Laufe des Jahres angehen werde: die Seiten Bücher, Musik, Computer, Spiele und Sim werden dann ins WordPress-System integriert und auf deren jeweiligen Einstiegsseiten werden Postings aus der passenden Kategorie von der Hauptseite angezeigt. Dazu muß ich mir aber noch etwas zur Gestaltung einfallen lassen, denn die derzeitigen Seiten sind so alt, daß man sie im Prinzip nur noch wegwerfen kann. Und das werde ich nach und nach demnächst auch tun und mal etwas ganz anderes zu den Themen versuchen.
Das neue Template für Bibra-Online ist erstmal ein kleiner Renovierungs-Schritt, der hauptsächlich dazu da ist, mich zu motivieren, hier in Zukunft wieder mehr zu schreiben. Ich werde zwar nicht wieder damit anfangen, dauernd die Artikel vom DVDLog und vom Foto-Archiv zu doppeln, aber mit dem neuen Design habe ich auch wieder Lust, mehr zu anderen Themen zu schreiben. Jetzt muß ich aber erstmal noch eine kleine Pause einlegen, aber danach gehts mit irgendetwas weiter :-).
Vor einiger Zeit hatte ich schon einmal den Internet Explorer von meinen Webseiten verbannt, damals anläßlich der Ankündigung, daß der IE9 nicht mehr unter Windows XP laufen wird. Inzwischen habe zwar Zugriff auf ein Win7-System und den IE9, aber das ändert nichts daran, daß der Internet Explorer in Zukunft hier nicht mehr funktionieren wird. Während der ersten Tests für das dieses Jahr anstehende kleine Facelifting von Bibra-Online habe ich festgestellt, daß das neue Design zwar auf allen aktuellen Browsern vom Firefox, Opera, bis zu Chrome und Safari und sogar auf dem iPad funktioniert, aber nicht auf dem IE9.
Die simple Konsequenz daraus ist, daß Bibra-Online nach dem Redesign entgültig nicht mehr Kompatibel zum Internet Explorer sein wird, es sei denn Microsoft unternimmt in Zukunft irgendwann mal etwas in Sachen CSS3-Unterstützung. Ich möchte nicht mehr auf die designtechnischen Vorteile von CSS3 verzichten, die so vieles einfacher machen und eine Gestaltung ermöglichen, die früher nur mit vielen Tricks und massivem Einsatz von Grafiken möglich war. Zusammen mit dem Redesign werde ich dann eine Browserweiche einbauen und wer die Seite dann mit dem Internet Explorer aufruft, wird vorher hinreichend gewarnt werden.
Wann das Redesign, oder besser gesagt, das Facelifting von Bibra-Online kommen wird, weiß ich jetzt noch nicht genau. Ich habe gerade erst mit einem reinen HTML-Test angefangen und bis das ganze auch als WordPress-Template umgesetzt ist und die anderen notwendigen Änderungen gemacht sind, werden sicher noch ein paar Monate vergehen, aber vielleicht werde ich das Blog-Template zuerst fertigstellen.
Das Redesign betrifft übrigens erstmal nur Bibra-Online, DVDLog und das Foto-Archiv sind davon (noch) nicht betroffen.
Es ist mal wieder soweit, WordPress 3.3 ist fertig und damit ist wie immer auch eine Update-Orgie verbunden, die ich zum Glück jetzt schon hinter mir habe. Die neue Version hat gegenüber der vorherigen Ausgabe einige interessante Neuerungen mit sich gebracht – insbesonders ist der Admin-Bereich noch schlanker geworden und macht auch auf kleineren Auflösungen jetzt keine Probleme mehr. Meine Tips zur Editor-Optimierung, die ich im September 2010 das letzte Mal gepostet hatte, funktionieren wegen dem stark veränderten CSS-Code leider nicht mehr so wie damals angegeben, aber ich habe mir das mal angeschaut und die wichtigsten beiden Änderungen wiedergefunden:
HTML-Editor: Der HTML-Quellcode-Editor verwendet vernünftigerweise schon seit Version 3.2 Consolas als Zeichensatz, aber die Zeilenhöhe ist immer noch zu groß. Die entsprechende CSS-Definition in der Datei wp-admin/css/wp-admin.css heißt jetzt textarea.wp-editor-area, zu der man die Definition line-height: 120%; hinzufügen sollte.
Visual Editor: Der Anzeige-Font des Visual Editors läßt sich immer noch nur über die CSS-Datei wp-includes\js\tinymce\themes\advanced\skins\wp_theme\content.css verändern. Hier genügt es aber jetzt, die Zeichensatzdefinition ganz am Anfang im Body-Tag von font: 13px/19px Georgia […] auf einen gewünschten Font wie Verdana zu ändern.
Get Shortlink: Um die Beschriftung dieses oft zu großen Buttons zu ändern, muß man in der Datei /wp-admin/edit-form-advanced.php nach dem Text “Get Shortlink” suchen und ihn auf eine kürzeren Text ändern. Deaktivieren läßt sich der Buttons übrigens auch, indem man im Jetpack-Plugin das Modul WP.ME-Shortlinks ausschaltet – aber das nützt nichts, wenn man die Shortlinks trotzdem braucht und der Button trotzdem zu groß ist.
Wie immer übernehme ich keine Garantie für diese “Hacks”, man sollte also schon wissen, was man tut, wenn man in den Innereien von WordPress herumbastelt.
Ich bin ja jetzt schon einige Jahre mit meinem Webseiten im Internet präsent, aber das ist mir noch nie passiert: am 23. und 24. August ist ein Teil meiner Webseiten gehackt worden. Genauer gesagt hatte sich jemand mit einer rumänischen IP-Adresse Zugang zu den FTP-Servern von Bibra-Online.de und DVDLog.de verschafft und dort fremden Code in zahlreiche Dateien eingeschleust. Was genau dieser Code letztendlich verursacht, ist mir noch unbekannt, aber aufgefallen ist mir der Angriff zuerst, weil meine Webseiten anfingen von fremden Domains irgendetwas nachzuladen.
Ich kann aber Entwarnung geben: in einer Mords-Aktion habe ich noch gestern Abend sämtliche manipulierten Dateien durch saubere Backups ersetzt. Ich kann bei den tausenden von Dateien nicht ausschließen, daß ich dabei etwas vergessen habe, aber alles im Hauptverzeichnis von Bibra-Online inklusive den DVD-Kritiken sowie die WordPress-Installationen sind jetzt wieder sauber. Der Angriff scheint nicht von WordPress ausgegangen zu sein und es wurden sowohl reine HTML-Dateien als auch PHP-Skripte manipuliert.
Wer aber vom Abend des 23. bis zum Abend des 25. August auf Bibra-Online oder DVDLog zugegriffen hat und dem dabei etwas merkwürdiges aufgefallen ist – bitte unbedingt bei mir melden! Ich hoffe, daß ich mit meinen Webseiten durch diesen Zwischenfall keine Viren oder ähnliches verbreitet habe, aber ganz ausschließen kann ich das im Moment noch nicht. Allerdings habe ich in dieser Zeit auch auf die Webseiten zugegriffen und mein Virenscanner hat nicht angeschlagen, so daß da hoffentlich nicht drastisches passiert ist.
Im Moment bin ich noch dabei, die Scherben aufzufegen und mehr über den Angriff herauszufinden – sollte es Neuigkeiten dazu geben, werde ich mich an dieser Stelle natürlich wieder melden.
[Update vom 27.8.: Wie der Angriff zustande gekommen ist, bleibt nach wie vor völlig unklar. Mein Provider meint natürlich, daß es nur an ausgespähten Passwörtern gelegen haben kann, was ich aber auf meiner Seite wiederum hundertprozentig ausschließen kann. Was genau die manipulierten Webseiten angestellt haben, weiß ich auch noch nicht genau, da ich noch nicht dazu gekommen bin, mir die gesicherten Dateien unter kontrollierten Bedingungen anzuschauen. Auf den Webservern befinden sich aber definitiv keine infizierten Dateien mehr und es hat auch keine neuen Angriffe mehr gegeben.]
Vor fast genau einem Jahr hatte ich den Internet Explorer in die Mülltonne getreten und aus aktuellem Anlaß möchte ich das heute noch einmal bekräftigen. Es ist nicht nur, weil Microsoft aus nicht wirklich nachvollziehbaren Gründen die neunte Version seines Browser nur für Windows Vista und 7 anbietet, sondern auch, weil sich in Sachen Kompatiblität immer noch nicht viel getan hat. Als Webdesigner bekommt man da schnell Kopfschmerzen, besonders weil das hochgelobte Hardware-Zeichensatzrendering nun noch zu zusätzlichen Textformatierungs-Problemen führt – ich werde nach wie vor den Internet Explorer in allen Versionen auf meinen Webseiten nicht berücksichtigen.
Aber wer ist nun der neue Browser-König? Mit der Veröffentlichung des IE9 und Firefox 4 ist ansonsten nur noch Googles Chrome in den Medien vertreten, aber der nach meiner Meinung beste Browser von allen wird natürlich kaum erwähnt: Opera, der nach einer etwas wackeligen Version 10 inzwischen als hervorragende elfte Version zu haben ist und in Sachen Benutzerführung und vor allen Dingen Anpaßbarkeit nicht zu schlagen ist. Ich habe nichts gegen Firefox, der in der vierten Version nun noch wendiger und schneller geworden ist, aber persönlich mag ich einfach vom “Browsergefühl” Opera am liebsten. Chrome ist mir ehrlich gesagt nicht ganz geheuer, denn bei Google bin ich mir nicht ganz so sicher, wo der Datenkrake überall seine Finger drin hat, aber als Webdesigner kann ich alle Benutzer nur inständig anflehen, alles zu benutzen – nur bitte den verdammten Internet Explorer nicht… okay?
Bei Webdesign-Aufträgen werde ich natürlich auf Wunsch auch auf eine IE-Kompatiblität achten, aber bei schwierigen Designs werde ich dann wegen der zusätzlichen Arbeit einen Aufschlag verlangen. Hier auf meinen Webseiten werde ich demnächst mal ein Plugin installieren, daß bei IE-Besuchern eine hübsche Warnung ausgibt…:-).
Wer auf seinen eigenen WordPress-Installationen das Statistik-Plugin von WordPress.com benutzt, wird seit letzter Woche bemerkt haben, daß einiges durcheinander gekommen ist. Ich war nicht der einzige, bei dem im Dashboard nur noch eine Fehlermeldung angezeigt wurde, daß der WordPress.com-User keine Erlaubnis zum Anschauen der Statistik besitzt. Bei mehreren Blogs, die den gleichen WordPress.com-Account für die Statistiken benutzen, ging außerdem anscheinend die Verknüpfung verloren, so daß die Statistiken erst gar nicht mehr im globalen Dashboard von WordPress.com angezeigt wurden.
Der Grund für diese Probleme ist bis jetzt noch unbekannt und offenbar hat sich von WordPress noch niemand dazu geäußert, aber es gibt zum Glück eine einfache Lösung: das Statistik-Plugin deaktivieren und stattdessen Jetpack installieren. In dieser Sammlung von verschiedenen Tools, die von WordPress.com angeboten werden, sind auch die Statistiken enthalten und wenn man Jetpack mit dem gleichen WordPress.com-Account verknüpft, mit dem man auch das alte Plugin betrieben hat, sind alle alten Statistiken noch da. Zum Anschauen der Statistiken braucht man jetzt nicht mehr zwingend einen eigenen, für die Statistiken authorisierten WordPress.com-Account, sondern muß nur registrierter Benutzer auf dem jeweiligen Blog sein. Die anderen Funktionen von Jetpack kann man deaktivierten, unter anderem auch den von mir so ungeliebten Get Shortlink-Knopf im Editor, aber andere Sachen wie die Integration von Youtube & Co. sind vielleicht doch ganz nützlich.
Mehr zu der neuen Version 3.1 von WordPress demnächst noch in einem eigenen Artikel.
