Aus Anlass der Veröffentlichung von WordPress 2.5 und den damit in naher Zukunft verbundenen regen Update-Aktivitäten und wohlmöglich dann auch vermehrt auftretenden Hilferufen, möchte ich hier noch einen Hinweis zum Besten geben. Immer wieder tauchen beim Upgraden von WordPress Probleme auf, Sven von der Trendmile kann davon ein Liedchen singen. Und nicht nur Sven, auch ich habe bei meinen letzten Upgrade-Aktionen desöfteren die seltsamsten Phänomen erlebt. Ob Fehlfunktionen, blanke Kommentar-Seiten, Plugins die sich nicht mehr aktivieren lassen wollten oder das gänzliche Verschwinden des Admin-Bereiches, all diese Dinge durfte ich schon mehrfach erleben.
Die Fehlersuche hat immer wieder Zeit gekostet, am Ende kristallisierte sich aber neben veralteten Plugins und Templates eine Fehlerquelle als immer wiederkehrende Problemursache heraus – der Speicherhunder von WordPress und das leidige Speicherlimit von PHP. So kann es passieren, dass eine vormals problemfreie WordPress 2.1.3 nach einem Upgrade auf WordPress 2.3.3 zu spinnen anfängt und beim Upgrade-Versuch auf WP 2.5 gänzlich den Geist aufgibt. Die Ursache ist im zunehmenden Speicherverbrauch der neueren Versionen zu finden. Reichten für ältere Installationen noch 8 MB, so müssen es für die neueren Versionen einige MB mehr sein. Hier im SOS SEO Blog bin ich sogar schon bei 16 MB auf Probleme gestoßen, insofern würde ich 24 MB als Minimum ansehen. Besser den Wert gleich auf 32 MB erhöhen, dann hat man noch für ein paar weitere WordPress Upgrades Luft ;-)
Um welchen Wert geht es hier? Er nennt sich memory_limit und ist üblicherweise in der php.ini Datei angesiedelt. Wer Zugriff darauf hat und weiss was er tut, der kann den Wert anpassen und muss anschließend nur noch den Webserver restarten um in den Genuß von mehr Speicher für seinen PHP Prozessor zu kommen. Unter Umständen kann der Wert auch lokal via .htaccess verändert werden, dazu trägt man lediglich noch die Zeile
php_value memory_limit 24M
in die .htaccess Datei ein und hofft, dass alles ohne Serverfehler vonstatten geht. So habe ich z.B. eben das Limit einer bei Webtropia gehosteten Domain von 8 auf 16 MB erhöht und damit auch mein WP 2.5 Upgrade Problem gelöst. Bevor man aber zu diesen Maßnahmen greift, sollte man sich über die tatsächlichen Werte schlau machen. Entsprechende Informationen finden sich meist im Administrationsbereich des Webservers oder können über die Funktion phpinfo ausgelesen werden. Schon eine php-Datei mit nur einer Zeile Code <? phpinfo() ?> bringt die Details ans Tageslicht. Am besten ist natürlich, es geht alles glatt und solche Verrenkungen erübrigen sich.
Bei meinen drei soeben veranstalteten WordPress 2.5 Upgrades klappte (einmal nach Behebung des Speicherproblems) alles perfekt – es schaut diesmal tatsächlich alles nach einer schmerzfreieren WP-Version aus.
Dabei muss man aber dringend beachten, dass php_value *nur* verfügbar ist, wenn PHP als Module läuft und das ist bei den einschlägigen Hostern nicht der Fall. PHP als Module ist von unsicher und wir deswegen of nicht eingesetzt.
Wenn PHP aber als CGI läuft, kannst du oft eine eigene php.ini anlegen. Weitere Informationen dazu direkt auf der PHP-Homepage:
http://www.php.net/manual/en/ini.core.php#ini.memory-limit
Gruß,
Martin
BTW: Die php.ini geht auch pro Verzeichnis, ähnlich einer .htaccess.
Kleine Anmerkung zu Martin’s Tipp:
Das mit der eigenen php.ini ist schon eine praktische Sache, verwende ich selbst auch häufig. Man muss nur unbedingt berücksichtigen, dass sich diese Einstellungen im CGI-Modus NICHT auf untergeordnete Ordner vererben! Dies ist nicht äquivalent zu Einstellungen in der .htaccess.
d.h. es muss in jeden Ordner, in dem PHP-Dateien liegen, auf die direkt per URL zugegriffen wird, eine Kopie der Datei abgelegt werden.
Bsp:
Wordpress verwaltet das Blog-Frontend über index.php im Stammverzeichnis. Dort muss die erste php.ini abgelegt werden.
Aber der Zugriff auf’s Admin-Panel läuft über /wp-admin/index.php. Somit muss im Ordner /wp-admin/ ebenfalls eine php.ini abgelegt werden. Sonst läuft dort alles mit Standardeinstellungen.
Teilweise ist es auch möglich für eine ganze Domain eine eigene PHP ini zu definieren. Das ist recht praktisch, führt aber zur Verwirrung, wenn man – völlig SEO-unfreundlich – mehrere Domains in den gleichen Ordner schickt und nicht per htaccess umleitet. In diesem Fall kann es passieren, dass die Webseite einmal mit und einmal ohne die php.ini arbeitet, was zu unterschiedlichsten Ergebnissen führen kann. Mache sowas manchmal zu Testzwecken auf dem „Heimserver“.
Wer übrigens mit dem neuen WordPress Backend nich so wirklich dicke ist – z.B. weil er ständig nach dem Button „Settings“ sucht oder weil er mit dem halb flüssig, halb festen Layout einfach nicht kann, der kann sich mal das Alternative WP Backend Fluency Admin anschauen – ich ziehe es dem neuen Standard jedenfalls vor.
etwaige Mehrinfos: http://perishablepress.com/press/2008/02/19/improve-site-performance-by-increasing-php-memory-for-wordpress/
Kenn das Problem bei Joomla, dort hatte ich das auch immer.