Ein Updaten auf die neuste Version brachte keine Abhilfe, erst nach einigem Suchen entdeckte ich im Help-Forum von phpMyAdmin einen entsprechenden Hinweis:

… Um Zeilen bearbeiten zu können, benötigt phpMyAdmin einen Primärschlüssel, um MySQL sagen zu können, welche Zeile gemeint ist. Ist keiner vorhanden, kann die Zeile nur über die Gesamtheit ihrer Spalten adressiert werden. Für Zeilen, die größer als 1KiB sind, kann phpMyAdmin allerdings keine URL für den Bearbeiten-Button generieren, da dies die maximale Länge einer URL sprengen würde. …

Primärschlüssel definiert und schon ließen sich wieder alle Einträge bearbeiten. Es kann manchmal so einfach sein …

Das BSI schreibt zu der Vorgehensweise:

Das DNS (Domain Name  System) ist einer der wichtigsten Dienste im Internet, welcher für die Umsetzung von Namen (URLs) in IP-Adressen verantwortlich ist. Im Falle einer Infektion mit der Schadsoftware leitet der Webbrowser die Benutzer bei Abfrage populärer Webseiten unbemerkt auf manipulierte Seiten der Kriminellen um, wo betrügerische Aktivitäten wie beispielsweise die
Verbreitung angeblicher Antivirensoftware, Klickbetrug oder nicht lizenzierter Medikamentenverkauf stattfinden. Zudem konnten die Kriminellen gezielt manipulierte Werbeeinblendungen an infizierte Rechner senden, Suchergebnisse manipulieren und weitere Schadsoftware nachladen.

Bereits im November wurden die Hintermänner des Botnetzwerkes gefasst, die bestehenden Infektionen sind aber nach wie vor aktiv. Die Server des Netzwerkes sollen im März 2012 abgeschaltet werden und danach würden betroffene Rechner keinen Zugang mehr zum Internet herstellen können, da die DNS-Einträge (ausgeliefert über die Server des Botnetzwerkes) nicht mehr zur Verfügung stehen.

Ob der eigene Rechner vom dem Trojaner betroffen ist, lässt sich über einen einfachen Aufruf testen. Das BSI hat dazu die Webseite

  www.dns-ok.de

geschaltet. Wer diese korrekt angezeigt bekommen, hat einen Rechner ohne Infektion. Für alle anderen gibt es beispielsweise hier Hinweise, wie man die Schadsoftware am einfachsten wieder entfernen kann.

http://blog.botfrei.de/2011/11/operation-ghost-klick-fbi-entlarvt-dnschanger-botnetz/

Bundesamt für Sicherheit in der
Informationstechnik (BSI)

Und da es bei WordPress fast alles auch per Plugin gibt, existieren natürlich auch Plugins, die Bewertungen usw. als Snippet im suchmaschinenfreundlichen Format darstellen können. Ohne Anspruch auf Vollständigkeit habe ich daher hier zwei Plugins die häufiger zum Einsatz kommen, aufgeführt:

GD Star Rating

GD Star Rating ist eigentlich dafür gedacht, die Benutzer über Beiträge abstimmen lassen zu können. Ist das Plugin aktiv wird zu jedem Artikel ein Abstimmfeld eingeblendet, das beispielsweise per Sternchen oder Schulnoten die Abstimmung ermöglicht. Auf Grundlage dieser Daten kann man beispielsweise auch die best benoteten Artikel anzeigen.

• http://wordpress.org/extend/plugins/gd-star-rating/

Seit Version 1.9.0 unterstützt das Plugin auch Microdata Formate und damit auch Google Rich Snippets.

Wer nach einer einfachen Möglichkeit sucht, Rich Snippets anzeigen zu lassen und das Plugin ohnehin im Einsatz hat, sollte von der zusätzlichen Möglichkeit die Daten google-freundlich darzustellen, Gebrauch machen. Für alle anderen kann dies auch sinnvoll sein, es könnte allerdings gerade bei älteren Beiträgen schwierig werden, wirklich aussagekräftige Bewertungen zu bekommen.

SEO Ultimate

SEO Ultimate war ursprünglich einmal als einfaches SEO-Plugin gestartet, mittlerweile hat das Plugin aber mehr als 20 Module, von denen eines auch speziell dafür zuständig ist, Rich Snippet Microformate auszuliefern.

Das Plugin generiert allerdings keine eigenen Daten sondern wandelt bloß bestehende Daten (beispielweise Artikel über Produkttests) in Rich Snippets. In erster Linie werden dabei Autor und Datum hinzugefügt, wenn das Plugin eine Bewertung findet (beispielsweise über eine Rating-Tool) wirde diese auch mit umgewandelt.

Etwas mehr dazu gibt es hier:

• http://www.seodesignsolutions.com/blog/wordpress-seo/seo-ultimate-3-0/
• http://wordpress.org/extend/plugins/seo-ultimate/

Um nicht warten zu müssen, ob die Plugins richtig gearbeitet haben und um zu prüfen, obGoogle auch versteht, das man nun Rich Snippet hat, kann man folgende URL nutzen. Dort findet sich das hauseigenen Rich-Snippet Testing Tool:

• http://www.google.com/webmasters/tools/richsnippets

Ich hatte bereits vor längerer Zeit mal beschrieben, wie man dieses Programm nutzen kann, um Werbeausgaben (wie beispielsweise Adwords Kosten) ein wenig zu senken und noch einen kleinen Bonus zu bekommen. Das Prinzip ist dabei relativ einfach: alle Adwords Ausgaben lassen sich natürlich auch per Kreditkarte bezahlen und generieren damit Membership Punkte die man irgendwann in nette Prämien eintauschen kann. Beispielsweise gibt es ab 5000 Punkten (entspricht einem Umsatz von 5000 Euro) einen Amazon Gutschein in Höhe von 25 Euro. Etwa ein halbes Prozent der Ausgaben bekäme man damit als Prämie zurück. Da die Amex Gold Karte aber selbst eine GEbühr von 140 Euro pro Jahr hat, lohnt sich dieses Modell nur bei größeresn Umsätzen.

Mein aktueller Favorit im Prämienshop ist das iPhone4 in weiß. Auch wenn es gerüchteweise bereits gegen Jahresende das iPhone5 geben soll ist das Modell immer noch unangefochten die Nummer Eins was die Smartphones betrifft. Bei Amex gibt es das iPhone4 derzeit für 131.000 Punkte (16GB Version) und 154.000 Punkte (32GB Version) im Rewards Programm. Das entspricht einem Umsatz von 131.000 bzw. 154.000 Euro. Keine kleine Summen aber wer über das Jahr bei Adwords einige Ausgaben generiert hat, kann sich eventuell über diesen kleinen Bonus freuen. Falls es nicht ganz zu diesen Punkten gereicht hat gibt es beide iPhone4 Modelle auch mit einer Zuzahlung von 299.00 Euro. Die notwendigen Punkte dafür sinken dann auf 75.009 bzw. 81.000 ab.

Die Fehlermeldung:

Das Verzeichnis /srv/www/…/wp-content/uploads/xxxxx kann nicht angelegt werden. Ist das übergeordnete Verzeichnis durch den Server beschreibbar?

WordPress hat in diesem Fall nicht das Problem die Datei hoch zu laden, sondern das Verzeichnis in das die Datei soll, kann nicht angelegt werden.

Liest sich erst mal wenig spektakulär und scheint mit den Zugriffsrechten zusammen zu hängen. Daher sollte man, wenn diese Fehlermeldung auftaucht auch als erstes schauen, ob das Uploads-Verzeichnis die korrekte Zugriffsrecht (777). Falls das nicht so ist könnte hier bereits der Fehler liegen.

Es gibt aber auch durchaus Fälle, in denen die Zugriffsrechte des Verzeichnisses korrekt gesetzt sind und diese Fehlermeldung trotzdem auftaucht. In diesem Fall kann es mit den Zugriffsbeschränkungen des Server zusammenhängen.

Viele Server (insbesondere vServer oder Webspace Pakete) sind miteiner Sicherheitsfunktion im php ausgestattet. Ist der sogenannte safe_mode aktiviert sind Zugriffe auf den Server nur eingeschränkt möglich. Insbesondere php Scripte können bestimmte Aktionen nicht mehr ausführen. Das sichert den Server gegen bestimmte Angriffsversuche ab, macht aber auch einige Funktionen nicht mehr möglich. Eine Übersicht über die Einschränkungen des safe_mode gibt es hier: safe_mode.

Eigentlich sollte WordPress diesen Fehler selbst abfangen. Zumindest ist im Upload Script eine entsprechende Weiche eingebaut:

if ( ini_get(‘safe_mode’) ) {
// Safe mode screws up mkdir(), so we must use a flat structure.
add_option(‘uploads_use_yearmonth_folders’, 0);
add_option(‘upload_path’, ‘wp-content‘);

Allerdings scheint dies nicht in jedem Fall korrekt zu arbeiten.

Ist der safe_mode aktiv kann er nur durch eine entsprechende Änderung in der php.ini abgeschaltet werden. Teilweise ist es auch in den Adminbereich von confixx oder Plesk möglich. Bei Plesk findet sich die Option beispielsweise in den Webhosting-Einstellungen:

Ist der safe_mode deaktiviert und die Zugriffsrechte richtig gesetzt dürfte die Fehlermeldung nicht mehr erscheinen. Falls man einen shared Websapce nutzt und dies nicht selbst machen kann hilft auch ein Nachfragen beim Hoster. Allerdings muss man natürlich selbst wissen ob es sinnvoll ist die safe_mode Option (die ja für mehr Sicherheit steht) zu deaktivieren oder ob man eventuell darauf verzichtet und die Verzeichnisse per Hand anlegt.

Erfreulicherweise gibt es aber die Möglichkeit, sich in WordPress ganz einfach selbst ein Amazon Werbemittel so zu gestalten, dass es zum Seiteninhalt passt. Hier ein kleines How-To.

1. Werbemittel Code generieren

Im Amazonpartnerbereich findet sich unter Widgets auch das Widget “Empfohlene Produktlinks”. Dort kann man einen Bereich und ein Keywort hinterlegen zu dem werbung eingeblendet werden soll. Die Erstellung des Codes ist dabei ganz einfach:

Welche Keywörter man an der Stelle hinterlegt ist egal, die Kategorie sollte aber in etwa zum Bereich passen zu dem man etwas schreiben möchte. Danach kann man noch die Größe bestimmen und erhält eine iFrame Code.

2. Den Code anpassen

Im Code für den iFrame ist ein Parameter search hinterlegt. Dort findet sich das Keywort das man bei der Erstellung eingegeben hat. Dieses Keywort ersetzt man nun durch den Code für die WordPress Tags: <?php the_tags(); ?>

Danach kann man den Code im Artikel-Template (single.php) einbinden und das Amazon Widget zeigt Werbung an die zu den Tags des Artikels passt. Mit der Vergabe der richtigen Tags kann man damit die Werbung gut steuern. Sehr konkrete Produkte als Tags bringen auch sehr konkrete Produkte in der Werbung und umgekehrt.

So ein Wechsel des Aussehens einer Webseite birgt jedoch auch einige Risiken. Viele Betreiber klagen nach einem Wechsel über kurz- oder auch längerfristige Einbrüche bei den Besucherzahlen, die meist darauf zurückzuführen sind, dass sich das Ranking in den Google Suchergebnissen verschlechtert hat.

Ein neues Theme bedeutet in der Regel auch, das sich die OnPage-Faktoren der Suchmaschinenoptimierung ändern – das hat natürlich auch Auswirkungen auf das Ranking der Seite. Daher sollte man vor einer größeren Umstellung des Designs einer Webseite das neue Theme auch auf die OnPage Optimierung prüfen und gegebenenfalls Änderungen vornehmen. Ein paar der wichigsten Bereich die man prüfen sollte habe ich nachfolgende aufgeführt.

Alles korrekt installiert?

Wenn die Benutzerzahlen wirklich massiv einbrechen kann das eine ganz einfach Ursache haben die man vorher dringend ausschließen sollte bevor man sich an alle anderen Maßnahmen macht: Ist der Trackingcode für die Statistik im neuen Theme auch bereits installiert und funktioniert er korrekt? Gerade bei Google Analytics vergessen Webmaster oft, den Code neu einzufügen weil er oft direkt über das alte Template angesteuert wurde und nicht in Quellcode hinterlegt war.

Seiten-Titel und Metaangaben

Ein neues Theme bringt in der Regel auch neue Header-Angaben mit sich bzw. werden die Headerangaben im Template auf jeden Fall verändert. Wer ein SEO-Plugin im Einsatz hat braucht sich an der Stelle weniger Gedanken zu machen, denn die Plugins überschreiben in der Regel die Einstellung des Themes. Trotzdem kann hier eine Kontrolle nicht schaden.

Wichtige Meta-Angaben eines Templates sind:

• Titel
• Description
• Canonical-URL

Um Auswirkungen auf die Serps zu vermeiden sollten diese Einstellungen im neuen Theme mit den Einstellungen im alten Template identisch sein.

Linkstruktur

Die interne Verlinkung ist ebenfalls ein wichtiger Faktor für das Ranking von Seiten. Ältere Seite werden darüber gefunden und mit den entsprechenden Linktexten verknüpft.

Beim neuen Theme sollte man darauf achten, dass eine ausreichende interne Verlinkung vorhanden ist und die alte interne Linkstruktur weitgehend nachgebildet wird. Das betrifft in erster Linie die Sidebar und den Footer. Oft werden diese Bereich mittlerweile per Widget oder internen Menüs angesteuert. Diese Ausgaben sollte man auch im neuen Theme einbinden um die Änderung so gering wir möglich zu halten.

Weiter Punkte für die intere Verlinkung ist die Pagination (also die Anzeige älterer Seiten in Listen wie der Startseite, Archivseiten usw.). Die Pagination sollte auf jeden Fall auch im neuen Theme vorhanden sein. Falls das Theme selbst keine Funktion dafür bietet kann man dies per Plugin nachbessern.

Gleiches gilt auch für weitere Bereich wie “Relatet Posts” (die ähnlichen Artikel) usw. Diese Features sollten, sofern sie bereits genutzt wurden, auch im neuen Theme vorhanden sein.

Überschriften und Unter-Überschriften

Die Kennzeichnung von Überschriften durch die h-Tags ist ein Faktor der von Google bei der Bewertung einer Seite beachtet wird. Das neue Theme sollte daher möglich wenig von der h-Struktur der alten Seite abweichen. Seitenüberschriften sollten im besten Fall h1 haben, Unterüberschriften h2-h4, je nach Wertigkeit. Der Umbau ist hier oft nicht ganz einfach das die Ausgaben durch die style-Dateien oft sehr theme-spezifisch sind. Im Zweifel sollte man sich immer für das Aussehen entscheiden und nicht ein h1 erzwingen obwohl man sich dadurch das Design kaputt macht.

Darüber hinaus wird der Wechsel eines Themes oft genutzt um auch andere (meist längst anstehende) Neuerung einzubauen. das geht von der Aktualisierung der WordPress Version über neue Plugins bis hin zu einer komplett neuen Permalink-Struktur. Ich kann von solchen Rundumschlägen nur abraten: Zu viele Faktoren machen eine Kontrolle der Auswirkungen sehr schwierig. Besser ist es die Maßnahmen einzeln und mit Abstand durchzuführen um bei negativen Auswirkungen die Änderngen auch wieder zurücknehmen zu können.

Der IE9 hat damit allerdings bei älteren Cunfo Javascripten seine Probleme. Im IE9 werden dann Schriften die mit Cufon ausgegeben werden gar nicht mehr angezeigt. Die Überschriften fehlen einfach. Das kann auch WordPress Templates betreffen, denn gerade bei den neueren Themes wird oft mit Cufon gearbeitet. Wer sich nicht sicher ist: Einfach in den Header-Bereich des Templates schauen ob dort eine cufon Javascript Datei aufgerufen wird.

Die Lösung ist relativ simpel: Auf den Seiten von Cufon steht bereits eine kompatible Javascript Version bereit die auch mit dem IE9 zusammen arbeitet. Einfach die neuste Version der cufon-yui.js herunterladen und an Stelle der alten Javascript Version auf der eigenen Webseite einfügen. Dann hat auch der IE9 nichts mehr zu meckern.

Zum Download:

• Webseite Cufon
• Direktlink Download

Schritte für einen korrekten WordPress-Umzug:

1. Datenbank sichern

Bevor man sich an einem Umzug macht sollte der aktuelle Stand der Datenbank unbedingt gesichert werden. Gibt es Probleme beim Backup oder geht etwas wirklich schief kann so immer noch der alte Stand wieder hergestellt werden. Viele Webspaces und Server bieten phpmyAdmin als Datenbank-Software gleich mit an, darüber können Blogs bis etwa 2 Megabyte Daten gesichert und wieder hergestellt werden. Für größere Backups empfiehlt sich eine externe Software wie zum Beispiel mySQLDumper. Wer das Plugin WordPress Database Backup installiert hat kann auch dieses verwenden.

Ein reiner Export der Artikel aus dem WordPress Backend heraus reicht im übrigen nicht aus. Die Einstellungen der Plugins und die Optionen werden so nicht gesichert.

2. Datein sichern und anpassen

Im einfachsten Fall sichert man einfach alle Dateien die in der WordPress Installation auf dem alten Server liegen. Wer dies nicht möcht kann aber auch nur die wichtigen Dateien vom Server nehmen.

Gesichert werden sollte dabei das gesamte wp-content Verzeichnis. Darin liegt nicht nur das Template sondern es enthält auch die Plugins und die Uploads (Bilder) die man in der Betriebszeit auf den Server geladen hat. Es reicht nicht aus nur das Template zu sichern, denn dann müßte man sämtliche Plugins neu installieren und die Artikelbilder (und auch die Thumbnails) wären auch weg. Auch wichtig: die wp-config.php (zu finden im Root Verzeichnis) enthält einige wichtige Informationen und sollte daher auch gesichert werden. Wurde eine eigene Permalink Struktur angelegt wird auch noch die Datei .htaccess benötigt.

Auf dem neuen Server lädt man entweder das komplette alte Verzeichnis hoch oder (wenn nur die individuellen Dateien gesichert wurden) spielt eine neue WordPress Installation auf und ersetzt die htaccess Datei und das wp-content Verzeichnis durch die alten Dateirn.

Die wp-config.php sollte mit den neuen Zugriffsdaten auf die neuen Datenbank ausgestattet werden. Danach kann auch sie auf den Server geladen werden.

// ** MySQL settings ** //
define('DB_NAME', 'putyourdbnamehere'); // The name of the database
define('DB_USER', 'usernamehere'); // Your MySQL username
define('DB_PASSWORD', 'yourpasswordhere'); // ...and password
define('DB_HOST', 'localhost'); // 99% chance you won't need to change this value

Die Settings sind dabei mit den alten Zugriffsdaten für die alte Datenbank ausgefüllt, sie mssen durch die neuen Zugriffsdaten ersetzt werden.

3. Datenbank anpassen und überspielen

WordPress hinterlegt die Daten für die Domain auf der der Blog läuft in der Datenbank (wp_options), daher muss dieses Feld angepasst werden, damit WordPress die neuen Installation auf dem neuen Blog findet. Am einfachsten geht dies, wenn man in der alten Installation die Daten auf die neue URL ändert und danach eine neue Kopie der Datenbank sichert. Die Domain wird dabei 2 mal festgelegt (in den Feldern siteurl und home), in beiden Feldern muss die neue Domain eingetragen werden. Die neue Kopie der Datenbank wird dann auf den neuen Server gespielt, auch hier kann bei großen Dateien wieder mySQLDumper zum Einsatz kommen.

Wer sich gut mit Datenbanken auskennt kann die Daten auch direkt in der Datenbank oder im sql-File ändern.

4. Fertig

Das wars. Mehr ist an sich nicht notwendig und der Blog sollte jetzt bereits laufen. Im besten Fall wurden alle Optionen/Einstellungen übernommen. Wer den alten Blog weiterlaufen lassen möchte sollte das erste Backup der Datenbank auf den alten Server spielen, denn durch die Änderung der URL funktioniert der alte Blog nicht mehr.

Fehler & Probleme beim WordPress und neuen Domains

Mod_Rewrite und der 500 Fehler

Manchmal kann der neue Server keine htaccess-Datein lesen, weil der Server kein mod_rewrite Modul hat. Dann gibt es beim Aufruf der Artikel eine Fehlermeldung (meist internal Error 500). Unter Einstellungen/Permalinks kann man dies deaktivieren, lassen sich die Beiträge dann normal aufrufen muss man mod_rewrite aktivieren.

.htaccess-Fehler

Oft sind in der alten .htaccess-Datei noch feste Verlinkungen auf die alte Domain vorhanden die irgendwann mal manuell hinterlegt wurden. Diese funktionieren natürlich nicht mehr für die neue Domain daher sollten sie schnell angepasst werden.

Umlaute sehen merkwürdig aus

Das passiert häufig wenn beim Backup ein falsches charset (Sprachcode) verwendet wurde. In dem Fall einfach ein wenig mit den möglichen Varianten (latin, UTF 8 usw.) experimentieren (Download mit einem anderen Charset der alten Version) bis es passt. WordPress hat meist UTF-8 voreingestellt, es kann aber auch sein, das für einige Tabellen der Datenbank andere charsets voreingestellt sind. Auf bueltge.de gibt es für fortgeschrittene Anwender auch ein Script mit dem man die Umlaute direkt in der DB korrgieren kann.

• http://blogs-optimieren.de/?p=123

Unter Einstellungen/Permalinks kann man in Worpress dies korrigieren und zum Beispiel den Titel oder die Kategorie des Beitrages als URL anzeigen lassen. Dies funktioniert aber nur wenn das mod_rewrite Modul des Servers aktiviert ist. Einige Webspaces bieten dies nicht an und so kann man entweder die schlecht optimierten Standard-URLS verwenden oder auf einen Tipp zurückgreifen, der sich in den englischen WordPress-FAQ findet.

Dazu reicht es, vor die eigentlichen umgeschriebenen Permalinks eine index.php zu setzen.

Soll zum Beispiel der Name des Beitrags erscheinen muss unter Einstellungen/Permalinks im Feld benutzerdefiniert folgende Struktur angegeben werden:

/index.php/%postname%/

für Datum und Name entsprechend:

/index.php/%year%/%monthnum%/%day%/%postname%/

Durch die vorangehende index.php werden die Beiträge automatisch zugeordnet, eine .htaccess Datei ist nicht notwendig.

Eigentlich passt es weniger zum Thema, da es aber doch ab und an mal gebraucht wird, hier die originalen Anweisungen aus der Standard-htaccess-Datei von WordPress:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

Häufig passiert es nach dem Umzug eines Blogs auf einen neuen Webspace, dass statt der Anzeige des Blogs ein Internal Error 500 ausgegeben wird. Das kommt häufig von fehlender oder nicht richtig konfigurierter mod_rewrite Unterstützung. Man kann in den Fällenden Provider bitten diese zu aktivieren oder aber auf die oben genannte Variante ohne mod-Rewrite zurückgreifen.

Die Installation ist dabei recht einfach und erfolgt unter Debian, Ubuntu und OpenSUSE mehr oder weniger automatisch. Dazu sind keine besonderen Systemkenntnisse notwendig sondern es reicht per Konsole auf den Server zuzugreifen:

• Debian, Ubuntu apt-get install chkrootkit
• OpenSUSE chkrootkit

Danach kann man das Programm durch den Aufruf chkrootkit starten. Die einzelnen Hinweise sollte man sorgfältig prüfen und nach eventuellen Infektionen suchen. Strato hat ein nettes Beispiel für einen kompromittierten Server mitgeliefert:

Checking ifconfig… INFECTED
Checking pstree… INFECTED
Searching for t0rns v8 defaults… Possible t0rn v8 \(or variation\) rootkit installed
Searching for Showtee… Warning: Possible Showtee Rootkit installed
Checking bindshell… INFECTED (PORTS:  465)
chkproc: Warning: Possible LKM Trojan installed
Checking bindshell… INFECTED (PORTS:  465)
Checking chkutmp…  The tty of the following user process(es) were not found
in /var/run/utmp !
! RUID          PID TTY    CMD
! root        15781 pts/0  -bash

Falls der Server so heftig infiziert wird hilft wohl nur eine komplette Neuinstallation des Systems sowie danach ein Schließen der aktuellen Sicherheitslücken in dem man die Plesk und ProFTP Programme auf die neusten Versionen updatet.

Für WordPress-Nutzer gibt es bereits ein neues Plugin mit dem sich jetzt schon beispielsweise Sendezeiten umsetzen lassen. Eine erste Version des Plugins steht hier zum Download bereit: JMSTV Plugin. Das Plugin filtert deutsche IP Adressen heraus und liefert für diese IPs außerhalb der definierten Sendezeiten nicht die normale Webseite sondern eine Textseite auf die wahlweise gestaltet werden kann. Die Standard Version der Testseite gefällt mir aber schon mal ganz gut.

Unabhängig von diesem Plugin sollten sich Webmaster auf jeden Fall auf die neuen Regelungen ab 1.1.2010 vorbereiten und ihre Seiten dahingehend überprüfen ob Inhalte ausgeliefert werden die nach den neuen Regeln eine Kennzeichnung nötig machen. Das kann im übrigen schon ab einer Einblendung von Videos notwendig werden, genauere Richtlinien wann welche Altersstufe greift gibt es aber nicht. Das ist auch einer der größten Kritikpunkte an der Neuregelung.

Erste Webseiten haben wegen der Neureglung bereits angekündigt zu schließen. Darunter sind auch bekanntere Projekte wie etwa das VZlog

Zum kostenlose Icon-Set:
http://www.wpzoom.com/wpzoom/new-freebie-wpzoom-developer-icon-set-154-free-icons/

Interessant ist in diesem Zusammenhang der Test der Online-Solution-Group. Dort wurden explizit zwei WordPress-Systeme getestet und dazu ein osCommerce Shopsystem. Während bei osCommerce die Geschwindigkeit tatsächlich spürbar verbessert wurde gab es bei den WordPress-Systemen kaum eine Veränderung. Im Gegenteil, hier waren die Seiten nach dem Aktivieren des Moduls sogar geringfügig langsamer als vorher. Für WordPress gibt es allerdings bereits eine Reihe von Plugins die Caching und andere Funktionieren optimieren. Es ist also durchaus möglich, dass auch die Ergebnisse von WordPress-Installation zu WordPress-Installation unterschiedlich ausfallen können. Daher kann auch an dieser Stelle ein wenig Testen nicht verkehrt sein und ich würde mich dem Fazit von Markus anschließen:

Als Fazit kann man jedenfalls sagen, dass es nach momentanem Wissensstand durchaus einen Versuch wert ist. Wenn wie im Falle der OsCommerce-Website mit nur 15 Minuten Arbeit satte 44% Ladezeit eingespart werden können, ist das beeindruckend. Und wenn hingegen wie im Fall der beiden WordPress-Websites zumindest keine deutlich spürbare Verschlechterung eintritt, kann man es immerhin als kleine praktische Übung sehen und das Plugin sehr einfach wieder deaktivieren und deinstallieren.

Im normalen Plesk gab es für solche Fälle einen Button namens “Limits” mit dem man das Ablaufdatum der Domains steuern konnte. Im Normalfall war es im bisherigen Plesk auch auf unbegrenzt gesetzt. Unter Parallels Plesk finden sich die Limits nun unter dem Button “Resource Usage” oder “Ressourcennutzung” (im Unterbereich Statistics). Das Icon dazu sieht eher aus wie ein Traffic-Monitor, dass man unter diesem Button auch so elementare Sachen wie die Ablaufzeit einer Domain verwalten kann ist nicht sofort ersichtlich. Keine Ahnung warum diese Änderung eingeführt wurde aber wirklich userfreundlich ist sie nicht.

Dazu scheint Parallels Plesk mit anderen Voreinstellungen zu arbeiten. Alle Domains waren mit einer Laufzeit von nur einem Jahr angemeldet. In den nächsten Monaten wären also auch noch andere Domains automatisch deaktiviert worden. Ein Nachricht dazu gab es im Übrigen nicht.

Wer also auch mit Parallels Plesk arbeitet sollte prüfen ob seine Domains eventuell auch mit einem Ablaufdatum angemeldet worden sind. Falls ja würde ich empfahlen das Datum auf “unbegrenzt” zu setzen um solche Probleme für die Zukunft auszuschließen.

Zum Auffinden des Buttons:

- Domains anwählen

- die entsprechende Domain anklicken

- unter Statistik den Button Ressource Ussage

- letzter Eintrag ist die Domaingültigkeit

Google spricht davon das im besten Fall die Ladezeiten halbiert werden könnten:

Das Modul ist nur für Server auf Apache Basis erhältlich und steht hier zum Download bereit: http://code.google.com/intl/de/speed/page-speed/download.html

Google versucht schon seit geraumer Zeit die Geschwindigkeit von Webseiten zu erhöhen. Ein erster Schritt dazu war die Anzeige der Ladezeit (samt Verbesserungsvorschlägen) in den Google Webmastertools, danach wurde die Ladezeit von Webseiten ins Ranking mit aufgenommen. Das neue Modul greift nun eine Reihe von Verbesserungsvorschlägen auf und erleichtert die Umsetzung.

Laut Google ist die Ladezeit einer Webseite ein wichtiger Faktor bei der Bewertung durch die User. Langsame Webseiten werden als störend empfunden und eher abgelehnt. Ein schneller Seitenaufbau dagegen sorgt für ein positives Surfergebnis.

Schwieriger wird es, wenn die kompromittierte Seite lange genug online war um in den Filtern von Stopbadware.org zu laden. Dann ist sie nämlich sowohl für Firefox User als auch über die Google Suche nur noch erreichbar wenn die Nutzer Warnhinweise ignorieren. Das passiert aber nur sehr selten weshalb der Traffic in einem solchen Fall sehr schnell sehr stark einbricht. Das kann gerade bei gewerblichen Projekten zu massiven Umsatzeinbrüchen führen, Beispiele dafür sind bereits bekannt.

Der Firefox gibt bei den Aufruf einer solchen Seite die Warnung “Als attackierend gemeldete Webseite!” aus, in der Google Suche wird das Suchergebnis mit “Diese Website ist als verdächtig eingestuft. Das Aufrufen dieser Website kann schädlich für Ihren Computer sein!” gekennzeichnet. Dazu wird eine Mail an die bekannteren Adressen der Domain geschickt um auf den Vorfall und die Sperrung aufmerksam zu machen.

Als Webmaster sollte man in einem solchen Fall schnell handeln. An erster Stelle ist es wichtig, die Webseite zu säubern und wie oben beschreiben abzusichern:

• FTP-Daten ändern
• CMS auf den neusten Stand bringen, eventuell auch die Serversoftware updaten
• sauberes Backup aufspielen (falls keins vorhanden ist: meistens werden die index-Dateien und die Javascript Dateien infiziert. Bei kleiner Webauftritten kann man die Schadcodes dort auch per Hand löschen.)
• Die Seite mit aktiviertem Virenscanner prüfen ob nichts übersehen wurde

Falls der Angriff genutzt wurde um eine Typ der Gumblar Viren zu verteilen ist auch dieses Tool hilfreich um den Virus recht schnell wieder zu entfernen: Curevir

Ist die Seite in den Google Webmastertools angemeldet, kann recht schnell eine erneute Überprüfung beantragt werden. Dazu einfach in dem WMT die entsprechende Seite anwählen unter und Diagnose den Punkt Malware aufrufen. Dort finden sich Details zur Infizierung der Webseite sowie ein Link mit der sich die erneute Prüfung der Webseite anstoßen lässt.

Falls die Webseite noch nicht in den Webmaster Tools hinterlegt ist, lässt sich auch direkt bei Stopbadware.org eine neue Prüfung der Seite beantragen. Dazu gibt es ausführliche Hinweise unter http://stopbadware.org/home/reviewinfo. Dazu muss man die eigene Seite in der Liste (hier) der gemeldeten Seiten finden. In den Details gibt es dann den Button “Request an independent review” mit dem man die Seite ernaut prüfen lassen kann.

Egal ob bei Google oder direkt bei Stopbadware: in beiden Fällen sollte man sicher stellen, dass wirklich kein Schadcode mehr ausgliefert wird, sonst werden auch die Warnhinweise nicht entfernt.

Verantwortlich für die Ausgabe der Bilder im Text ist folgende Angabe in der style.css des TwentyTen-Themes:

#content img {
margin: 0;
height: auto;
max-width: 640px;
width: auto;}

Sowohl für die Breite als auch für die Höhe ist eine automatische Angabe hinterlegt. Das Theme passt die Größe der Bilder im Blog automatisch an, unabhängig welche Größe dafür unsprünglich hinterlegt ist. Im Editor selbst wird diese Anweisung nicht verwendet, da hier die style.css nicht geladen wird.

Entfernt man die Auto-Angaben aus dem css-Eintrag löst sich das Skalierungsproblem und die Bilder werden auch im Frontend in der richtigen Größe angezeigt.

Der Fehler ist deswegen so ärgerlich weil das neue Standard-Theme den Einsatz noch einfacher machen sollte und daher für Einsteiger im WordPress Bereich gedacht war die schnell und einfach einen Blog aufsetzen wollen. Es ist aber nicht zu erwarten, dass ein WordPress-Anfänger dieses Problem alleine lösen kann. Bleibt zu hoffen, dass mit dem nächsten Update von WordPress auch dieser kleine Bug mit gefixt wird.

in der Regel reicht es allerdings, auf automatische Antispamsysteme zu setzen. Das bereits bei jeder WordPress-Installation enthaltene Akismet oder Antispambee leisten als Plugins gegen die Spamflut gute Arbeit und erfordern nur selten ein manuelles Eingreifen. Nur in Ausnahmefällen ist es daher wirklich notwendig auf die Blacklist-Systeme von WordPress zurückzugreifen.

So ein Ausnahmefall kann beispielsweise eintreten wenn wieder einmal ein SEO-Wettbewerb zu einem erfundenen Keywort (Revierphone?) gestartet wurden. Dann fallen Scharen von SEOs über Follow-Blogs her um manuell ihre Kommentare samt Keywortverlinkung unterzubringen. Gegen diesen manuellen Spam sind die Plugins meistens machtlos. Blacklists dagegen können nützlich sein, denn es reicht einfach das problematische Keywort auf die Blacklist zu setzen und schon werden Kommentare mit diesem Begriff einfach ausgefiltert. Dabei spielt es keine Rolle, wo der Begriff auftaucht. WordPress findet die Keywörter sowohl im Inhalt, im Namen, in der URL oder auch in der E-Mail-Adresse. Sogar IPs kann man so sperren, denn auch die IPs werden auf Blacklisteinträge überwacht.

Die Blacklists in WordPress finden sich unter Einstellungen – Diskussionen. Dort gibt es zwei große Felder mit den Titeln Kommentarmoderation und Kommentar-Blacklist. Kommentare mit Wörtern die auf der Kommentar-Blacklist zu finden sind werden sofort verworfen. Kommentare die Keywörter von der Kommentarmoderations-Liste enthalten werden dagegen nicht freigeschaltet sondern in die Warteschlange gelegt. Erst wenn der Blogbesitzer diese freischaltet werden sie angezeigt.

Für den englischsprachigen Raum gibt es im Übrigen bereits eine Vorlage für eine Blacklist mit der die häufigsten Spamkommentare ausgesiebt werden. Die Liste kann hier kopiert werden. Allerdings nützt diese Zusammenstellung natürlich nichts gegen Kommentare auf russisch oder anderen Sprachen.

Der Workaround zur Fehlerbehebung war eher quick and dirty: Ich habe die bestehende Application gelöscht und eine neue angelegt. Damit funktionierte das Posten der Beiträge wieder, weswegen es mit der vorigen App nicht geklappt hat weiß ich aber immer noch nicht.