Man lernt ja nicht aus. Heute bin ich zufällig über einen relativ seltsamen Fehler in unserer Microsoft Exchange 2007 Installation gestolpert. Durch ein automatisch per Windows Update installiertes Update Rollup 1 für Exchange 2007 SP2 meldete die Exchange-Verwaltungskonsole bei jedem Zugriff auf die Toolbox folgende Fehler:

--------------------------------------------------------
Microsoft Exchange Fehler
--------------------------------------------------------
Das Toolboxcenter konnte nicht alle Tools anzeigen.

ExTRA-DRM
Fehler
Fehler:
Fehler des Tools beim Laden, weil das Tool ungültig ist. Beheben Sie die folgenden Ursachen des Fehlers:
'Datenbankwiederherstellungs-Verwaltung' ist kein zulässiges Tool.

ExTRA-MailFlow
Fehler
Fehler:
Fehler des Tools beim Laden, weil das Tool ungültig ist. Beheben Sie die folgenden Ursachen des Fehlers:
'Nachrichtenübermittlungs-Problembehandlung' ist kein zulässiges Tool.

ExTRA-MDBMount
Fehler
Fehler:
Fehler des Tools beim Laden, weil das Tool ungültig ist. Beheben Sie die folgenden Ursachen des Fehlers:
'Datenbank-Problembehandlung' ist kein zulässiges Tool.

ExTRA-MsgTrack
Fehler
Fehler:
Fehler des Tools beim Laden, weil das Tool ungültig ist. Beheben Sie die folgenden Ursachen des Fehlers:
'Nachrichtenverfolgung' ist kein zulässiges Tool.

ExTRA-Perf
Fehler
Fehler:
Fehler des Tools beim Laden, weil das Tool ungültig ist. Beheben Sie die folgenden Ursachen des Fehlers:
'Leistungsproblembehandlung' ist kein zulässiges Tool.

--------------------------------------------------------
OK
--------------------------------------------------------

Die entsprechenden Tools

• ExTRA-DRM: Datenbankwiederherstellungs-Verwaltung,
• ExTRA-MailFlow: Nachrichtenübermittlungs-Problembehandlung,
• ExTRA-MDBMount: Datenbank-Problembehandlung,
• ExTRA-MsgTrack: Nachrichtenverfolgung und
• ExTRA-Perf: Leistungsproblembehandlung

wurden nicht geladen.

Die Ursache des Problems ist relativ einfach. Microsoft hatte im Zuge des Updates die Namen der Tools von deutschen Bezeichnungen auf Englisch geändert, allerdings ohne entsprechende Updates für bereits bestehende Registry-Einträge zur Verfügung zu stellen. Manche Dinge muss man wohl nicht verstehen …

Beheben lässt sich das Problem relativ einfach, in dem man die deutschen Namen im Registry-Pfad HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange\v8.0\AdminTools\Toolbox\ durch ihre nachfolgenden englischen Pendants aus der Dokumentation ersetzt:

• ExTRA-DRM: Database Recovery Management,
• ExTRA-MailFlow: Mail Flow Troubleshooter,
• ExTRA-MDBMount: Database Troubleshooter,
• ExTRA-MsgTrack: Message Tracking und
• ExTRA-Perf: Performance Troubleshooter

Als Registry-File sähe das dann so aus:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange\v8.0\AdminTools\Toolbox\ExTRA-DRM]
@=""
"Name"="Database Recovery Management"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange\v8.0\AdminTools\Toolbox\ExTRA-MailFlow]
@=""
"Name"="Mail Flow Troubleshooter"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange\v8.0\AdminTools\Toolbox\ExTRA-MDBMount]
@=""
"Name"="Database Troubleshooter"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange\v8.0\AdminTools\Toolbox\ExTRA-MsgTrack]
@=""
"Name"="Message Tracking"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange\v8.0\AdminTools\Toolbox\ExTRA-Perf]
@=""
"Name"="Performance Troubleshooter"

Mehr oder weniger zufällig haben wir gestern nach einem Update auf Version 3.0.4 einen „Bug“ im WordPress-Backend gefunden, durch den kein Umschalten des WYSIWYG-Editors zwischen „Visuell“ und „HTML“ mehr möglich war. Da die Eingrenzung des Fehlers doch etwas gedauert hat, poste ich das hier, für den Fall, dass es sonst noch jemandem weiterhilft.

Interessant daran: Scheinbar hatte sich WordPress per Cookie / Einstellung zuvor gemerkt, welchen Modus ein Benutzer beim Schreiben / Editieren zuletzt aktiviert hatte, denn entdeckt wurde der Fehler dadurch, dass bei einem Benutzer scheinbar der Editor nicht mehr funktionierte, bei anderen alledings erschien der Editor (TinyMCE) problemlos. Genau lässt sich auch nicht sagen, seit wann das Problem wirklich existiert, vermutlich schon seit einer der früheren 3.0.X-Versionen.

Das Problem

Die Identifikation des genauen Symptoms war per Firefox-Fehlerkonsole relativ schnell erledigt. jQuery wurde scheinbar nicht korrekt geladen, wodurch darauf aufbauende Javascripts Fehler wie z.B. „jquery is not defined“ oder „edButtons is undefined“ auswurfen.

jQuery is not defined

Die Herkunft des Problems lag allerdings etwas tiefer….

Vorgeschlagene Lösungen

Erste Amtshandlung nach Identifikation der Fehlerquelle war (wie vermutlich bei den meisten) Googlen nach der Meldung aus der Fehlerkonsole. Resultat: http://lmgtfy.com/?q=wordpress+jquery+is+not+defined.

Unter den Support-Forum-Posts der Google-Ergebnisse wurde das Deaktivieren von Plugins zur Eingrenzung der Ursache (z.B. http://wordpress.org/support/topic/javascript-error-jquery-is-not-defined) oder noch häufiger ein erneuter Upload der entsprechenden Javascript-Dateien per FTP-Binärmodus (z.B. http://wordpress.org/support/topic/jquery-is-not-defined) vorgeschlagen.

Lösen ließ sich das Problem in unserem Fall damit allerdings nicht, denn die JS-Dateien kommen bei uns über ein Shell-Update-Skript direkt aus dem WordPress-SVN und auch nachdem alle Plugins deaktiviert waren, bestand der Fehler weiter, obwohl wir z.B. auch das (wie ich persönlich finde) sehr gute, im ersten Link erwähnte Admin Dropdown Menü verwenden.

Die tatsächliche Lösung

Bei der weiteren Suche bin ich dann schnell an der Javascript-Quelle hängen geblieben, die – wie man im Screenshot oben gut erkennen kann – das PHP-Skript „load-scripts.php“ nutzt, um verschiedene Einzeldateien zur Verkürzung der Ladezeit zu konkatenieren. Dieser Mechnismus hat wohl auch schon in anderen Konstellationen Fehler verursacht, siehe z.B. http://wordpress.org/support/topic/wp-28-jquery-error. Durch einfaches Abschalten der Skriptverkettung sowie (sicherheitshalber) auch der gleichzeitig von WP durchgeführten Kompression mittels gzip, konnte der Fehler schließlich relativ einfach beseitigt werden. Hierzu müssen lediglich die beiden folgenden Zeilen in die Datei wp-config.php eingefügt werden, die sich im Root-Verzeichnis der WordPress-Installation befindet:

define('CONCATENATE_SCRIPTS', false);
define('COMPRESS_SCRIPTS', false);