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

Beispielsweise wurde die Webseite des Bundestagsabgeordneten Jens Spahn (CDU) mit einem fremden Artikel versehen. Dort lief ein WordPress System mit der Version 3.2.1 für das es leider schon einige Exploits gab (siehe beispielsweise hier und hier). Ebenfalls angegriffen wurde die Seiten von Silvana Koch-Mehrin (Mitglied des Europaparlamentes) die sogar noch mit einer alten WordPress 2.8.4 lief, ich spare mit an dieser Stelle, die möglichen Sicherheitslücke aufzuzählen.

Überhaupt finden sich in er Liste sehr viele Seiten die WordPress nutzen. Von hoffnungslos veralteten Installationen bis hin zu WordPress 3.3 Systemen ist alles dabei.

Leider werden nur selten Details angegeben, welche Lücke genau genutzt wurde. Von daher ist es nicht sicher, ob tatsächlich Sicherheitsprobleme bei WordPress zu den erfolgreichen Angriffen geführt haben, oder ob es andere Systeme waren, die genutzt wurden. Beispielsweise hat die TimThumb-Lücke Mitte dieses Jahres gezeigt, dass es nicht immer der Core sein muss, der Angriffsfläche bietet.

Auf jeden Fall sollte es sich mittlerweile herumgesprochen haben, dass Sicherheitslücken bei Wordpres sehr schnell aktiv ausgenutzt werden. Ein Versionupdate ist daher in jedem Fall Pflicht sobald neue Versionen mit Bugfixes für Sicherheitslücken erscheinen. Die 1-Klick Installation der neuen Updates ermöglicht es auch wenig versierten Nutzern, neue Versionen schnell zu installieren – eine Ausrede gibt es daher nicht. Darüber hinaus hilft es natürlich, die Tipps zur Absicherung einer WordPress Installation zu beachten. Einen 100%igen Schutz gibt es aber wohl leider nicht. Gerade komplett neue Versionen bieten oft auch komplett neue Exploits, da hilft nur selbst wachsam bleiben und eine schnelle Reaktion, sobald Fixes vorhanden sind. Ein Exploit Scanner oder ein Antivirus Programm für die eigenen Seite kann dazu helfen

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

Auch die statistischen Angabenn im dazugehörigen Artikel sind recht interessant. Beispielsweise wurden WordPress 3.2. in den ersten beiden Tagen 500.000 Mal herunter geladen und von 100 aktiven Domains in den USA nutzt jeden 5.Seite WordPress.

Leider scheinen die üblichen Verdächtigen für so einen Fall seit WP 3.2 nicht mehr zu funktionieren. Bislang gibt es dafür auch noch keine Updates so dass die Plugins zumindest mit der neusten WordPress Version den Dienst verweigern. Kennt jemand eine Lösung, die auch mit WP 3.2 funktioniert – sei es ein Plugin oder eine Scriptlösung um die normalen Editor auch für das Textfeld der Kommentare zu nutzen?

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.

Die wichtigste Änderung ist wohl ein Problem mit den Nutzerrechten, das mit WordPress 3.1.2 gefixt wird. Mitarbeiter konnten damit unter Umständen Artikel veröffentlichen obwohl sie dazu an sich keinerlei Rechte haben sollte. Mitarbeiter können zwar Texte verfassen, dieser aber nicht direkt veröffentlichen sondern nur zur Revision vorlegen. Dann kann ein anderer Nutzer mit den entsprechenden Rechten diese freischalten. Erst dann wären die Artikel im Blog sichtbar.

Daneben wurde noch einige weitere Probleme gefixt. Perun schreibt dabei von 9 Problemen, im Tracker konnte ich allerdings nur 4 entdecken und auch laut Meldung von WordPress selbst gab es nur 4 neue Fixes. Allerdings ist die zahl auch eher nebensächlich, das neue Updaten sollte auf jeden Fall jeder einspielen der WordPress in den neueren Versionen nutzt.

Die geänderten Files:

• wp-includes/post-template.php

• wp-includes/version.php

• wp-includes/user.php

• wp-includes/query.php

• readme.html

• wp-admin/includes/class-wp-posts-list-table.php

• wp-admin/includes/update-core.php

• wp-admin/press-this.php
  

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.

Das betreffende Theme hört auf den Namen “The Avatar Movie WordPress Theme Template” und steht hier zum kostenlosen Download bereit. Bevor jetzt aber die ersten den Link anklicken und das Theme downloaden bitte erst noch weiter lesen.

Rechtliches

Gerade bei solchen Film- oder Spiel-Templates habe ich immer etwas Bauchschmerzen. Der Macher des Templates mag des Theme zwar kostenlos anbieten, das heißt aber nicht, dass er auch für alle verwendeten Grafiken das Recht hat diese weiter zu verteilen. Bei Avatar kann ich mir vorstellen, dass auf den Charakteren und dem Logo (das auch im Template auftaucht) Schutzrechte liegen, die wahrscheinlich vom Studio oder den Produzenten gehalten werden. Wer das Template einsetzt könnte es also im schlechtesten Fall direkt mit einer Rechtsabteilung der Produktionsfirma zu tun bekommen. Wirklich checken lässt sich im Vorfeld auch nicht welche Grafiken verwendet werden dürfen. Mir persönlich wäre der Einsatz damit zu risikoreich.

Ein zweiter Punkt sind die verwendeten Lizenzen:

“This work is under Creative Commons Attribution-Share Alike 3.0 License, This means you may use it and make any changes you like, However, credit links must remain on footer for legal use, Please Share This Article if You like it.”

Das Werk steht unter einer CC BY SA Lizenzen. Zwar darf der Lizenzgeber bestimmen, wie die Namensnennung zu erfolgen hat, eine Link zu einer anderen Seite als der Lizenzseite darf aber nicht vorgeschrieben werden. Dazu bestehen die Links im Footer nicht nur aus einem Link:

<a href="http://www.free-wordpress-theme.net">Avatar by Vee</a>
designed by
<a href="http://www.screensleuth.com/">Buy TV</a>.
Code by
<a href="http://mmohut.com/">Free MMORPG</a> |
<a href="http://cheapufctickets.net/">UFC Tickets</a> |
<a href="http://www.exportimportusa.net/">USA Export Import</a>.<br />
Downloaded From <a href="http://www.template4all.com/wordpress/" title="Free WordPress Themes" target="_blank">Free WordPress Themes</a> | <a href="http://www.freethemes4all.com/" title="Free Website Templates" target="_blank">Free Website Templates</a> | <a href="http://www.bestnewslinks.info" title="News Magazines" target="_blank">News Magazines</a>

(aus der footer.php)

Insgesamt 8 Link werden hier verbraten, teilweise extrem themenfremd. Nicht nur im Bereich der Lizenz würde ich hier ein Problem sehen, wer solche Linkblöcke im Footer stehen lässt schreit faktisch um eine Abstrafung wegen gekaufter Links.

In Sachen Sicherheit

Ein kleiner Blick in die functions.php offenbart, dass hier mit interessanten Methoden gearbeitet wird:

eval(str_rot13('shapgvba purpx_sbbgre(){
$y=\'Ningne ol Irr
qrfvtarq ol
Ohl GI.
Pbqr ol
Serr ZZBECT |
HSP Gvpxrgf |
HFN Rkcbeg Vzcbeg. \';
$s=qveanzr(__SVYR__).\'/sbbgre.cuc\';$sq=sbcra($s,\'e\');
$p=sernq($sq,svyrfvmr($s));spybfr($sq);
vs(fgecbf($p,$y)==0){rpub \'Guvf gurzr vf eryrnfrq haqre perngvir pbzzbaf yvprapr, nyy yvaxf va gur sbbgre fubhyq erznva vagnpg\';qvr;}}purpx_sbbgre();'))

Das ganze sieht nach einer Rotation von versteckten Links aus, die irgendwo im Block auftauchen werden. Am Ende der Datei kommt dann noch ein weiterer verschlüsselter Code:

eval(str_rot13('shapgvba purpx_s_sbbgre(){vs(!(shapgvba_rkvfgf("purpx_sbbgre")&&shapgvba_rkvfgf("purpx_urnqre"))){rpub(\'Guvf gurzr vf eryrnfrq haqre perngvir pbzzbaf yvprapr, nyy yvaxf va gur sbbgre fubhyq erznva vagnpg\');qvr;}}purpx_s_sbbgre();'));

Den gleichen Code findet man auch in der header.php:

eval(str_rot13(‘shapgvba purpx_s_sbbgre(){vs(!(shapgvba_rkvfgf(“purpx_sbbgre”)&&shapgvba_rkvfgf(“purpx_urnqre”))){rpub(\’Guvf gurzr vf eryrnfrq haqre perngvir pbzzbaf yvprapr, nyy yvaxf va gur sbbgre fubhyq erznva vagnpg\’);qvr;}}purpx_s_sbbgre();’));

Bei solchen Codeblöcken habe ich immer massive Bauchschmerzen. man weiß nie, was genau da im Blog gemacht wird und es besteht durchaus die Möglichkeit, dass hier auch noch Datein nachgeladen werden, man also dem Macher einen einfachen Zugriff auf den eigenen Blog gibt.

Daher mein Rat bei so was: Solche Zeilen am besten ganz entfernen und besser noch ganz die Finger weg von solchen Templates die nur dafür gebaut sind um Links zu verteilen.

Die deutsche Version des Updates sowie das Upgradepaket das nur die veränderten Dateien enthält sind hier erhältlich:
http://blog.wordpress-deutschland.org/2010/12/29/wordpress-3-0-4-de-edition-und-upgradepaket.html

• 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.

Wer sich nicht sicher ist kann unter Einstellungen › Schreiben › Fernpublizieren prüfen ob die XML-RPC-Schnittstelle aktiviert ist. Da Update gibt es wie immer unter wordpress-deutschland.org

Mehr dazu:

• http://wp-magazin.ch/2010/12/08/wordpress-3-0-3-erschienen/
• http://www.kalliey.de/wordpress-3-0-3-ist-da-sicherheitsluecke-wird-geschlossen/12/2010/
• http://www.schockwellenreiter.de/blog/2010/12/08/wordpress-3-0-3-ist-verfugbar/
• http://www.zweidoteins.de/wp/wordpress-3-0-3-ist-verfugbar-bitte-aktualisiere-per-fernpublizierung

Eine deutsche Version davon gibt es noch nicht aber wenn ich es richtig gesehen habe sind zumindest die geänderten Dateien ohnehin nicht sprachrelevant. Wer also nur die Änderungen hochlädt kann auch mit der englischen Version arbeiten.

Die Neuerungen von WordPress 3.1 in der Übersicht:

bessere interne Verlinkung

Beim Einfügen von Links über den Editor erscheint nun auch eine Suchmaske mit der man ältere Artikel suchen und einfach als Link einfügen kann

neue Adminbar für das Frontend

angemeldete Nutzer bekommen im Frontend eine Adminbar angezeigt die wichtige Funktionen zum Verwalten des Blogs enthält. Damit muss man nicht mehr ins Backend wechseln um bestimmte Aktionen vorzunehmen

sortierbare Spalten im Backend

bei der Verwaltung von Artikeln usw. im Backend sind die Spalten jetzt einfach per Mausklick sortierbar. So kann man schnell die Titel alphabetisch sortieren oder neuste bzw. älteste Artikel zuerst anzeigen lassen.

neue Formatvorlagen

Für die Veröffentlichung eines Artikels gibt es jetzt individuelle Formatvorlagen (Standard, Aside und Gallery). Diese können direkt im Template ausgelesen werden uns so für verschiedene Formatvorlagen andere Layouts ausgeben.

Daneben gibt es noch eine Reihe weiterer Änderungen die eher technischer Natur sind. So wurde der TinyMCE Editor auf die aktuelle Version 3.3.9.1 und das backend bekam eine überarbeitete CSS-Datein sowie eine verbesserte AJAX-Oberfläche.

Mehr dazu gibt es im WordPress Blog oder hier:

• Perun
• Golem
• wp-magazin

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.

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.

Wer genervt ist das schon wieder ein Update ansteht: die neue Version ist nicht sicherheitsrelevant und muss damit nicht zwangsläufig zeitnah aufgespielt werden. Man kann also auch etwas warten – auf der anderen Seite geht das automatische Upgrade ja mit einem (maximal 2 Mausklicks) und ist damit eigentlich auch nicht viel aufwendiger.

Noch ist allerdings die deutsche Version nicht erschienen, ich denke aber im Laufe des Tages wird auch sie zur Verfügung stehen.

WordPress Papierkorb

Mit WordPress 2.9 kam die neue Papierkorb-Funktion. Gelöschte Objekte wie Beiträge oder Kommentare werden damit nicht mehr direkt aus der Datenbank entfernt sondern erst in den Papierkorb verschoben um sie eventuell wieder herstellen zu können falls sich herausstellt, das sie doch noch benötigt werden. Nach 30 Tagen werden Objekte dann (standardmäßig) aus dem Papierkorb entfernt. Wem dieser Zeitraum zu lang oder zu kurz ist kann mit folgenden Eintrag diese Zeitspanne verändern:

define(‘EMPTY_TRASH_DAYS’, 10 ); (Objekte werden nach 10 Tagen aus dem Papierkorb gelöscht)

define(‘EMPTY_TRASH_DAYS’, 0 );

Mit der letzten Option kann man den Papierkorb mehr oder weniger ausschalten denn gelöschte Objekte werden dann sofort vernichtet. Ob das sinnvoll ist sollte jeder selbst entscheiden, denn ein falscher Klick ist schnell mal getan und dann ist die Wiederherstellung durchaus sinnvoll.

Datenbank Reparatur

Ein korrupte Tabelle in der Datenbank kann viele Fehler verursachen und wenn es zum Beispiel die Options-Table betrifft auch ein Login unmöglich machen. Abhilfe schafft ein direkter Zugriff auf die Datenbank und ein entsprechendes Repaid-Kommando. Wer darauf keinen Zugriff hat kann Worpress diese Funktion auch selbst ausführen lassen:

define('WP_ALLOW_REPAIR', true);

Damit führt WordPress auch ohne Login ins Backend den Repair Table Befehl aus der unter Umständen beschädigte Datenbanken wieder herstellen kann. Dieses Kommando sollte allerdings nur dann genutzt werden, wenn die Datenbank beschädigt ist. Im Normalfall hat dieser Befehl also nichts in der wp_config.php zu suchen.

Eine Übersicht über alle vorhandenen Befehle für die WordPress Config Datei gibt es hier.

Mittlerweile ist WordPress 3.0 aufgespielt. Das Update klappte direkt beim ersten Versuch, Zwischenschritte waren nicht notwendig und auch das Update der Datenbank klappte ohne Probleme. Kurz: ich bin begeistert.