Code Styling Project » Probleme mit WordPress 2.8 lösen

Probleme mit WordPress 2.8 lösen

codestyling | 14. Juni 2009 | 18:10

In letzter Zeit häufen sich die Meldungen wieder mal, das es ziemliche Probleme bei einigen Benutzern gibt, von WordPress 2.7 auf WordPress 2.8 umzusteigen. Einige dieser Probleme lassen sich relativ einfach beheben, man muss nur wissen, was alles möglich ist.
Ich kann hier allerdings keine umfassende “Ich hab für alles eine Lösung…” präsentieren sondern nur eine Auswahl dessen, was mir selbst schon über den Weg gelaufen ist. Der eine oder andere Hinweis wird sicher interessant sein und euch die Kopfschmerzen ersparen.

Allgemeine Problembeschreibungen

1.) Da mit der neuen Version unter anderem jQuery (UI) auch ein Update erfahren hat, gibt es Probleme, wenn der Browser Cache noch immer die alten Scripte benutzen will. Ein Möglichkeit ist das Löschen des Browser Caches.

2.) Es ist bereits gemeldet worden, das der Turbo (Google Gears) Probleme macht und das Backend völlig zur Unbenutzbarkeit degradiert. Derzeit gibt es noch keinen Fix dafür, es empfiehlt sich derzeit eine Deaktivierung von Google Gear für WordPress, um das in den Griff zu bekommen.

3.) Ebenfalls macht das “packen” und “linearisieren” von Javascripts und CSS Dateien einige Probleme. Ebenfalls nicht unproblematisch sind derzeit das standardmäßige Laden der Scripte im Footer. Deshalb könnten Plugins ihren Dienst versagen, weil jQuery erst später geladen wird, diese Scripte aber bereits jQuery benutzen wollen! Wie man das ändern, erkläre ich gleich.

Für den visuellen Editor treffen im Moment mehrer oben genannter Phänomene aufeinander: Google Gears, gepackte Scripte und Laden im Footer. Speziell beim Einbetten von nicht im Lieferumfang von WP enthaltener TinyMCE Komponenten kann die Lade-Reihenfolge tödlich sein.

Die Einstellungsseiten im Backend werden nicht oder nur halb dargestellt. Des Weiteren treten wieder mal Probleme wegen Speichermangels auf.

Gegenmaßnahmen mit Bordmitteln

WordPress hat ein Menge mehr Konstanten mit 2.8 eingeführt, die man dann benutzen sollte, wenn es ernsthafte Probleme mit der Installation gibt. Im Folgenden werde ich einige davon erläutern. Diese Konstanten sollten in der wp-config.php kurz nach den Datenbankeinstellungen definiert werden.

Zusammenfügen von Scripten als ein einziges Script unterbinden

Konfigurations-Eintrag: define(’CONCATENATE_SCRIPTS’, false);
Das Zusammenfassen von Scripten bringt manche Browser aus dem Tritt und hat speziell für den TinyMCE sehr dramatische Folgen. Es führt auf einigen Rechnern dazu, dass die visuelle Darstellung der Editors nicht mehr funktioniert. Dieser Eintrag schaltet das zusammenkleben ab. Das bereinigt unter anderen auch Probleme einiger Plugins, die zwar ihrer Abhängigkeiten gemeldet haben aber nicht in mit linearisiert werden, da sie nicht zu WP Standard gehören und dann zum falschen Zeitpunkt ausgeführt werden.

Scriptkomprimierung unterbinden

Konfigurations-Eintrag: define(’COMPRESS_SCRIPTS’, false);
Einige Browser reagieren ungemein allergisch auf gepackt ausgelieferte Scripte, einer der Spezies ist u.a. der Internet Explorer. Mit diesem Eintrag wird das Packen der Scripte unterbunden. Dieser Eintrag bereinigt auch u.U. die Probleme einiger PHP Backend-Abstürze (Thema PECL_ZIP … Meldungen).

TinyMCE wegen Scriptkomprimierung nicht vorhanden (weiss und keine Buttons)

Da sich die eingeschaltete Script-Komprimierung auch auf den TinyMCE auswirkt, gibt’s es ein neues Problem. Hier ein Ausschnitt aus der Datei, die den TinyMCE ausliefert:

PHP
1
2
3
4
5
6
7
8
9
10
11
12
13
...
header('Content-Type: application/x-javascript; charset=UTF-8');
header('Vary: Accept-Encoding'); // Handle proxies
header('Expires: ' . gmdate( "D, d M Y H:i:s", time() + $expires_offset ) . ' GMT');
header("Cache-Control: public, max-age=$expires_offset");
 
if ( isset($_GET['c']) && 1 == $_GET['c'] && false !== strpos( strtolower($_SERVER['HTTP_ACCEPT_ENCODING']), 'gzip') ) {
	header('Content-Encoding: gzip');
	echo get_file($basepath . '/wp-tinymce.js.gz');
} else {
	echo get_file($basepath . '/wp-tinymce.js');
}
exit;
timing: 0.096s

PHP
1 2 3 4 5 6 7 8 9 10 11 12 13	... header('Content-Type: application/x-javascript; charset=UTF-8'); header('Vary: Accept-Encoding'); // Handle proxies header('Expires: ' . gmdate( "D, d M Y H:i:s", time() + $expires_offset ) . ' GMT'); header("Cache-Control: public, max-age=$expires_offset"); if ( isset($_GET['c']) && 1 == $_GET['c'] && false !== strpos( strtolower($_SERVER['HTTP_ACCEPT_ENCODING']), 'gzip') ) { header('Content-Encoding: gzip'); echo get_file($basepath . '/wp-tinymce.js.gz'); } else { echo get_file($basepath . '/wp-tinymce.js'); } exit;
timing: 0.096s

Es liegt eine vorkomprimierte TinyMCE Datei rum, die ausgeliefert wird. Ich habe getestet, was passiert, wenn man sie löscht. WP 2.8 scheint sie nicht! neu zu erstellen sondern der TinyMCE ist dann mit 2 Script-Abstürzen einfach nicht da und der Inhalt des Editors weiss bis auf die roten Pünktchen der Rechtschreibkontrolle.
Wenn man die Datei wieder herstellt, geht der Tiny auch wieder. Mit der Option define(’COMPRESS_SCRIPTS’, false); lässt sich auch der TinyMCE beeinflussen und liefert dann die ungepackte Datei aus. Bei Providern, die keine packten Dateien auf dem WebSpace erlauben und sofort löschen, dürfte der TinyMCE deshalb nicht funktionieren. Dort kann man wie oben beschrieben, die Script-Komprimierung nur ausschalten!

Stylesheet Komprimierung ausschalten

Konfigurations-Eintrag: define(’COMPRESS_CSS’, false);
Auf komprimierte Stylesheets reagieren noch viel mehr Browser allergisch. Dieser Eintrag schaltet dies ab. Dies bereinigt unter Umständen die Probleme in der Seitendarstellung, wenn etwas im Design kaputt ist, obwohl am Theme nix geändert wurde.

Google Gears abschalten

Wie oben schon erwähnt, ist das eine temporäre Lösung und sollte durch WordPress mit dem nächsten Hotfix bereinigt sein. Wen es nicht betrifft, hat derzeit Glück. Das Problem gibts als Trac #10112 Eintrag bereits.

fehlerhafte Themes korrigieren

In einigen Themes fehlt in der Footer Sektion ein Hook Aufruf, der ab WP 2.8 aber essentiell ist. Da nun Scripte erst im Footer geladen werden können, um den Speed der Seitenauslieferung zu erhöhen, benötigt man nun: <?php wp_footer(); ?> in der footer.php des Themes. Fehlt dieser Aufruf, dann werden einige Scripts unter Umständen nicht mehr geladen und die Seite macht nicht, was sie soll.

Zeitzonenunterstützung zerstört die Einstellungsseite(n)

Mit den Zeitzonenunterstützung hat sich WordPress keinen Gefallen getan, denn diese benötigt zwingend PHP 5. Allerdings sind selbst nicht alle PHP 5 Versionen in der Lage, das dann hinzubekommen, wie ein Trac #10143 Eintrag im WordPress Trac zeigt. Falls es daran liegt, kann man das mit einem Filter unterbinden, den man provisorisch in der functions.php des Themes einfügt:
add_filter(’timezone_support’, create_function(’$on’,'return false;’));

Fatal error: Allowed memory size of xxxxxxxx bytes exhausted

Das tritt auf, weil der Speicheranspruch den WordPress 2.8 stellt, deutlich gewachsen ist. Es gibt 3 Möglichkeiten, damit umzugehen, wenn die alle nicht funktionieren, dann kann nur der Provider der Limit anheben:

1.) wenn man Zugriff auf die php.ini des Servers hat, kann man Folgendes eintragen:
memory_limit = 64M ; Maximum amount of memory a script may consume (64MB)

2.) wenn der Server .htaccess Dateien unterstützt, dann kann man dort das hier außerhalb der WordPress Sektion (möglichst am Anfang) eintragen:
php_value memory_limit 64M

3.) man es es in der wp-config.php ebenfalls eintragen:
define(’WP_MEMORY_LIMIT’, ‘64M’);

Dies setzt allerdings voraus, das der Provider das auch erlaubt. Wenn keine Möglichkeit davon den Fehler behebt, sollte man den Provider wegen Erhöhung des PHP Speicherlimits kontaktieren.

Fatal error: Cannot use object of type WP_Error as array

Diese scheint ein Problem zu sein, das bei bestimmten Themes wie “Options” oder “Structure” auftaucht. Für die beiden genannten Themes sollte es jetzt Updates geben, die das beheben. Allerdings könnten auch andere Themes betroffen sein. Zum Test einfach mal das Standard Theme aktivieren. Wenn im Standard Theme alles ok ist, dann braucht man dringend ein Theme Update. Der Patch für die o.g. Themes sieht so aus:
$all_cats = get_all_category_ids();
ersetzen durch
$all_cats = get_categories();
Ob das bei einem anderen Theme auch hilft, kann ich nicht beurteilen, wollte es nur mit auflisten.

Fatal error: Trying to clone an uncloneable object …

Diese Problem hat ausnahmsweise nichts mit WordPress selbst zu tun sondern mit einer Einstellung beim Provider. Wenn man PHP 5 benutzt, werden auch ein paar Reflections Erweiterungen verwendet, die nur ab PHP 5 zur Verfügung stehen.
Unglücklicher Weise gibt das aber ein Problem, wenn beim Provider folgende php.ini Einstellung gesetzt ist:
zend.ze1_compatibility_mode=On
Diese sollte aber so aussehen, wenn man PHP 5 einsetzt:
zend.ze1_compatibility_mode=Off
Bei PHP Reflections API kann man das als Kommentar nachlesen. Ebenfalls hat das einem Nutzer im Forum von WordPress Deutschland geholfen, einen sauber funktionierenden Blog zu bekommen.

kein Ajax Drag ‘n Drop mehr möglich in Backend

Das ist ebenfalls durch inkompatible Themes wie die von “Wootheme” hervorgerufen. Diese erweitern den Admin Bereich mir eigenen Javascripts, die sie in den Header packen unter der Annahme, die Bibliotheken wie jQuery sind schon geladen. Leider passiert das erst im Footer, weshalb die Javascript Engine wegen des Fehlers dann keine Scripte mehr interpretiert.
Grundsätzlich sollten alle Themes überprüft werden, ob sie mit WP 2.8 kompatibel sind und ggf. ein Update eingespielt werden!

Cache Plugins verhindern korrekt Funktion

Wenn Plugins wie “WP SuperCache” im Einsatz sind, dann muss man diese deaktivieren, den Cache auf dem Server komplett leeren und das Plugin wieder starten (aktivieren). Durch das Cachen von Seiten und deren Inhalten werden auch zum Teil Skripte mit gecacht, die nicht mehr funktionieren nach einem Update auf 2.8 weil sie für 2.7 bestimmt waren.

sämtliche Dateien können gelöscht werden, wenn das automatische Core-Update fehlschlägt

Wenn der Core Update Prozess von 2.7 auf 2.8 zwar alle Dateien runterladen kann dieser auch auspacken aber nicht überall ersetzen kann, dann führt eine fehlerhaft implementierte Bereinigung (Löschen der Download - Dateien) statt dessen zum Löschen der bisherigen Dateien!
Einen Fix gibt es unter Trac #10140 bereits und ist für WP 2.8.1 schon eingetragen.
Was sagt uns das? Immer ein Backup der Datenbank und aller Dateien des Servers in greifbarer Nähe haben, wenn man ein Core Update durchführt!

Fatal error: Class ‘Translations’ not found in xxxxx

Die Rechtevergabe auf neu angelegte Ordner funktioniert ausgerechnet nur bei den neuen Dateien für die Sprachdatei-Verwaltung nicht korrekt. Dies ist ebenfalls als neues Ticket Trac #9846 für WordPress Version 2.8.1 eingetragen und gefixed. Die Lösung ist, das man die Berechtigung per FTP Programm für den Ordner ändert:
wp-includes/pomo auf 755 stellen

ShortCodes werden nicht oder nicht richtig ersetzt

Wenn man WordPress ShortCode verwendet oder ein Plugin das tut, dann funktioniert das derzeit offensichtlich auch nicht mehr in allen Fällen.
Auch das ist bereits als Fehler registriert unter Trac #10082 und ist auf Wp 2.8.1 gestellt. Falls man eine kurzfristige Behebung braucht, müssen die ShortCodes einzeln jeweils in eine eigene Zeile geschrieben werden. Direkt hintereinander wie das hier, funktioniert leider nur teilweise bis gar nicht:
[media id=”448″]test[/media][media id=”448″]test[/media]

Zusammenfassung

Dank Jörn’s Hinweis will ich nochmal deutlich dazu schreiben, dass Abschaltungen von Kompression und Dateizusammenlegung natürlich einen Geschwindigkeitsverlust in der Auslieferung der Seite nach sich ziehen. Diese Lösungsvorschläge zielen daher primär auf die Sicherstellung der Benutzbarkeit von WordPress nach Update auf Version 2.8 ab und sind nicht als dauerhafte Lösung gedacht. Nur manchmal braucht man eben einen funktionierenden Blog dringender.
Sobald für die Probleme die entsprechenden Gründe, Patches oder permanent einsatzfähigen Lösungen bekannt sind, werde ich das wieder hier oder auf WordPress Deutschland veröffentlichen.

Kategorien: Deutsch, WordPress (DE), jQuery in WordPress
: RSS Kommentare

52 Antworten Schreib einen Kommentar

Kretzschmar

14.06.2009 | 19:15

Es sollte jedoch auch nicht unerwähnt bleiben, dass alle diese Maßnahmen die Geschwindigkeitsverbesserungen der neuen WordPress Version maßgeblich beeinflussen.
Oft hilft auch das Deaktivieren einzelner Plugins. Über längere Zeiträume sammeln sich auf einigen Blogs astronomisch viele Plugins an, von denen meist viele nicht unbedingt benötigt werden.

PHP
1	wp_enqueue_script( 'jquery' );
timing: 0.061s

Probleme mit WordPress 2.8 lösen

Allgemeine Problembeschreibungen

Gegenmaßnahmen mit Bordmitteln

Zusammenfügen von Scripten als ein einziges Script unterbinden

Scriptkomprimierung unterbinden

TinyMCE wegen Scriptkomprimierung nicht vorhanden (weiss und keine Buttons)

Stylesheet Komprimierung ausschalten

Google Gears abschalten

fehlerhafte Themes korrigieren

Zeitzonenunterstützung zerstört die Einstellungsseite(n)

Fatal error: Allowed memory size of xxxxxxxx bytes exhausted

Fatal error: Cannot use object of type WP_Error as array

Fatal error: Trying to clone an uncloneable object …

kein Ajax Drag ‘n Drop mehr möglich in Backend

Cache Plugins verhindern korrekt Funktion

sämtliche Dateien können gelöscht werden, wenn das automatische Core-Update fehlschlägt

Fatal error: Class ‘Translations’ not found in xxxxx

ShortCodes werden nicht oder nicht richtig ersetzt

Zusammenfassung

52 Antworten Schreib einen Kommentar

thomas

thomas

thomas

thomas

thomas

Ulli

Ulli

Ulli

thomas

gthr

Frank

Frank

Frank

Marcus

Refizul

Navigation

Suche

Neuere Beiträge ...

Ältere Beiträge ...