Eine Änderung, die mit WP 2.6 eingeführt wurde machte nun offenbar im grösseren Stil Schwierigkeiten. Admins konnten sich nach einem brav und eigentlich korrekt nach “HowTo” eingespieltem Upgrade nicht mehr einloggen. Ein über mehre Seiten mit Hilfegesuchen gefüllter Foren-Thread von ausgeschlossenen Wordpress-Betreibern (“Upgraded to WP 2.6 and can’t access wp-admin area“) wurde schliesslich von den Moderatoren recht barsch geschlossen. Etliche Ratsuchende wurden nach meinem dafürhalten ohne eine Hilfestellung zurückgelassen, da der abschliessende Beitrag des Moderators keine Lösung nennt.

Was war passiert?
Mit dem Upgrade auf die 2.6 ist man dazu angehalten in die wp-config.php drei weitere Defines zur verbesserten Cookie-Sicherheit einzubauen.

Wer noch den Sticky Beitrag im Support-Forum HOWTO: Set up secret keys in WordPress 2.6+ gefunden hat, konnte sogar erfahren, dass man sich neu einloggen muss (okay, kann man auch von selbst drauf kommen).

Dies sowie der sonst noch häufig zu findende Hinweis, die Cookies zu löschen, nützen aber nichts, wenn man in der Config auch noch eine Define für den SECRET_KEY gesetzt hat (ich meine der wurde so um die v2.5 eingeführt. Wer also von einer Uralt-Version upgraded, wird das Teil ggf. nicht haben und somit von dem Problem verschont bleiben). Sobald aber die drei neuen Keys und der alte SECRET_KEY definiert sind ist man ausgeschlossen da alle Login-Versuche mit You do not have sufficient permissions to access this page bzw. Sie haben nicht ausreichend Rechte, um auf diese Seite zuzugreifen abgewiesen werde.

Es muss offenbar der ehemals gültige SECRET_KEY ab v2.6+ auskommentiert werden, damit es wieder mit dem Login klappt (zumdem muss man die alten Cookies ablöschen). Eine offizielle Erklärung bzw. Bestätigung habe ich beim lesen der Upgrade How-Tows nirgends gefunden; aber das scheint mir die einzig logische Erklärung. Wenn jemand eine andere Vorgesehensweise für dieses Problem hat bitte ich um einen Kommentar.

Wäre doch sinnvollgewesen, wenn die Moderatoren nicht so sehr die Hilfesuchenden beschimpfen würden (okay, die sind auch angenervt von der Konsumer-Mentalität…) sondern beim Upgrade einen nicht zu übersehenden Hinweis draufgebeppt hätten. Ich jedenfalls bin beim schnellen Upgraden voll in dieser Stolpferfalle hineingelaufen (drum tippe ich das jetzt hier hinein; vielleicht findet ein Ratsuchender diesen Beitrag).

BTW: Wer nach “You do not have sufficient permissions to access this page” googelt wird oft auch als Lösungshinweis “force-upgrade.php” finden. Das Tool addressiert aber ein anderes Problem dass offenbar mit älteren Versionen im Zusammenhang steht.

Die Entscheidung für WordPress ist für das Projekt wo die Community im Vordergrund steht sicherlich nicht die beste Wahl, aber aus Zeitmangel und aufgrund der vielen WordPress Installationen, die ich inzwischen betreue, ist es mir derzeit leider nicht möglich mich auch noch mit einer weiteren Plattform zu befassen. Sehr gerne hätte ich Drupal eingesetzt – aber es steht zZ. nicht in Aussicht, dass das dabei angesammelte Know-How sich einmal für projektbezogene – also bezahlte – Arbeit nutzen lässt, weshalb ich das privat betriebene und finanzierte Projekt Classic-Cadillac.com der Einfachheit halber mit dem soliden Arbeitstier WordPress betreiben werde.

require_once(dirname(__FILE__).$tmpPath.’/wp-admin/admin-db.php’);

auszukommentieren.

Am problematischsten dürfte das neue Taxonomy-System sein, denn es ersetzt diverse Tabellen.
Das Upgrade auf WordPress 2.3 löscht gleich mehrere Tabellen und macht so eine Reihe von Plugins unbrauchbar, die direkt auf diese Tabellen zugreifen statt über die dafür vorgesehene API zu gehen um z.B. die Kategorien auszulesen. Wer also nach dem Upgrade Fehlermeldungen wie z.B. “wp_post2cat’ doesn’t exist” bekommt, kann davon ausgehen, dass ein verwendetes Plugin nicht mit WordPress 2.3 kompatibel ist.

Eine List der zu WordPress 2.3 nicht mehr kompatiblen Plugins wurde hier zusammengestellt.

Ein Plugin, dass ich einsetze und für das ich kein Upgrade von Seiten des Autoren erwarte ist:

WP-dTree 2.2 Version 2.2 (10 July 2006)
. Das Plugin macht einen recht verwaisten Eindruck, leistete aber bis zu WP 2.2.3 sehr gute Dienste so dass ich dafür sogar ein Widget druckrum gebastelt habe. Da ich bisher noch keinen brauchbaren Ersatz gefunden habe, werde ich das Plugin soweit patchen, dass ich es wieder für meine Zwecke einsetzen kann. (to be continued … maybe… if there is enough time)…

Nachtrag: Problem mit WP2.3 hinter Loadbalancer Pound erkannt. Der Loadbalancer stattet die RequestedURL immer mit der Portangabe :80 aus. Diese Portangabe will WP herausbekommen und sendet einen Redirect. Der Loadbalancer hängt beim neuen Request dann wieder die :80 dran so dass wir in einer endlos-Redirect-Schleife gefangen bleiben. Ich filtere die :80 des Loadbalancers heraus. Damit klappt dann alles bestens. Die volle Funktionalität des neun Canonical URL Redirect bleibt erhalten.

Wer Registrierungen für jedermann zulassen möchte und dabei nicht massenweise automatisiert erstellte Benutzer in Kauf nehmen will, muss sich nach einer Lösung umsehen. Bisher war dies gar nicht so einfach, denn die angebotenen Captcha-Lösungen deckten i.d.R. nur Kommentar-Spam ab oder erforderten die Anpassung von Wordpress Core Quellcode.

Seit kurzem ist nun aber ein Lösung als Plugin verfügbar, die gleich mehrere Captcha-Engines mitbringt und ansteuern kann. Eine Änderung vom Wordpress-Quellcode ist nicht erforderlich. Lediglich die GD-Library und FreeType Library müssen installiert sein, damit das Plugin die Captchas erstellen. Nur wenige Texte sind in englisch im Quellcode hart codiert und können leicht angepasst werden: Login and Register Anti-Spam Captcha Plugin für WordPress von Raz-Soft.

Es sind einige Plugins im Umlauf, die die integrierte Kategorie-Liste von WordPress ersetzen und z.B. um aufklappbare Ordner erweitern.

Fold Category List 1.12 - Provides PHP functions to display a folding category tree.

Dieses Tool kommt ohne Widget daher und arbeitet ohne JavaScript. Es wird also zum Aufklappen eine Kategorie immer eine neue Seite geladen.

Genau diesen Nachteil adressiert das JavaScript Animated Collapsing Categories Widget.

Diese Lösung basiert auf JavaScript - somit wird das Neuladen der Seite vermieden. Ausserdem wird ein Widget beigesteuert. Die Kompatibelität zu WordPress 2.2 scheint jedoch noch nicht gewährleistet zu sein. Der Autor schreibt dazu "NOTE Concerning WordPress 2.2: I have not upgraded my blog to 2.2 yet, and cannot speak to the compatibility of this plugin with WP2.2. If you’ve tried it, please share with me your results!" Ich habe auch Probleme mit diesem Tool unter WP2.2 @Apache2, php5 gehabt, so dass ich mich einem anderen Tool zugewendet habe:

WP-dTree

Leider ist auch hier die aktuelle WP-dTree Version 2.2 bereits etwas angestaubt (last update 10 July 2006) und wolle auf Anhieb nicht so recht mit WP 2.2 harmonieren.

WP-dTree Version 2.2 setzt auf WP-Scriptaculous auf, was vom Autoren ein Lösungsansatz ist unterschiedliche Scriptaculous Versionen zu handlen und die Installation für Scriptaculous-basierte Widgets zu vereinfachen. Ich denke aber, dass dieser zusätzliche Layer nur mehr Komplexibelität mit sich bringt, die nicht zwingend erforderlich ist. Sehr negativ finde ich auch, dass das Plugin Schreibrechte auf die .htaccess benötigt. Um den Problemen mit WP-Scriptaculous aus dem Weg zu gehen habe ich mich entschlossen auf WP-Scriptaculous zu verzichten.

Damit WP-dTree Version 2.2 auch ohne WP-Scriptaculous eingesetzt werden kann, habe ich an /wp-content/plugins/wp-dtree.php folgende Änderungen durchgeführt:

In meinem Theme referenziere ich dann die erforderlichen Scriptaculous Dateien, die von WP aus mitgeliefert werden:

Wünschenswert wäre es übrigens, wenn hier eine AJAX basierte Lösung verfügbar wäre, da somit auch bei umfangreicheren Kategorie-Listen geringere Ladezeiten realisierbar wären.

Last but not least fehlt dem WP-dTree ein Widget so dass es statisch in das Theme eingebunden werden müsste um es zu nutzen. Ich habe mir daher ein einfaches Widget gebaut, welches als Layer um den Funktions-Aufruf für die Kategorie-Liste gelegt wird. Ich habe es lsdtree genannt und sie können es hier downloaden.

In dieser Kombination gibt es dabei Probleme: Die von FeedWordPress importierten Beiträge werden nicht vom PostTeaser verarbeitet, so dass sie in den Listendarstellung vollständig erscheinen anstatt angeteasert zu werden. Auch beim Editieren der via FeedWordPress importieren Beiträge gibt es Probleme: Die Absatzformatierungen gehen verloren.

Ich habe mir beide Plugins angeschaut und herausgefunden, dass das Problem durch das Content-Filter-Handling des FeedWordPress Plugins verursacht wird.

Der Autor dokumentiert sein Dilemma wie folgt:

Syndicated items are generally received in output-ready (X)HTML and
should not be folded, crumpled, mutilated, or spindled by WordPress
formatting filters. But we don't want to interfere with filters for
any locally-authored posts, either.

What WordPress should really have is a way for upstream filters to
stop downstream filters from running at all. Since it doesn't, and
since a downstream filter can't access the original copy of the text
that is being filtered, what we will do here is (1) save a copy of the
original text upstream, before any other filters run, and then (2)
retrieve that copy downstream, after all the other filters run, *if*
this is a syndicated post.

Bei meinem Anwendungsfall ist dieses Verhalten aber nicht gewünscht und nicht erforderlich. Damit also der Filter von PostTeaser greifen kann, muss das eigentlich gute Verhalten von FeedWordPress deaktiviert werden. Hierzu kommentiere ich die beiden Zeilen aus, die die entsprechenden Filter in FeedWordPress einklinken:

Surftipp: http://projects.radgeek.com/2007/02/23/feedwordpress-filter-poll/

In der WP Community ist das WP-o-Matic mit viel Begeisterung aufgenommen worden, weshalb ich es mir zuerst angeschaut habe.

Das jüngere und von der Featurelist sehr vielversprechende WP-o-Matic Projekt macht auf mich einen sehr schlechten ersten Eindruck: Der Autor bietet die 0.2beta Version zum Download an. Die Sourcecodes weisen sich jedoch als Version 0.1beta aus, was nicht nur bei mir sondern auch bei anderen Testern für Verwirrung sorgt. Mit meiner aktuellen WP 2.2.1 Installation kommt die WP-o-Matic 0.2 (oder doch nur 0.1?) dann auch promt nicht zurecht. Das Plugin lässt sich zwar aktivieren, die Tabellen mit Demo-Daten werden auch angelegt, aber das Admin-Interface verhält sich sehr fehlerhaft: Sämtliche Änderungen an den Einstellungen werden nicht übernommen. Der Demo-Feed kann nicht aktiviert werden, ein neuer Feed lässt sich nicht hinzufügen. Die Ajax-Features des Interfaces arbeiten nicht korrekt. Zum testen habe ich also die Einträge in den Tabellen direkt manipuliert. Konnte damit aber auch nicht erreichen, dass Feeds übernommen wurden. Aufgrund der langen Anfragen-Liste mit Fehlermeldungen, der sehr frühen Beta-Version und dem sehr geringen Autoren-Feedback habe ich von diesem Tools zunächst wieder Abstand genommen und es wieder deinstalliert (und die angelegten Tabellen manuell entfernt).

FeedWordPress hat bereits einen längeren Entwicklungszyklus hinter sich und wird auch aktiv vom Autoren supported. Die Site bietet eine umfangreiche Doku zum Projekt und schafft bei mir somit erstmal etwas mehr Vertrauen... Aber auch für dieses Plugin wird die Kompatibelität nur bis WordPress Version 1.5.x, 2.0.x, und 2.1 angegeben.
Die installation ist etwas umfangreicher da nicht nur einfach ein Folder in das Plugin-Verzeichnis kopiert werden. In den wp-content Folder muss man eine weitere Datei ablegen und man muss entscheiden ob man weitere optionale Dateien verwenden will, die default-Dateien von WP ersetzen. Hier habe auf die optionalen Dateien zunächst verzichtet.
Nach der Installation und Aktivierung des Plugins werden keinen weitere Tabellen in der Datenbank angelegt. Zur Datenhaltung "zweckentfremdet" das Pluging die Link-Tabelle. Über eine eigenes angelegte Kategorie "Contributors" kann man die Syndication-Ziele verwalten. Die Einstellungsmöglichkeiten sind viel umfassender als die bei dem noch recht jungen WP-o-Matic was das Tool zwar flexibler aber auch deutlich komplexer macht. Da ich mit FeedWordPress auf Anhieb zum gewünschen Ergebnis gekommen bin und WP-o-Matic auch trotz diverser Fixes und Tweaks nicht dazu zu bewegen war mit WP 2.2.1 zu arbeiten, bleibe ich wohl bis auf weiteres erstmal bei dem etwas ausgereifter wirkenden FeedWordPress.

Beim AdSense-Deluxe Plugin kann ich die zu inkludierenden Ad-Codes selbst anlegen und bin nicht auf das Web-Frontend des AdSense-Managers angewiesen um die Parameter zu bestimmen - hier fand ich den AdSense Manager zunächst sehr einschränkend, da ich glaubte nur festlegen zu können, was das Frontend ermöglicht - bis ich Schussel herausgefunden habe, das ab der Version 2.0 auch "direct Code Ads" unterstützt werden. Insgesamt erscheint mir das AdSense Manager Plugin also etwas "verwirrend" und im nachhinein "aufgebohrt" worden zu sein.

Aber vielleicht liegt das auch daran, dass ich das DeLuxe zuerst kennen gelernt habe.
Beim DeLuxe Plugin sind die "direct code Ads" quasi das einzige womit man zu tun hat. Daher wirkt es konzeptionell gradliniger und bringt weniger Ballast mit.

Man ist bei den Ad-Codes total frei und kann z.B. auch andere Werbedienste intgegrieren oder für andere Publisher Werbung einbauen, da die Pub-Id nicht zentral vergeben und verwendet wird.

Beide Plugins tun sich wohl nicht so viel, wenn es darum geht die Werbung in die Artikel oder Templates zu übernehmen. Das ist bei beiden sehr gut und sehr ähnlich gelöst.

Das AdSense-Deluxe stellt jedoch kein Widget bereit um Werbung in die Sidebars zu integrieren. Das müsste man als Text-Widget selbst erstellen; es wird nicht automatisch bereitgestellt wie es beim AdSende Mananger der Fall ist.

Beide Plugins zwingen einen nicht einen gewissen Prozentsatz der Impressionen abzutreten. Wie es mit Support und Weiterentwicklung der Plugins ausschaut habe ich nicht beurteilen können. Das AdSense Deluxe bringt neben einer Sandbox-Funktion auch integrierte Instruktionen mit, wirkt ansonsten aber etwas verwaist: Latest Version: 0.8 (released Jun 27, 2006).
AdSende Manager scheint durchaus aktiver zu sein - was man aber auch neg. Bewerten kann, denn offenbar gibt's gerade bei den Sidebar-Features mit jüngsten WP Upgrades Probleme die am 31. Mai 07 zum Release der v2.1 des Plugins führten.

Mein Fazit: Auf den ersten Blick habe ich keinen Grund gefunden vom AdSense Delux auf den AdSense-Manager umzusteigen. Aber vielleicht habe ich etwas übersehen?