Alexander Langer » Wordpress

+2: Ich bin dabei!

Alexander Langer — Tue, 06 Sep 2011 20:41:57 +0000

Soziale Netzwerke und der Datenschutz, das ist ein lange schwelendes Thema, dass durch die Einschätzung des ULD (Unabhängige Landeszentrum für Datenschutz) und die Aufforderung an alle Stellen Schleswig-Holsteins, Facebook-Fanpages und “Gefällt mir”-Buttons von den Webseiten zu entfernen, erneut angefacht wurde.

Der Heise Verlag nahm dies zum Anlass die Einbindung von sozialen Netzwerken auf den eigenen Websites zu überarbeiten. Heraus kam vor einigen Tagen der 2-Klick-Empfehlungsbutton. Er lädt den eigentlichen Button der sozialen Netzwerke Facebook, Twitter und Google+ erst, nachdem der Benutzer dies über den zugehörigen Button aktiviert hat.

Das Echo auf diesen Vorstoß war so grandios, dass man den Code für das JQuery Plug-in socialshareprivacy nach Aufräum- und Dokumentationsarbeiten nun unter der MIT Lizenz freigegeben und zum Download bereit gestellt hat. Dieser Code wiederum diente H.-Peter Pfeufer als Basis für sein WordPress-Plugin 2-Click Social Media Buttons. Dieses kommt hier ab sofort zum Einsatz und ersetzt damit ein Plug-In für Twitter, eines für Facebook, selbstgestrickten Code für Google+ und ein weiteres Plugin von Seitzeichen für diverse anderen Bookmarking-Dienste, das damit ersatzlos gestrichen wird.

Weitere interessante Artikel:

Googles PlusOne (+1) Button einbinden und nutzen

Alexander Langer — Thu, 14 Jul 2011 21:36:13 +0000

Wir kennen sie alle, diese mal mehr und mal weniger gut erkennbaren Schaltflächen unter und neben News- und Blog-Artikeln um diese weiterzuempfehlen. Was einst mit Bookmarking-Diensten wie del.icio.us (heute: Delicious) und Digg begann und hierzulande etwa von Mister Wong und anderen nachgemacht wurde, wird heute mehr und mehr durch Facebooks “Mag ich”- / “Like”-Funktion übernommen.

Und dann kam Google

Seit ein paar Wochen spielt auch Google mit seiner PlusOne-Funktion (+1) im Bereich Bookmarking / Bewertung mit. Dabei nutzt Google als Marktführer im Bereich der Web-Suche seine Möglichkeiten um +1 direkt in relevanten Google-Diensten zu berücksichtigen. So weisen die Google Webmaster Tools ebenso wie Googles Webstatistik-Dienst Analytics seinen Nutzern entsprechende Statistiken darüber aus, welche Seite des Angebots wann und wie oft gepluseinst wurde (Anm.: Man merkt schon, dass sich die Funktion sprachlich nur sehr unrund transportieren lässt.).

Die Zeit wird zeigen wie und in welchem Umfang Google dieses zusätzliche Signal nutzen wird um die Suchergebnisse entsprechend anzupassen. Dass PlusOne ein Rankingfaktor ist bzw. wird ist unumstritten und liegt auf der Hand. Grund genug für viele Website-Betreiber diese Funktion auch in die eigenen Seiten einbauen zu wollen.

Ist der Einbau der Funktion auf meiner Website sinnvoll?

Das ist die Frage die jeder für sich selbst beantworten muss. Ähnlich wie bei Facebooks Like-Button kann man die Anzeige des Google PlusOne-Buttons in vorgebenem Rahmen anpassen. Dazu gehört die Auswahl ob die Anzahl der getätigten PlusOne-Klicks angezeigt werden soll oder nicht.

So wie man um etwas zu “liken” einen Facebook-Account haben muss, muss man – damit ein Klick auf PlusOne gezählt wird – ein Google Konto haben. Die Zahl derer bei denen dies der Fall ist liegt derzeit sicher deutlich unter der Anzahl derer, die ein Facebook-Konto haben. Google Konten dürften vermehrt in einer eher technikaffinen Zielgruppe zu finden sein. Das könnte sich ggf. aber schnell mit der Verbreitung von Googles brandneuem sozialen Netzwerk Google+ ändern.

Auf diesem Hintergrund muss man sich überlegen welche Zielgruppe die eigene Website hat und wie diese Zielgruppe ggf. auf das Signal agiert, das ein PlusOne-Button mit aktiviertem Zähler aussendet, wenn der Zählerstand bei 0 steht oder halt auf sehr geringem Niveau bleibt. Im Falle dieses meines Blogs mache ich mir da wenig Gedanken zu. “Dabei sein ist alles”, auch um früh Erfahrungen zu sammeln und diese dann auch in andere Projekte einbringen zu können. Den Zähler habe ich aktuell aber deaktiviert.

Der Datenschutz

Wie auch bei Facebooks Like-Button lässt sich Googles PlusOne-Button nur einbinden, wenn man auf der betreffenden Seite Code von einem Server von Google lädt. Das führt unweigerlich dazu, dass Facebook und Google nachvollziehen können welcher (nicht nur) eingeloggte User wann wo wie eine entsprechend ausgestattete Seite besucht hat – auch wenn nichts angeklickt wurde. Datenschutztechnisch ist das ebenso bedenklich wie die Nutzung von Google Analytics, etc.

Was die Verwendung der Klickdaten durch Google angeht, finden sich in den Datenschutzbestimmungen der Google +1-Schaltfläche der folgende Hinweis:

“Wir sind berechtigt, zusammengefasste Statistiken über die +1-Aktivitäten der Nutzer an die Öffentlichkeit, unsere Nutzer und Partner wie etwa Publisher, Inserenten oder verbundene Websites weiterzugeben. So dürfen wir beispielsweise einem Publisher Folgendes mitteilen: „10 Prozent der Nutzer, die dieser Seite +1 gegeben haben, befinden sich in Tacoma im US-Bundesstaat Washington.“ ”

Einen möglichen Workaround für das ungefragte Anfordern von Daten von den Google-Servern und viele gute Hintergrundinfos bietet Marc Stenzel in seinem Artikel “Den Google +1 Button datenschutzkonform integrieren” an.

Google PlusOne (+1) für WordPress

Für das beliebte Blogsystem WordPress gibt es aktuell wenigstens vier Plugins die +1-Schaltfläche integrieren und über die man Positionierung und Anzeigevariante steuern kann. Diese vier stellt khk kurz und knapp in seinem Artikel “SEO – Eine Auswahl von vier Google Plus One Buttons für WordPress Blogs” vor.

Google PlusOne (+1) für Drupal

Für das Content Management Framework Drupal gibt es für die Versionen 6 und 7 das Modul “Google Plus One +1“, nicht zu verwechseln mit dem Modul “+1″.

Google PlusOne (+1) von Hand

Wem HTML-Code nicht fremd ist, der kann +1 auch manuell in seine Website einbauen, so wie ich es hier auch gemacht habe. Dazu stellt Google die ausführliche Dokumentation seiner +1 API auf der Seite “Einfügen der +1-Schaltfläche auf Ihrer Website” zur Verfügung.

Weitere interessante Artikel:

Wenn WordPress immer langsamer wird

Alexander Langer — Wed, 25 Nov 2009 11:21:21 +0000

3,5 Sekunden – so lange dauerte es zuletzt, bis eine Seite meines Blogs erzeugt und ausgeliefert war, zggl. CSS-, JavaScript- und Bild-Dateien. Ich habe das erst gar nicht bemerkt, da ich die letzten Wochen sehr blogfaul gewesen bin. Der schlussendliche Augenöffner war ein Blick in die Google Webmaster Tools. Hier in der Crawling-Statistik ist klar abzulesen, dass gerade in den letzten Wochen und Monaten die Zeit, die der Webserver zur Auslieferung einer Seite meines WordPress Blogs immer größer wurde, im Schnitt rund 2.7 Sekunden, zuletzt bis zu 3.8 Sekunden:

Eine so lahme Website ist nicht nur für Besucher nervig. Nein, die Auslieferungsgeschwindigkeit wird bei Google womöglich in 2010 ein Ranking-Faktor werden. Viele vermuten bereits seit einiger Zeit, dass dies schon aktuell der Fall ist und schnellere Seiten einen Vorteil in den Rankings haben. Der Eindruck mag aber auch nur daher rühren, dass die gut gerankten Seiten eben auch oft gut besucht sind, von größeren Firmen und Projekten stammen und hier einfach mehr und besser an der Infrastruktur gearbeitet wird.

Auf der Suche nach den Ursachen für die wachsende Zähigkeit konnte ich den Server selbst klar ausschließen. Mein Root-Server hat kaum Last, ist gut konfiguriert und hat mit Dual-Quadcores und 8 GB RAM reichlich Leistungsreserven. Schnell fand ich im Netz Frank Bültges kleines Debug Queries Plugin für WordPress. Aktiviert fügt es am Seitenende eine Auflistung der für die Seitengenerierung erzeugten Datenbank-Abfragen durch und gibt aus, wo diese abgesetzt wurden. So war schnell herausgefunden, dass eine einzelne SQL-Abfrage des Popular Post Moduls alleine 3 Sekunden dauerte. Die Abfrage habe ich händisch nochmal in MySQL laufen lassen und die 3 Sekunden Laufzeit wurden hier bestätigt. Ein EXPLAIN förderte zudem ad hoc kein Verbesserungspotenzial im Aufbau der Abfrage zutage, das ich “mal eben” hätte nutzen können.

Da ich noch eine alte 1.3er Version einsetzte, die aktuelle 1.5.1 aber nur über den Zwischenschritt der 1.4.6 upgedatet werden soll, entschloss ich mich kurzerhand das Modul zunächst zu deaktivieren und komplett zu deinstallieren und danach die aktuelle Version zu installieren.

Und siehe da, nun braucht es keine 3,5 Sekunden mehr eine Blog-Seite zu erzeugen, sondern nur noch 0,8 Sekunden! Persönlich empfinde ich das nicht als berauschend schnell, aber so ist WordPress nunmal.

Wenn eure Seiten auch immer langsamer werden, lohnt sich ggf. auch ein Blick auf die Datenbankabfragen – neben diversen anderen Punkten, die ich im Vorfeld schon ausschließen konnte.

Update

Mittlerweile habe ich hier W3 Total Cache laufen. Die Auslieferung des HTML Quelltextes dauert damit – wenn die Seite im Cache liegt – aktuell nur noch rund 70 Millisekunden. Als Cache kann dabei sowohl die Festplatte / der Webspace genutzt werden, als auch APC und Memcache, wenn vorhanden. Da das Blog auf einem meiner eigenen Server läuft, setze ich APC und habe dabei ein Auge auf die Größe des APC Cache. Zusätzlich unterstützt W3 Total Cache die Minifizierung und Komprimierung von CSS- und JS-Dateien mit diversen Optionen und bringt selbst Support für CDNs (Content Delivery Networks) mit.

Weitere interessante Artikel:

Woo! Kaufe 4 WordPress Themes, zahle 1

Alexander Langer — Fri, 19 Jun 2009 06:48:56 +0000

Wer auf der Suche nach einem qualitativ hochwertigen und schicken Theme für sein WordPress Blog ist, der wird früher oder später über WooThemes stolpern. Hier findet man einige sehr gut freie (kostenlose) Themes und eine ganze Menge mehr kostenpflichtige, aber vergleichsweise günstige Themes.

Los geht es bei $70 für ein Theme im sog. Standard Package, oder $150 im sog. Developer Package. Der Unterschied liegt zunächst darin, dass das Developer Paket zusätzlich auch die Photoshop-Dateien enthält. Weiterhin gibt es permanente Aktionen. So kann man im Standard ein Theme kaufen und bekommt ein weiteres, das man sich selbst aussuchen kann, umsonst dabei. Beim Developer Package liegen gleich zwei kostenlose WordPress Themes dabei.

Seit dem 17. Juni und bis zum 24. Juni und unter dem Versprechen, dass diese Aktion nicht verlängert werden wird, gibt es nun beim Kauf eines einzelnen Themes gleich drei weitere WordPress Themes umsonst dazu! Sie nennen es das WOO2: 4-for-1 Launch Special

Ich denke das ist ne coole Gelegenheit für Blogger, die andere Blogger kennen, für kleines Geld in Vierergrüppchen ihren Blogs (oder denen von Kunden) ein neues Layout zu verpassten.

Weiterhin besteht bei WooThemes auch die Möglichkeit einer Mitgliedschaft (Standard und Developer mit Photoshop Dateien). Hier wird zunächst eine Aufnahmegebühr in Höhe von einmalig $110/$180 fällig und eine monatliche Gebühr von $15 bzw. $20, die einem Zugang zum Support Forum und allen Bugfixes und Upgrades aller Themes gibt. Darüber hinaus hat man als Clubmitglied sowieso Zugriff auf alle jemals erschienenen und während der Mitgliedschaft neu erscheinenden Woo WordPress Themes. Die Mitgliedschaft kann monatlich gekündigt werden. Hier findet ihr alle Details zu Preisen und Mitgliedschaft.

Als nächstes wird WooThemes auch auf andere Plattformen expandieren. In Kürze wird man mit Drupal Themes starten, später sollen auch das Shopsystem Magento (die Arbeiten ruhen derzeit) und die Blogging Plattform ExpressionEngine (man wartet auf Version 2.0) bedacht werden.

Weitere interessante Artikel:

Heute neu: WordPress 2.8 und Google Webmaster Tools

Alexander Langer — Thu, 11 Jun 2009 14:17:19 +0000

Mit einem Tag Verspätung wurde heute die Version 2.8 der WordPress Blog-Software herausgegeben. Änderungen gab es diesmal hauptsächlich in Details und unter der Haube. So verfügt der integrierte Theme-Editor nun über Syntax-Highlighting und Zeilennummerierung und über 800 Fehler sollen berichtigt worden sein. Die wichtigsten Neuerungen im detaillierten Überblick stellt Vladimir Simovic auf WordPress-Buch.de vor. Von der versprochenen Performance-Verbesserungen merke ich allerdings nach meinem Update noch nichts.

Syntax Hightlighting und Zeilennummern in WordPress 2.8

WordPress 2.8 ist in der englischen Originalversion und der deutschen Version ab sofort zum Download bereit. Alternativ kann auch die integrierte automatische Upgrade-Funktion genutzt werden.

Ebenfalls seit heute offiziell ist das neue Layout der Google Webmaster Tools. Mit diesem gehen auch neue Features und Änderungen einher, die in der Webmaster Zentrale nachgelesen werden können. Hier wird auch erklärt warum sich manche Angaben inhaltlich von den der bisherigen Google Webmaster Tools unterscheiden, gerade in Bezug auf externe Links. Die neuen Webmaster Tools standem seit einigen Wochen bereits als Alternative zur Nutzung bereit und man konnte per Mausklick zwischen den Versionen wählen.

Weitere interessante Artikel:

Schnellere Webseiten und höhere Conversion durch Komprimierung

Alexander Langer — Mon, 30 Mar 2009 11:08:01 +0000

Anfang Januar habe ich das Hosting dieses Weblogs gewechselt und zwar von meinem seinezeit dienstältesten Root-Server (AMD Single Core, 2 GB RAM) dessen Last zum überwiegenden Teil von Mails erzeugt wird hin zu einem Dual Qualdcore mit 8 GB RAM, der vornehmlich für datenbankgestützte Webanwendungen genutzt wird. Mit dem Umzug einher gingen auch ein paar technische Umstellungen. Die reichlich vorhandene Power des neuen Servers setze ich u.a. dafür ein sämtlichen HTML-, CSS- und JavaScript-Content mit GZip komprimiert auszuliefern.

Kurz und bündig

Je schneller eine Webseite sich im Browser aufbaut, desto besser ist die User Experience, mit entsprechenden Auswirkungen auf Verweildauer, Klickverhalten auf Werbung, etc.
Die Komprimierung von HTML, CSS und JavaScript Code reduziert die Ladezeiten einer Webseite teils signifikant.
Mit wenigen Zeilen kann man seinen Webserver (auch bei Verwendung von Shared Hosting) dahingehend abrichten, die o.g. Inhalte komprimiert an Browser und Bots auszuliefern.

Technische Kosten und Nutzen der Komprimierung

Als Faustregel sagt man grob, dass die CPU Last bei der Verwendung der on-the-fly Komprimierung um etwa 10% pro Request ansteigt. Da HTML, CSS und JavaScript sich sehr gut komprimieren lassen (im Schnitt spart man etwa 70% Platz), lässt sich mit dieser recht einfachen Maßnahme viel Bandbreite sparen und die Daten werden vom Server schneller an den Webbrowser ausgeliefert, da die bei der Übertragung eingesparte Zeit bei weitem größer ist als die zusätzlich benötigte Zeit für die Komprimierung. Diese schnellere Auslieferung hat denn auch positiven Einfluss auf das Nutzerverhalten. Mehr dazu später.

GZip Komprimierung aktivieren für Apache 2.x

Die Realisierung der autom. Komprimierung von HTML, XML, CSS und JavaScript erfolgt über die .htaccess Datei im Hauptverzeichnis des Webs mit folgendem Code:



AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml application/xhtml+xml text/javascript text/css application/x-javascript
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4.0[678] no-gzip
BrowserMatch bMSIE !no-gzip !gzip-only-text/html
SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0

Dieser Code gilt den Apache 2.x mit aktiviertem Modul mod_deflate, es handelt sich dabei um den Nachfolger des mod_gzip Moduls des Apache 1.3 Webservers. Sollte dies nicht vorhanden / aktiv sein, werden die Anweisungen einfach ignoriert. Für ein paar Problemkinder unter den Browsern, vornehmlich einige Dinosaurier, sind zudem Ausnahmeregelungen enthalten, damit es nicht zu Komplikationen kommt. Generell geht man aber davon aus, dass 90% und mehr der aktuell verwendeten Browser problemlos mit GZip Komprimierung klarkommen.

Über die Visualisierung der Crawling-Statistik in den Google Webmaster Tools kann man den Beschleunigungseffekt sehr schön darstellen. Hier sieht man deutlich, wie bei gleichbleibender Menge an Anfragen und abgerufener Daten (entpackt) die benötigte Zeit zum Herunterladen deutlich nach unten ging:

Verringerte Zugriffszeit nach Serverwechsel und Aktivierung der Komprimierung

Mit der Grafik (und einem Kontrollblick in die Server-Logs) kann man auch direkt die Frage mit einem eindeutigen Ja beantworten, ob der Google-Bot die GZip Komprimierung unterstützt. Dies machte Google schon zu sehr frühen Zeiten und man kann sich vorstellen, wieviel Bandbreite und damit einhergehende Kosten sich so sparen lassen.

Je schneller desto Conversion

Web-Surfer sind ungeduldig. Trotz eines gewissen Trends zu ballaststoffreichen Websites mit viel Flash, Videos, etc. erwartet der User, dass Webseiten sich schnell im Browser aufbauen. Der stetige Fortschritt auch und gerade bei den Bandbreiten der Internet-Anschlüsse und die vollmundigen Werbeversprechen der Anbieter führen hier zu einer gewissen Erwartungshaltung.

In seinem Buch Website Optimization gibt Autor Andrew King auch anschaulich Zahlenmaterial weiter, welches Blogger Gabriel Svennerberg in seinem Beitrag Page Load Times vs. Conversion Rates teilweise zusammenfasst:

Eine von 0,4 auf 0,9 Sekunden ansteigende Ladezeit verringert den Umsatz bei Google um 20%.
Jede 0,1 Sekunde zusätzlicher Ladezeit verringert den Umsatz bei Amazon um 1%.
Ein Drittel aller Benutzer mit Breitband-Internet-Zugang ist nicht bereit länger als 4 Sekunden Seiten-Ladezeit hinzunehmen.

Zusätzlichen Lesestoff bietet King auf seiner Website zum Buch.

Abschluss und Ausblick

Wer seine Leser also nicht vergraulen möchte, sollte darauf bedacht sein ihnen eine möglichst gute Benutzererfahrung (Ist das wirklich die passende Übersetzung des Fachterminus UserExperience?) bieten. Neben dem Design kommt der gefühlten Geschwindigkeit einer Website hierbei eine tragende Rolle zu. Die hier vorgestellte Möglichkeit ist nur eine von sehr vielen kleinen und großen Maßnahmen, die man ergreifen kann. In jedem Fall ist sie aber sehr schnell umgesetzt und auch für Laien einfach zu verwenden.

Seit gestern Abend habe ich in diesem WordPress Blog zusätzlich das WP Super Cache Plugin laufen. U.a. speichert es den von WordPress generierten HTML Output als Datei zwischen und liefert diese direkt an Browser aus (mit der zwischenzeitlichen Komprimierung durch den Webserver), so dass der Overhead für Datenbankabfragen und einen Großteil der PHP Skript-Ausführung wegfällt. Ähnliches macht das Boost Plugin für Drupal und Typo3 bringt diese Funktion von jeder mit.

Je nach System, Know-How und Budget gibt es eine Unmenge an organisatorischen und technischen Maßnahmen zur Optimierung der Ladezeiten einer Website. Einen guten Überblick erhält man auch bei Yahoo! in den Best Practices for Speeding Up Your Website (eine deutsche Kurzfassung gibt es auch bei den Webkrauts). Einen schönen Überblick über die eigenen Ladezeiten erhält man u.a. mit dem Firefox Plugin Firebug in der Netzwerkansicht und mit der Firebug Erweiterung YSlow (“Warum langsam?”) von Yahoo!.

Für einen ersten Rundblick tut es aber z.B. auch ein webbasierter Dienst wie den Web Page Analyzer von Andy King. Hier muss man aber etwas vorsichtig sein, da ja der anfragende und auswertende Server in den USA (Chicago) steht..

Weitere interessante Artikel:

WP Mollom Plugin auf Deutsch

Alexander Langer — Wed, 11 Mar 2009 13:41:50 +0000

Da es bislang keine deutschen Sprachdateien für das WordPress Plugin für den Anti-Spam Dienst Mollom zu geben scheint, habe ich mich mal selbst darüber hergemacht. Einfach die folgenden beiden Dateien in das wp-mollom Verzeichnis eures Plugin Ordners legen und das war es schon. Erstellt wurden die Dateien von / mit / für WP Mollom 0.72 und werden in der nächsten Version des Plugins integriert werden.

Auf die Qualität gebe ich übrigens keine Gewähr. Feedback und Verbesserungen sind natürlich willkommen:

Weitere interessante Artikel:

Auf der CeBIT mit Drupal

Alexander Langer — Mon, 09 Mar 2009 17:13:17 +0000

Ein anstrengendes Wochenende ist vorüber und die CeBIT 2009 hat trotz 25% weniger Ausstellern und 20% weniger Besuchern als im Vorjahr zufriedene Aussteller hervorgebracht, zumal der Anteil an Fachpublikum unter den Besuchern höher war als zuletzt. Für mich war es auch das erste Mal, dass ich als Standbetreuung auf der weltgrößten IT Messe war.

Möglich machte es das Losglück (behaupte ich mal einfach, ich glaube aber nicht, dass wirklich nur die Würfel entschieden haben). Unter den Gewinnern von mehr als 70 bewerbenden Projekten fand sich neben KDE, Mozilla und anderen eben auch das Open Source Content Management System und Framework Drupal, welches sich auf einem Gemeinschaftsstand in der “Open Source Lounge” der Linux New Media AG präsentieren durfte.

Nach Bekanntgabe ging es dann ganz schnell und es fanden sich lauter Freiwillige, die über die Messewoche hinweg die Standbetreuung übernehmen wollten. Selbst hatte ich mich etwas später für den Samstag gemeldet. Passte mir gut in den Kram, um über die Woche normal arbeiten und erreichbar sein zu können (es standen noch zwei Projektlaunches an).

Um 05:15 Uhr klingelte der Wecker und gegen 06:40 Uhr nahm ich die ersten der rund 250 km unter die Räder. Ziemlich genau zur Öffnung um 09:00 Uhr kurvte ich am Expo Gelände in ein Parkhaus – geschmeidige 8 Euro für ein Tagesticket zahlend. Naja, da kam es auch nicht mehr drauf an ;-)

Kurz noch in Halle 26 meinem Co-Admin Franky aus dem Roosters Forum einen Besuch abgestattet und dann ging es auch schon auf direktem Wege zu Daniel und Stefan, Halle 6, Stand F50. Nach etwa einer ruhigen Stunde muss dann von irgendwo eine ganze Busladung Menschen gekommen sein. Ich erinnere mich, dass mein Mund vom vielen Sprechen immer trockener wurde. Die trocken-warme Luft in der Halle tat ihr übriges. Irgendwann kam auch noch Meinolf auf Stippvisite vorbei, er sollte zum Abschlusstag am Sonntag seine offizielle “Standzeit” haben.

Daniel Wehner (l) und Stefan Borchert (r) im Gespräch

Das Publikum präsentierte sich bunt gemischt, doch die meisten steuerten uns gezielt an und hatten konkrete Fragen. Manche wollten die Empfehlungen ihrer Webmaster und Agenturen einfach nochmal von Dritten beleuchtet sehen, andere kamen auf reine Empfehlung, wieder andere hatten konkrete Probleme bei der Umsetzung. Für mich persönlich war es zwischendurch schön, endlich mal wieder mein eingerostetes Englisch auspacken zu können.

Besonders angeregt zu ging es mit zwei Mitarbeitern des skandinavischen Fernsehsenders TV3 aus Dänemark. TV3 hat zuletzt die schwedische Website von Joomla (übrigens das zweitmeist genannte Wort am Stand an diesem Tage) auf Drupal umgestellt und vollzog diesen Schritt nun auch für die Sites der übrigen skandinavischen Länder. Als erwähnt wurde, dass man in Dänemark Schulungen erhalten habe, kam mir gleich ein Verdacht, der sich auf Rückfrage bestätigte. Die Schulung hatte natürlich MortenDK (aka King of Denmark) durchgeführt, bei dessen Session auf dem DrupalCamp in Köln im Januar ich aus dem Lachen kaum herausgekommen war. Ein ganz wunderbar verrückter wie fähiger Typ.

Mit einem Amerikaner ergab sich auch noch eine sehr unterhaltsame Diskussion darüber, wie man mit Open Source Geld verdienen könne. Ich war etwas baff, dass er selbst WordPress nutzte, aber die üblichen Business Models rund um Open Source ihm nicht geläufig waren.

Ich könnte so viel schreiben, lasse es aber bleiben. Um 18 Uhr hatte ich es dann auch recht eilig schnell nach Hause zu kommen, mich frisch zu machen und zur Saison Abschlussfeier der Roosters zu hetzen und mich sinnlos zu betrinken. Es wäre schneller gegangen, hätte ich nicht eine halbe Stunde in einer Vollsperrung der A2 gestanden, wo ein LKW durch die Mittelleitplanke wollte. Ich hoffe es wurde niemand ernstlich verletzt.

Mein Dank gilt den edlen Standspendern der Linux New Media AG, den Bewerbern und Organisatoren, meinen Mitstreitern Anja, Daniel und Stefan, die mich den ganzen Tag lang ertragen haben und natürlich allen Besuchern, ob aus Deutschland, Dänemark, USA, Malaysia, Italien, .. mit all ihren teils kuriosen, großteils aber sehr interessanten Fragen und Anmerkungen.

Ach ja.. Danke auch an Das Güldene M. Als ich irgendwann deutlich nach 19 Uhr zu einem Mäcces die Autobahn verließ, mir schnell zwei Burger besorgte (und obwohl ne Polizeihundertschaft gerade dasgleiche machte, bekam ich meine beiden ratzfatz) und diese dann bei der Weiterfahrt mampfte, ging es mir dann auch schnell etwas besser. Schließlich war es meine erste Mahlzeit des Tages..

Weitere interessante Artikel:

Update auf WordPress 2.7.1

Alexander Langer — Tue, 24 Feb 2009 10:14:09 +0000

Nichtsahnend komme ich heute Morgen ins Büro, packe mein MacBook aus, schalte es ein, checke Mails, checke Newsfeeds – nanu!? – was ist denn das? Da stehen in meinem Kommentar-Feed doch vier neue Kommentare, allesamt automatische Spam-Kommentare mit reichlich Links und Keywords drin (das übliche Zeug). Seltsam, bislang hatte Spam Karma 2 immer sehr zuverlässig out of the box gearbeitet.

Ich schaue ins Blog, markiere die Kommentare als Spam und finde noch ein paar mehr. Für keinen einzigen davon bekam ich eine E-Mail. Bevor es nun überhand nimmt, habe ich mich kurzentschlossen dazu entschieden meine WordPress Installation zu updaten. Das wollte ich mal irgendwann wenn Zeit ist in Ruhe nebenher testen und dann einspielen, aber ich möchte auch nicht dauernd Angst haben, dass ich zugespammt werde.

Das Update von WordPress 2.3.3 auf die aktuelle deutsche Version 2.7.1 gestaltete sich dann recht einfach, dank dieser Update Anleitung. Das Vorgehen unterscheidet sich im Grunde nicht von dem bei einem Drupal-Update, Backup anfertigen, Plugins deaktivieren, alte Installation bis auf eigene Daten (Konfiguration, Theme, hochgeladene Daten, Plugins) löschen, neue Version einspielen, Upgrade anstoßen und das war es denn auch.

Funktionierte völlig problemlos und kaum im neuen WordPress Backend eingeloggt (daran muss ich mich erstmal gewöhnen), habe ich meine alten Plugins wieder aktiviert und gehofft, dass soweit alles läuft. Bis dato kann ich keine Probleme feststellen. Auch das automatische Update von ein paar Modulen habe ich gleich mal getestet und lief soweit durch, bis auf das von mir eingesetzte WordPress Related Posts 0.9 . Wer der Update Empfehlung folgt hat im Anschluss nämlich Version 1.0 des Moduls Related Posts / Pages von Thamizhchelvan installiert und das ist mal ganz was anderes.

Falls wem irgendwas auffällt, vielleicht beim Kommentieren, beim E-Mail Abo für neue Kommentare und dergleichen, bitte kurz Bescheid geben. Entweder als KOmmentar oder wenn das nicht geht per Mail an kontakt(_AT_)alexander-langer.de .

Als nächstes schaue ich dann mal, ob ich nicht Mollom für WordPress anteste.

Weitere interessante Artikel:

Duplicate Content mit kanonischen URLs in Drupal und WordPress vermeiden

Alexander Langer — Sat, 14 Feb 2009 14:17:46 +0000

Duplicate Content ist ein Begriff dessen bloße Erwähnung vielen Web-Workern Schweißperlen auf die Stirn treibt. Suchmaschinenbetreiber Google hat irgendwann die Duplicate Content Penalty eingeführt, eine Abstrafung im Ranking für Seiten, die inhaltsgleich zu anderen Seiten sind. Mit den sog. Kanonischen URLs stellt Google selbst nun ein eigenes Konzept zur Vorbeugung vor. In der Drupal Community geht vielfach die Angst für der DC Penalty um, da Inhalte gerade bei Einsatz von sog. suchmaschinenfreundlichen URLs (noch so ein hartnäckiger SEO Mythos) in Verbindung mit der mod_rewrite Erweiterung des Apache Webservers den Nebeneffekt haben, dass sie fortan über mehrere URLs erreichbar sind.

Für Drupal

Nehmen wir folgendes Beispiel einer imaginären Drupal Website http://diewebsite.tld , mit einem Inhaltstyp “News”. Der Entwickler hat mittels Pathauto Modul (dt.: Autopfad) festgelegt, dass alle Artikel des Typ News über eine URL http://diewebsite.tld/news/[nid] erreichbar sind. Ohne zusätzliche Maßnahmen ist eine solche News nun aber über wenigstens vier unterschiedliche URLs gleichermaßen erreichbar:

Vereinfachtes Beispiel einer News mit der Node ID 666:

http://diewebsite.tld/news/666
http://diewebsite.tld/node/666
http://diewebsite.tld/?q=news/666
http://diewebsite.tld/?q=node/666

Google selbst sieht darin nach eigenen Aussagen kein Problem und Sorgen, man könne in einem solchen Fall (mehrere URLs mit demselben Inhalt) bereits abgestraft werden sind unbegründet. Eher ängstliche Gemüter behalfen sich in Drupal bislang mit dem Modul Global Redirect, das für einen Redirect mittels HTTP Status Code 301 (moved permanently) sorgt.Obwohl es also laut Google eigentlich kein Problem gibt, hat man nun mit den Canonical URLs ein Konzept eingeführt, das auch den letzten Zweifel ausräumen soll. Dahinter steckt nichts weiter als eine zusätzliche Angabe im HTML Head Bereich einer jeden Seite über die bevorzugte URL für diese Seite. In unserem Beispiel würde der Eintrag so aussehen, der egal über welche URL ich den Inhalt erreiche, im HTML Quelltext stehen würde:

In Drupal erreicht man diese Angabe ganz einfach über ein klein wenig Code an entsprechender Stelle der page.tpl.php :


< ?php if ($node) : ?>

< ?php endif; ?>

Dies ist ein denkbar einfaches Beispiel für die Integration von Googles kanonischen URLs in einem denkbar einfachen Fall, nämlich für die Seitenansicht einzelner Nodes in Drupal.

Interessehalber habe ich in einem Projekt mal einen Blick in die über das XML Sitemap Modul erzeugte sitemap.xml geworfen und fand, dass für eine Reihe von Nodes nicht der Alias-Pfad erscheint, sondern der reine Pfad über node/[nid] . Gibt Google diesen einmal in seinen Suchergebnissen an, kann es natürlich vorkommen, dass irgendwer extern einen Link auf einen solchen unerwünschten Pfad setzt. Dann könnte man sich wirklich fragen, ob oder ob nicht Google in der Vergangenheit hier Duplicate Content angenommen hat.

Doch mit den kanonischen URLs sollte sich auch dieser letzte Restzweifel ausräumen lassen, denn die hierdurch empfohlene Darstellungsweise der URLs wird von Google auch mit in SERPs übernommen.

Für WordPress

Eine ebenso einfache und schnelle Möglichkeit canonical URLs für WordPress zu nutzen, stellt WordPress Experte Frank Bültge in seinem Blog vor. Ab WordPress Version 1.5 liefert folgender PHP Schnipsel im Header des Themes die Lösung:


< ?php if ( is_singular() ) echo ''; ?>