SEO Campixx 2011 Recap

Die SEO Campixx 2011 ist auch wieder vorbei und bevor die Erinnerungen verschwinden, wollte ich schnell ein paar Worte dazu schreiben.
Die SEO Campixx 2011 war alles in allem auch dieses Jahr wieder ein voller Erfolg. Die meisten Vorträge waren, wie auch die letzten Jahre, deutlich werbefreier als bei vielen anderen Konferenzen. Dazu kommt dass die meisten Vortragenden sich wirklich sehr viele Mühe gemacht haben und ihr Thema schön aufbereitet haben.

Die in meinen Augen lustigsten/besten Vorträge kamen dieses Jahr von Jens Fauldrath und von dem Gespann BöserSEO und Andre Alpar. Besonders Black Hat Protection war interessant – besonders auch durch die anschließende Diskussion.

Ansonsten hat Marco dieses Jahr auch wieder ein super Rahmenprogramm zum Networken auf die Beine gestellt. Und daher ist es nicht verwunderlich, dass es auch dieses Jahr in der Hausbar bis in die frühen Morgenstunden viele Leute aufzufinden waren.

Duplicate Content Vortrag

Dieses Jahr hab ich mit Stefan Preusler zusammen auch einen Vortrag zum Thema Duplicate Content gehalten. Anhand eines Testprojekts wurde dabei erklärt wie man möglicherweise noch mit DC ranken kann und wie unsere Erfahrungen damit sind.

Duplicate Content – SEO-Campixx Vortrag 2011

View more presentations from codersx

Was andere schreiben

Ausser mir haben auch schon ein paar andere ein Recap geschrieben:

Magento: CMS Block im Template ausgeben

Bei Magento gibt es mehrere Möglichkeiten Blöcke anzulegen. Die einfachste Möglichkeit besteht darin, dass man die Blöcke direkt im integrierten CMS anlegt. Dadurch verliert man zwar die Möglichkeit in den Blöcken Code auszuführen, allerdings dürften bestehen viele Blöcke sowieso nur aus statischen Inhalten.

Statische Blöcke einbinden

Am saubersten erfolgt die Einbindung in den Layout-XML Dateien:




 
 block_id

Alternativ dazu kann man Blöcke auch direkt in die Template Dateien ( .phtml ) einbinden:

echo $this->getLayout()->createBlock('cms/block')->setBlockId('block_id')->toHTML();

Die letzte Möglichkeit ist die Integration direkt in eine CMS-Seite:

{{block type="cms/block" block_id="block_id" template="cms/content.phtml"}}

Das WordPress Afilliate Plugin – wpAffiliCheck

Wer sich mit WordPress beschäftigt und damit die ein oder andere Affiliate Seite erstellt, wird schnell feststellen: Es gibt sehr viele WordPress Plugins für Amazon, Adsense und um Banner zu integrieren. Wer aber für die deutschen Affiliate Netzwerke gute Plugins sucht, bei dem macht sich schnell die Ernüchterung breit.

Da auch ich vor einigen Tagen mal wieder auf der Suche nach einem passenden Plugin für die Affilinet API war und enttäuscht wurde, habe ich mich spontan dazu entschlossen schnell ein eigenes Plugin für den Eigenbedarf zu entwickeln.

wpAffiliCheck – das Affiliate Plugin für den deutschen Markt

Rausgekommen ist dabei das Plugin wpAffiliCheck. Gedacht ist das Plugin vor allem für Blogs und Sites die über einzelne Produkte berichten. Bei der Erstellung des Posts kann man in einer Box unterhalb des Contentfeldes die EAN für das Produkt eintragen.

wpAffiliCheck - CustomBox

Falls man die EAN des Produktes nicht kennt, kann man mit der Amazon Produkt Suche die EAN des Produkts schnell herausfinden.

wpAffiliCheck - Produktsuche

Durch einen Klick auf das Produkt wird die EAN des Produktes in das EAN Feld eingefügt. Damit sich das Plugin optimal in WordPress einfügt, habe ich die Suche mit ajax/jQuery umgesetzt.

wpAffiliCheck Anzeigemöglichkeiten

Wenn ein Post eine dazugehörige EAN hat, gibt es zwei Möglichkeiten wie die Preisdaten der verschiedenen Partnerprogramme angezeigt werden. Die einfachere Variante ist die Darstellung in einer Tabelle, wo alle Partnerprogramme mit Preis aufgelistet werden, welche das Produkt in ihrem Shop führen.

wpAffiliCheck - Preisvergleich

Die Darstellung der Tabelle ist dabei mit geringen PHP Kentnissen individualisierbar. Im Backend des Plugins kann man einstellen, ob die Tabelle oberhalb oder unterhalb des Contents angezeigt wird. Auch die Sortierung der Tabelle kann man verändern. Durch Tracking welche Links wie oft angeklickt werden, kann man die Tabelle auch anhand eines QualityFactors sortieren lassen.

Die zweite Möglichkeit der Anzeige ist die Integration von Variablen in den Content. Zur Verfügung stehen folgende Variablen:

  • [price] – Die Ausgabe des Preises ohne Währungsangabe. (z.B. 233,00)
  • [shopname] – Der Name des Online Shops. Der Name wird aus der API übernommen, kann aber in der Datenbank vollständig angepasst werden.
  • [link] – Der Link zu dem Produkt.

Die Variablen werden dabei immer mit dem derzeit günstigsten Angebot ersetzt. Durch die Integration der Links in den Content konnte ich bei ein paar Projekten deutlich höhere CTRs feststellen, als mit der Preisvergleichstabelle.

Die Variablen können beliebig oft innerhalb des Contents verwendet werden. Allerdings kann es passieren, falls das Produkt aus allen Shops entfernt wird, dass die Variablen Ersetzung nicht mehr  funktioniert.

Das Backend

Wie bereits angekündigt, kann man in dem Backend die Caching Time und weitere Optionen einstellen.

Wordpress Affiliate Plugin - Backend

Wie man in dem Screenshot des Backend bereits erkennen kann, kann das Plugin derzeit nur auf die Daten der Partnerprogramme von Affilinet und des Amazon Partnernet zurückgreifen. Eine Integration von Zanox ist in naher Zukunft geplant. Andere Affiliate Netzwerke werden wohl in nächster Zeit nicht integriert werden.

WordPress Affiliate Plugin downloaden

Das Plugin ist aus der Not heraus entstanden und funktioniert einwandfrei bei meinen Installationen. Vor der Veröffentlichung würde ich das Plugin allerdings gerne noch auf verschiedenen Installationen testen lassen und gegebenenfalls die Fehler ausbessern. Ich würde mich daher freuen, wenn sich zwei oder drei Leute als Betatester bei mir melden.

Magento auf einen neuen Server umziehen – Typische Fehler

Eine Website von einem Server auf einen anderen umzuziehen ist nicht einfach, deutlich schwieriger wird das ganze aber nochmal wenn die Website ein Shop ist. Da ich schon einige Magento Shops umgezogen haben, wollte ich meine Vorgehensweise vorstellen und die typischen Probleme bei einem Magento Umzug mit der entsprechenden Lösung auflisten.

Bewährte Vorgehensweise

  • Shopsystem auf dem Server zu einer .zip Datei zusammenfassen
    Die meisten Magento Shops dürften auf Managed-Servern oder Root-Servern laufen. Sowohl auf Root als auch auf Managed Servern sollte man die Möglichkeit haben den Shop zu zippen.
    Da Magento aus extrem vielen kleinen Dateien besteht, dauert der Transfer der Dateien ohne das zippen deutlich länger.
  • Datenbank mit phpMyAdmin exportieren
    Beim Export der Datenbank sollte man darauf achten, dass die Option Fremdschlüsselüberprüfung deaktivieren aktiviert ist. Da Magento, wie alle größeren Shop Systeme, in der Datenbankstruktur viele Foreign Keys verwendet, kann es sonst zu Problemen beim Import führen. Am Ende der exportierten Datei wird die Fremdschlüsselüberprüfung von phpMyAdmin automatisch wieder aktiviert.
  • Datenbank und Magento auf den neuen Server hochladen
    Die Datenbank kann man im komprimierten Zustand auch per FTP Client hochladen. Magento selbst sollte, um Zeit zu sparen, direkt von dem alten Server auf neuen Server hochgeladen werden werden.
  • Magento entpacken
  • Die Datenbank mit mysqldump oder bigdump einlesen.
  • Datenbank Zugangsdaten ändern
    Falls sich die Datenbank Zugangsdaten auf dem neuen Server geändert haben, muss man diese in der Datei /app/etc/local.xml auch anpassen.
  • In der Datenbank müssen anschließend noch zwei Werte modifiziert werden. Beide Einträge befinden sich in der Tabelle core_config_data. Der erste Eintrag ist web/unsecure/base_url, welcher die neue URL des Shops bekommen sollte. Der zweite Eintrag ist web/secure/base_url, welcher die HTTPS URL des neuen Shops beinhalten sollte.
    Falls der Shop nur auf einen neuen Server umgezogen wird, ohne dass dabei ein URL Wechsel vollzogen wird, kann dieser Schritt übersprungen werden

Nachdem man die Schritte alle ausgeführt hat, sollte der Shop wieder problemlos auf dem neuen Server funktionieren. Da aber trotzdem immer wieder Probleme dabei auftreten, habe ich hier eine Liste über Typische Probleme angehängt.

USING BTREE

Fehlermeldung
ERROR 1064 (42000) at line 382: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‘USING BTREE,
KEY `FK_ATTRIBUTE_VARCHAR_ENTITY` (`entity_id`),
KEY `FK_CATALO’ at line 9

Problem & Lösung
Ältere MySQL Versionen können mit USING BTREE hinter der Liste der Unique Keys nichts anfangen. Daher muss man in dem Datenbank Dump folgende Zeile suchen:

UNIQUE KEY `IDX_BASE` (`entity_type_id`,`entity_id`,`attribute_id`,`store_id`) USING BTREE,

und mit folgender Zeile austauschen:

UNIQUE KEY `IDX_BASE`  USING BTREE (`entity_type_id`,`entity_id`,`attribute_id`,`store_id`),

Falls das einspielen des Dumps danach immer noch nicht funktioniert, wird in verschiedenen Blogs geraten das USING BTREE einfach herauszulöschen. Ich konnte die Dumps bisher nach der Umstellung immer einspielen und würde daher von solchen Modifikationen abraten.

Store Zusammenhänge

Fehlermeldung
Undefined index: 0 in /app/code/core/Mage/Core/Model/Mysql4/Config.php on line 92

Problem & Lösung
Beim Umzug von Magento kann es vorkommen, dass Indexe erhöht werden und anschließend die interne Zuordnung von Stores zu Websites nicht mehr funktioniert. Ich hatte das Problem bei älteren Versionen mehrmals, bei 1.4.x ist es mir allerdings noch nicht untergekommen.

Im Internet kursieren dazu verschiedene Lösungen, die meistens das manuelle Editieren der betroffenen Einträge zur Folge haben. Das manuelle editieren in Datenbanken sollte man allerdings Fachleute machen lassen, da man hier schnell Datensätze kaputt machen kann.

setWebsite() must be an Instance…

Fehlermeldung
Recoverable Error: Argument 1 passed to Mage_Core_Model_Store::setWebsite() must be an instance of Mage_Core_Model_Website, null given, called in /path/app/code/core/Mage/Core/Model/App.php on line 427 and defined in /path/app/code/core/Mage/Core/Model/Store.php on line 279

Lösung
Um das Problem zu lösen, muss man die Datei /app/etc/use_cache.ser löschen.

Goodbye Drupal 5

Nachdem vor einigen Tagen Drupal 7 veröffentlicht wurde, wird ab dem 21.1.2011 Drupal 5 nicht weiter supported. Das bedeuted für alle Websites die derzeit noch Drupal 5 einsetzen in Zukunft:

  • Keine offiziellen Bug Fixes
  • Keine Security Updates
  • Das Modul Update Status Feature wird vermutlich demnächst nicht mehr funktionieren

Drupal rät allen Nutzern, die derzeit noch Seiten mit 5.x betreiben, ein Update auf die Version 6 oder 7. Gerade bei komplexeren Seiten würde ich aber derzeit auf jeden Fall die Version 6 vorziehen, da viele wichtige Module für Drupal 7 derzeit noch nicht vorhanden sind.

Für mich ist Drupal 5 auch etwas besonderes – es war die erste Drupal Version mit der ich produktiv gearbeitet habe. Anfangs von Views und CCK eher verwirrt, hab ich schnell die Vorzüge der Module kennen gelernt und würde sie heute nicht mehr missen wollen. Besonders in Drupal 7 wurde die Usability der Module auf ein angemessenes Niveau gehoben – mittlerweile kann man wohl selbst Laien mit dem System vertraut machen.

In diesem Sinne: Goodbye Drupal 5.

Drupal SEO Module: Page Title

Der Title einer Seite gehört zu den wichtigsten SEO Onpage Faktoren. Mittlerweile gibt es für fast jedes Content Management System ein Plugin, um den Title der Seite beliebig anzupassen. Natürlich gibt es auch eine Erweiterung für Drupal, um die Titles anzupassen.

Mit dem PageTitles Modul kann man die Titles einer Drupal Seite mit zusätzlichen Keywords erweitern. Mithilfe des Moduls kann man für jede Seite einen Unique Title erstellen, auch wenn der Inhalt sich über mehrere Nodes verteilt.

Flexibilität für optimale Titles

Das PageTitles Modul kann sowohl den Standard Title Aufbau ändern. Durch die enorme Flexibilität des Moduls kann man für jeden Content Typen einen eigenen Standard Title einstellen.

Page Titles

Die Standard Titles setzt sich zusammen aus mehr als 50 möglichen Variablen. Auch für die Taxonomy Seiten (zum Beispiel Tag Seiten) kann man in den Einstellungen spezielle Standard Titles angeben.

Falls man für einzelne Nodes nicht den Standard Title verwenden will, kann man für jeden Node auch den Standard Title überschreiben. Das geschieht mit einem Feld unterhalb des Content Feldes.

Magento Stratus und die Entwicklungen 2011

In den letzten Tagen macht Magento vor allem Schlagzeilen durch das neue Produkt Magento Stratus. Dabei handelt es sich um eine sehr gut skalierbare Magento Mietlösung. Das bedeutet, dass der Shop von der Firma hinter Magento für einen monatlichen Obulus gehostet und geupdatet wird. Obwohl die Software gehostet wird, soll sie ähnlich flexibel und anpassbar wie eine eigene Installation sein.

Die Realität sieht dann aber immer etwas anders aus, als die Ankündigungen der Hersteller. So haben die ersten Tester die Anpassungsfähigkeiten als sehr fehlerbehaftet bezeichnet. Speziell im Vergleich mit den großen Shop-SaaS Anbietern wie Demandware und Venda kann Magento Stratus wohl nicht mithalten, obwohl sich eine eigene Magento Installation hinter den Mietshops keinesfalls verstecken muss. Da ich bisher leider noch keinen Beta Account für Magento Stratus erhalten habe, muss ich mich allerdings derzeit noch auf die Berichte von anderen Beta Testern verlassen. Weitere Informationen zu Magento Stratus gibt es bei Alexander Ringsdorff und Magethemes.com.

Magento Entwicklungen in 2011

Die größte Neuerung in 2011 dürfte wohl das Erscheinen der Version 1.5 von Magento sein. Seit Dezember 2010 steht bereits die erste Alpha Version von Magento 1.5 zum Download bereit, welche allerdings noch einige Bugs vorweist.

In Magento 1.5 wurden unter anderem folgende Features integriert:

  • Editieren von fertigen Bestellungen
  • Multistep Checkout ohne Javascript
  • konfigurierbarer Order-Status
  • verbesserte Importfunktionalität

Zusätzlich wurden noch einige Bugs gefixt. Trotzdem werde ich hier das Gefühl nicht los, dass die Entwickler mit dem 1.* Zweig schon gedanklich abgeschlossen haben und sich bereits voll auf den 2.* Zweig fokusieren.

Eine kurze Zusammenfassung mit Bildern über die neue Funktionen findet man auch hier und hier.

Custom Types bei WordPress

Seit der Veröffentlichung der WordPress Version 1.0 im Jannuar 2004 hat sich WordPress immer weiter zum CMS entwickelt. Durch die Einführung von Custom Post Types in der Version 3.0 wurde diese Entwicklung fortgeführt.

Was sind Custom Post Types?

Mit Custom Post Types ist es möglich eigene Post Types anzulegen. Bisher war WordPress auf die Post Types Posts und Pages festgelegt. Seit der Einführung von Custom Post Types kann nun jeder Nutzer beliebig viele weitere Post Types einrichten, um so beispielsweise bestimmte Bereiche der Seite besser abzugrenzen. Denkbar wäre es zum Beispiel eine Datenbank über alle Folgen einer Serie zu machen.

Was benötige ich für Custom Post Types?

Um Custom Post Types benutzen zu können, benötigt man eigentlich noch nicht einmal ein Extra Modul, da dieses Feature in der Standard Version von WordPress 3.* bereits vollständig integriert is. Damit WordPress weiterhin einfach zu bedienen ist, haben die Entwickler von WordPress allerdings auf ein User Interface für dieses Feature verzichtet. Ein User Interface kann man allerdings mit dem Plugin Custom Post Type UI nachrüsten.

Wie richte ich Custom Post Types ein?

Custom Post Types

Custom Post Types

Wenn man das Custom Post Type UI Plugin installiert hat, gibt es im WordPress Admin ein Menüreiter Custom Post Types. Unter Add New können verschiedene Post Types angelegt werden.

Um einen neuen Post Type zu erstellen, sollte man neben den Basic Angaben auch die Advanced Options beachten.

Custom Post Types

In den Advanced Options kann man einige wichtige Einstellungen verändern, wie beispielsweise den Rewrite Slug (sozusagen den Ordner der URL). Mithilfe der Option Show UI kann man den WYSIWYG-Editor von WordPress aktivieren.

Die aktivierten Felder bei Supports aktivieren oder deaktivieren die verschiedenen Boxen, welche man auch beim Hinzufügen eines normalen Posts sieht. Bei den Checkboxen Built-in Taxonomies kann man die Standard Taxonomie für den neuen Post Type aktivieren oder deaktivieren.

Custom Post Type Advanced SettingsWirklich interessant wird das ganze aber vor allem durch das Anlegen neuer Taxonomien. Dadurch werden einem neue Möglichkeiten eröffnet, wovon viele WordPress Nutzer vorher nicht einmal träumen konnten. Beispielsweise das Taggen des Beitrags nach Autor, Darsteller und Produzent. Die Taxonomien können für mehrere Post Types aktiviert werden, wodurch auch normale Blog Posts mit den Tags in Verbindung gebracht werden können.

Wie bei WordPress gewohnt kann man sowohl Tags als auch Kategorien anlegen. Hierfür muss man beim anlegen wiederum die Advanced Options der Taxonomie ausklappen. Die Option hierfür nennt sich Hierarchical. Auch den Rewrite Slug kann man, ähnlich wie beim anlegen des Post Types, hier verändern.

Taxonomie anlegen

Nachdem ein neuer Post Type angelegt wurde und für diesen Post Type Taxonomies hinzugefügt wurden, erscheint dieser Content Type ebenso wie Posts oder Pages in dem Admin Menü.

Custom Post Types in ein Modul integrieren

Wie bereits angesprochen, kann man die Custom Post Types auch ohne zusätzliches Modul verwenden. Dadurch lassen sich mit den Custom Post Types sehr flexible und komplexe Module entwickeln. Für die meisten Anwendungszwecke dürfte aber die Verwendung des Plugin Post Type UserInterfaces vollkommen ausreichen.

Drupal 7

Nachdem vor einigen Tagen eine neue WordPress Version erschienen ist, legt Drupal mit dem Release von Drupal 7 nach. Nachdem die letzten Tage schon fleissig die Release Candidates getestet worden sind, sind jetzt alle Bugs beseitigt und Drupal 7 eignet sich theoretisch für den Live Betrieb.

Die Praxis schaut leider etwas anders aus, da neue Drupal Versionen auch immer Neuerungen in der API nach sich ziehen und so viele Module erstmal geupdatet werden müssen. Auch wenn die API in Drupal 7 im Vergleich zu früheren Updates nur wenig verändert wurde, so stehen derzeit nur 20% der Drupal 6 Module auch für Drupal 7 zur Verfügung.

Neue Features

Verbessertes User Interface
Wie auch bei WordPress hat sich bei Drupal einiges am User Interface getan. Besonders das Admin Interface soll durch ein neues Administrations Theme, ein Overlay Modul und eine konfigurierbare Shortcut Bar deutlich verbessert worden sein. Ausserdem wurde In-Place Editing für Blöcke und Nodes in Drupal 7 eingebaut.

Custom Fields
Drupal ist im Vergleich zu anderen Content Management Systemen besonders flexibel durch das CCK und Views Modul. Ein Custom Fields Modul, dem CCK Modul sehr ähnlich, wurde nun als Drupal Core Modul hinzugefügt. Im Vergleich zu CCK kann das neue Modul Felder aber auch zu Taxonomy Terms und Users hinzufügen.

Image Handling
Das bisher größte Problem von Drupal war meiner Meinung nach die mangelhafte Unterstützung von Bildern. Zwar gibt es mehr als genug Module um Bilder an Nodes anzuhängen oder direkt in Nodes anzuzeigen, aber kein Modul war hier vergleichbar mit der Medien Verwaltung von WordPress.
Mit der neuen Version werden einige Image Funktionen in den Core aufgenommen. So ist es in Zukunft ohne Module möglich Image Felder zu Content Types hinzuzufügen. Auch minimale Bearbeitungsfunktionen wie Scaling und Cropping bringt Drupal in der Version 7 standardmässig mit.

Update Manager
Bisher wurde dem Benutzer im Admin Interface nur angezeigt, dass ein Modul veraltet ist. Mit der neuen Version des Update Managers kann Drupal jetzt per Knopfdruck Themes und Module updaten.

Sonstiges

Release Partys

Pünktlich zum Drupal 7 Release finden heute in über 200 Städten Drupal Release Partys statt. Auch in Deutschland finden in den größeren Städten Release Partys statt.

WordPress 3.1

Nachdem heute der Release Candidat 2 von WordPress 3.1 veröffentlicht worden ist, will ich hier einen kleinen Ausblick auf die neue WordPress Version geben.

WordPress 3.1 wird die letzte Version sein, welche unter PHP4 und MySQL4 laufen wird. Ab der Version 3.2 werden mindestens PHP 5.2 und MySQL 5.0.15 vorausgesetzt. Durch den Umstieg auf PHP5 wird es den Plugin Entwicklern auch möglich sein, die Plugins nur noch in PHP5 zu entwickeln. Damit die Plugins bisher auf allen Servern liefen, wurden viele PHP5 Funktionen mit PHP4 Funktionen nachgebaut, was fast immer unsauberen Code zum Resultat hatte.

Neue Features

Natürlich wurden in der Version 3.1 auch neue Features eingebaut. Umgesetzt sind bereits folgende Features:

Durch die Verbesserung der Adminoberfläche ist es nun auch endlich möglich, die Posts und Pages nach Autor, Titel oder Datum zu sortieren. Eine Übersicht mit Screenshots der wichtigsten neuen Funktionen mit gibt es  hier.

Und alle weniger Testfreudigen Benutzer von WordPress sollten zumindest auf die Version 3.0.4 updaten.