Mein erster Verdacht fiel auf das Cache-Plugin. Damit hatte ich schon öfter Probleme gehabt und das Plugin fügt auch selbstständig Einträge in die .htaccess ein, was fehlerhafte Redirects erklären könnte. Leider gab es auch nach dem Deaktivieren des Cache-Plugins, dem Leeren des Cache und einer neuen, jungfräulichen .htaccess Datei keine Besserung.

Nach einigem Suchen stellte sich dann das Multipage-Plugin als Übeltäter heraus. Das Plugin sollte eigentlich nur eine einfache Möglichkeit bieten, Artikel über mehrere Seiten zu verteilen und bietet beispielsweise die Möglichkeit einfache Menüstrukturen mit einzubinden. Das Plugin ist schon etwas älter und findet sich hier. Im Plugin Verzeichnis ist es auch nur als kompatibel bis WP 2.6.1 ausgeschrieben, eventuell hätte ich doch genauer darauf achten sollen. Nach der Deaktivierung funktionierten die Kategorien- und Tag-Links auf jeden Fall wieder wie gewohnt. Falls also jemand dieses Plugin auch im Einsatz haben sollte: Einfach mal die Links checken, eventuell gibt es die Probleme ja nicht nur bei mir.

Multi-page Toolkit

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.

Falls es noch irgendwo fehlende Grafiken oder tote Links gibt – bitte einfach hier melden, ich kümmere mich so schnell wie möglich darum.

Eine englischsprachige Nachfolgeversion die ohne diese Lücke auskommt steht mittlerweile zu Download zu Verfügung (in englisch). Die deutsche Version dafür gibt es (noch) nicht, es ist aber zu erwarten, dass diese schnell nachgereicht wird. Wer die 2.8.1 nutzt sollte auf jeden Fall den Upgrade auf 2.8.2 durchführen um es eventuellen Angreifern nicht zu einfach zu machen. Mit dem mittlerweile funktionieren automatischen Upgrade sollte das ja kein Probleme sein.

CMS die RSS-Feeds anbieten (unter anderem auch WordPress) sind aber besonders anfällig, da sie den Content über den Feed besonders leicht für andere Seiten zur Verfügung stellen. Es gibt mittlerweile Plugins, die automatisch fremde Feeds auslesen und den Content samt Backlink im eigenen Blog (meist mit Backlink, oft aber auch ohne) posten.

Das ist nicht nur ärgerlich sondern kann in suchmaschinentechnischer Hinsicht ernste Probleme verursachen. Google indexiert zwar von mehreren identischen Texten nur die Version, die als Original eingestuft wird. Oft wird aber der geklaute Content aber nicht als identisch erkannt, da er zum Beispiel mit anderen Inhalten auf einer Seite präsentiert wird. Dann rankt Google möglicherweise die geklaute Version vor dem eigentlichen Original (die Keywords sind ja die selben) und der Traffic kommt beim Content-Dieb an.

Die Abwehr solche Content-Diebe ist nicht unbedingt einfach. Der beste Schutz ist immer noch zu verhindern, dass Content in fremden Seiten auftaucht.

Feeds entschärfen

Standardmäßig werden Artikel im Volltext von WordPress als Feed zur Verfügung gestellt. Dies ist praktisch für Feedleser, erleichtert aber automatisches Lese-Plugins die Arbeit extrem. Daher ist es sinnvoll den Feed auf die verkürzte Version zu reduzieren (entspricht bei WordPress the_excerpt()). Damit werden nur die ersten 150 Zeichen oder die optionale Kurzfassung als Feed zur Verfügung gestellt. Diese können zwar immer noch kopiert und ausgelesen werden, der Schaden ist dann aber wesentlich geringer da der volle Artikel nur im eigenen Blog steht.

IPs sperren

Wurden bereits einige Texte geklaut und kennt man den Verursacher, kann man die eigene Webseite gegen Zugriffe des Diebs absichern. Damit kann der betreffenden Server/Blog den eigenen Feed nicht mehr automatisch auslesen.

Dazu muss die IP des Servers bekannt sein, diese kann man dann einfach per .htaccess aussperren.

In der Datei .htaccess im Hautpverzeichnis folgenden Eintrag hinzufügen:

• #Spammer aussperren
  order allow,deny
  allow from all
  deny from hier IP eintragen

Alle Zugriffe von dieser IP werden dann automatisch abgewiesen.

Alternativ kann man auch auf System wie Bot-Trap setzen. Hier wird mit einer immer aktualisierten Liste von IP gearbeitet die bekannte Schädlingsbots aussperren.

Falls man diese Mechanismen noch nicht im Blog hat, kann es sein, dass bereits Texte an anderer Stelle veröffentlich wurden. Daher ist es auch wichtig, eventuell gestohlenen Content im Internet schnell zu finden. Zu diesem Zweck existieren Suchmaschinen die sich genau darauf spezialisiert haben. Mit Copyscape (online) und Plagiarism-Finder (download) kann man das Internet nach gleichlautenden Texten absuchen. Copyscape bietet zur Abschreckung zusätzlich einen Buttonsatz mit einem Warnhinweis. Professionelle Contentdiebe werden sich davon aber eher nicht abschrecken lassen.

Frank Bueltge hat ein Plugin veröffentlicht, dass jedem Feed-Eintrag einen individuelle ID anhängt. Wie ein Fingerabruck kann diese ID im Internet gesucht werden um geklaute Texte leichter zu identifizieren.

Damit kann man dann auch Content finden, der auf manuelle Weise (per Copy+Paste) geklaut wurde.

Gefundene Seiten kann man wie weiter oben schon beschrieben per .htaccess ausschließen, man kann aber auch rechtliche Schritte einleiten. Dann sollten aber wenigstens Screenshots abgespeichert werden um Beweise in der Hand zu halten. Einfach als der rechtliche Weg ist der Weg über Google. Über einen DMCA-Antrag (Digital Millennium Copyright Act) kann man Google über einen vorliegende Urheberechtsverletzung informieren. Google reagiert dann meistens relativ schnell und nimmt die betreffende Seite aus dem Index bzw ersetzt sie durch das Original.

Wenn man die Adresse/Kontaktdaten des Webseitenbetreibers hat, kann man (und sollte man) natürlich den Kontakt suchen. Vielfach steckt kein böser Wille hinter der Kopie und man kann mit einer Mail das Problem beheben oder zumindest einen Backlink bekommen. Das spart Zeit und Nerven.

Weiterführende Links:

• Spam und Bot Schutz
• Diebstahlschutz
• Attributor
• Contenklau verhindern

Dieser Artikel wurde im Original am 23.12.2007 verfasst und am 1.9.2008 aktualisiert und ausgebaut.