WordPress Fehler durch Sprachdateien - die Ursache
codestyling | 20. Juli 2008 | 16:47
Nach langer Suche, frustierenden Rückmeldungen für den temporären Patch, den ich schon bereitgestellt hab, ist es mir nun endlich gelungen, die Ursache dieses Problems zu finden und auch auf meiner lokalen Installation unter XAMPP zu reproduzieren. Eine intensive Recherche im Web förderte eine Menge gravierende Probleme zu Tage, die ich hier in diesem Zusammenhang mal darlegen möchte. Der Eintrag im WordPress Trac wird von mir umgehend erweitert, sodass in folgenden Updates dies berücksichtigt werden kann.
Um nochmal zu zeigen, worum es eigentlich geht, hier ein Admin Seitenaufruf meiner Testinstallation, wenn dieser Fehler auftritt:
Warning: unpack() [function.unpack]: Type V: not enough input, need 4, have 0 in C:\xampp\_root_wordpress26\wp-includes\gettext.php on line 91 Warning: unpack() [function.unpack]: Type V: not enough input, need 4, have 0 in C:\xampp\_root_wordpress26\wp-includes\gettext.php on line 91 Warning: unpack() [function.unpack]: Type V: not enough input, need 4, have 0 in C:\xampp\_root_wordpress26\wp-includes\gettext.php on line 91 Warning: unpack() [function.unpack]: Type V: not enough input, need 4, have 0 in C:\xampp\_root_wordpress26\wp-includes\gettext.php on line 91 Fatal error: Maximum execution time of 60 seconds exceeded in C:\xampp\_root_wordpress26\wp-includes\streams.php on line 66 Fatal error: Maximum execution time of 60 seconds exceeded in C:\xampp\_root_wordpress26\wp-includes\wp-db.php on line 359
Diese Fehlermeldungen mit Verweis auf unpack(), gettext() und der maximum execution time mit anschliessendem Script Abbruch sollten allen Betroffenen bekannt sein. Um diesen Fehler in meiner lokalen XAMPP Installation (hier WP 2.6, betrifft aber auch WP 2.5.x) zu provozieren, hab ich in der php.ini folgende Einstellung geändert:
; overload(replace) single byte functions by mbstring functions.
; mail(), ereg(), etc are overloaded by mb_send_mail(), mb_ereg(),
; etc. Possible values are 0,1,2,4 or combination of them.
; For example, 7 for overload everything.
; 0: No overload
; 1: Overload mail() function
; 2: Overload str*() functions
; 4: Overload ereg*() functions
mbstring.func_overload = 7
Sinn und Zweck der Überladung von Stringfunktionen mit multibyte String Funktionen wäre eigentlich, Seiten mit Unicode Ausgaben zu unterstützen. Allerdings funktioniert das nicht auf diese Weise mit den Sprachdateien und produziert noch andere ungewollte Fehler in PHP Scripten (nicht nur bei WordPress!).
Sobald man diesen Eintrag in der php.ini auf mbstring.func_overload = 0 stellt, ist alles erstmal wieder korrekt und man kann wieder Sprachdateien verwenden.
Wer jetzt aber der Meinung ist, das es sich damit schon erledigt hat, läuft in 3 gravierende Probleme:
- Einige Provider erlauben nicht, die php.ini zu ändern.
- Eine lokale php.ini in der eigenen Domain wird nicht immer unterstützt.
- Die Änderungen dieses Wertes mittels .htaccess Datei hat brutale Aus- und Nebenwirkungen!
Fangen wir mal an, die Nebenwirkungen folgender Änderung in der .htaccess zu untersuchen:
PHP_VALUE mbstring.func_overload 0
Dies sollte, sofern der Provider dies auswertet, dazu führen, das Sprachdateien wieder funktionieren. Allerdings gibt es einen BUG seit 2004 im Zusammenspiel von mod_php und Apache (Bug #27421 | mbstring.func_overload set in .htaccess becomes global), der bei dieser Art der Umstellung für alle vhost’s des Providers dies umschaltet!
Das bedeutet auch, wenn auf einem shared hosting auch nur einer der anderen Domains, die durch den Apache gehostet werden, in seiner .htaccess dies wieder auf einen Wert ungleich 0 stellt, dass alle anderen Domains, die hier mit gehostet sind, sozuagen “abgeschossen” werden. Denn fälschlicher Weise wirkt sich das global aus anstatt nur für die Domain, für die es gesetzt wurde!
Die betroffenen Systeme, die ich bisher kenne, kann man in zwei Gruppen unterteilen:
- Gruppe a) Der Fehler tritt immer auf und der bisherige Patch bringt gar nix.
- Gruppe b) Der Fehler tritt nur sporadisch auf und gibt sich nach einiger Zeit wieder.
In Gruppe a) sieht es danach aus, dass der Provider grundsätzlich diesen Wert so konfiguriert hat, dass sämtlich String Funktionen überladen werden für alle Domains, die durch diesen Apache gehostet werden. Dann sollte man mit dem Provider sprechen und diesen darauf hinweisen und verlangen, dass diese Einstellung global auf 0 gestellt wird oder auskommentiert wird (was Standardwert 0 entspricht).
In Gruppe b) ist es schwieriger, damit umzugehen. Wenn man bisher zu Gruppe a) gehörte, den Provider überzeugen konnte, das auszuschalten, kann es jetzt passieren, dass man in Gruppe b) landet. Denn irgend eine Domain, die mit gehostet ist, stellt dies per .htaccess um. Wenn also ein Seitenzugriff auf der Domain passiert, die das umstellt und gleichzeitig auf meiner eigenen Domain ein Zugriff reinkommt, wird plötzlich dieser Fehler auftauchen. Er verschwindet sofort, wenn weitere Anfragen meiner Domain in einem anderen Apache Prozess landen, der nicht umgestellt wurde oder der Apache Prozess, der betroffen war, einen restart durchführt. Gegen andere Domains, die das auslösen können, gibt es bis jetzt noch keine Lösung, weder seitens PHP noch Apache’s noch WordPress.
Ich werde dieses Problem nochmal dem gemeldeten WP Bug Trac anhängen, damit dort auch die Ursache bekannt ist. Sowie es meine Zeit erlaubt, werde ich auch einen qualifizierten Patch für die Sprachdatei Verarbeitung und WP machen, denn man kann das sehr wohl im Code behandeln, nur muss man erstmal wissen, woher der Fehler kommt.
Leider hat dieser Apache/PHP Bug weitreichende Konsequenzen für die korrekte Funktion diverser PHP Scripts. Da Stringfunktionen manipuliert sind (overload), können beispielsweise Plugins versagen, Regular Expressions abstürzen bzw. Müll produzieren oder aber der schon mehrfach genannte Mail Versand von WordPress keine korrekten deutschen Texte versenden!
Die im Moment beste Lösung ist, den Provider zu benachrichtigen und diesen zu veranlassen, diesen Parameter immer auf 0 stehen zu lassen und zu verhindern, dass er je wieder umgestellt werden kann (weder durch eigene php.ini noch .htaccess Anpassung). Dieser Fehler bewirkt u.a. auch, das PhpMyAdmin nicht funktioniert, aber dort wird dies gemeldet als fehlerhafte Konfiguration.
Ich hoffe, diese Beschreibungen und Erklärungen helfen dem Einen oder Anderen, das Problem zu beheben. Der bisherige Patch ist dann nicht mehr nötig, wenn diese Einstellung immer auf 0 steht. Für Rückmeldungen und weitere Hinweise bin ich dankbar und werde mich drum kümmern, wenn es die Zeit erlaubt.
Update: 21.07.2008
Ich hab mich nochmal hingesetzt und die betroffene streams.php, die schon einmal gepatched habe, erneut anzupassen. Damals wusste ich ja die Ursache nicht und hab nur eine Umgehung gebaut. Jetzt ist das korrekt behandelt und wählt immer gemäß der eingestellten Überladung (mbstring.func_overload) die korrekte Variante des Einlesens der Sprachdatei. Ich hab das mit allen möglichen Einstellungen getestet (von 0 bis 7) und es gibt damit keine Probleme mehr, egal wie die Einstellungen in der php.ini aussehen mögen.
WP 2.5.x / WP 2.6.0 streams.php Patch: streams.php-WP2.5.x_2.6.0.zip
(ersetzt die bisherige streams.php im Ordner /wp-includes/)
Ich werde das jetzt ebenfalls an den WP Bug Trac Eintrag anhängen und hoffe nun, das dies dann endlich den Einzug in die nächste Release findet.
Frank
22.07.2008 | 11:23Hallo,
erst einmal vielen Dank für Deine Mühen. Ich habe Deinen neuen zweiten Patch eingespielt und der Fehler tritt bei mir leider weiterhin sporadisch auf.
Ich hatte eine zeitlang Deinen ersten Patch verwendet und da trat der Fehler nicht auf. Es gab aber Probleme mit einem Plugin durch die neue streams.php
Benötigst Du weitere Informationen um das Problem weiter zu verfolgen?
Viele Grüße,
Frank
Antworten »
codestyling
22.07.2008 | 11:49Mich würden folgende Informationen interessieren:
1. Welcher Provider ist dahinter ?
2. Was gibt eine Aufruf von < ?php echo ini_get("mbstring.func_overload"); ?> bei dir aus ?
Es ist möglich, wenn ich den PHP/Apache global Bug betrachte, das eine Umschaltung im laufenen Betrieb eine bereits im Interpreter befindliche PHP Datei mittendrin umschaltet. Wenn also deine Datei mit Wert 0 anfuhr und jemand anderes auf dem Server seine Domain per .htaccess umstellt und in mod_php alle Domains fehlerhafter Weise nun “on the fly” gepatched werden, kann es passieren, das mitten im Lesen der *.mo Datei dein Script “stirbt”. Ob das so ist, muß ich noch mit einen neu aufzusetzenden Server und einem Stresstool testen.
Da du schreibst, der bisherige Patch machte bei Plugins Probleme, dürfte sich das aber (abgesehen von o.g. Problem) jetzt gelegt haben, richtig ?
Antworten »
Frank
22.07.2008 | 13:251. all-inkl.com
2. 0
3. Das Plugin “Post Notification” läuft bisher ohne Probleme
Antworten »
codestyling
22.07.2008 | 13:36Danke für die Informationen. Damit kann man 2 Sachen festhalten:
1. Der Bugfix ist erstmal soweit ok, weil das betroffene Plugin auch wieder geht.
2. Es sieht danach aus, dass immer nur (oder zumindest in unnatürlich hohem Maße) der Provider all-inkl.com davon betroffen ist.
Fast 100% aller Meldungen dieser Art, die mich erreicht haben, betreffen diesen Provider. Wenn das sporadisch bei dir weiterhin auftritt, dann fürchte ich, das der Bug im Apache/PHP weit drastischer ist, als ich dachte. Das legt die Vermutung nahe, das tatsächlich im laufenden Betrieb der Apache für alle Domains den overload ,verursacht durch eine bestimmte Domain, umschaltet und andere Domains damit crashen kann! Das würde auch die Aussagen von Betroffenen erklären, die nach einer solchen, sporadische Fehlermeldungen x Minuten nicht mehr ihre Domain erreichen können. Scheinbar macht dann der Apache einen Restart und dann ist die Domain wieder da, als wäre nix gewesen.
Vielleicht solltest du den oben verlinkten Bug und eine Referenz auf meinen Artikel an den Provider schicken. Dieser sollte dann zumindest verhindern können (wenn schon diese Wert auf 0 steht), dass man den nicht mehr per .htaccess ändern kann!
Antworten »
Frank
28.07.2008 | 08:42Nach der Rücksprache mit meinem Provider all-inkl.com habe ich folgende Eintrag in der htaccess gemacht: PHP_VALUE mbstring.func_overload 0
Bisher läuft es jetzt fehlerfrei…
Antworten »
Frank
30.07.2008 | 09:05Fehler tritt leider weiterhin auf.
Antworten »
ChristianB
25.07.2008 | 12:45Erfahrungsbericht zum neuesten Patch:
Nach der Installation hat wieder alles funktioniert. Ich habe auch eine ganze Weile hin und her geklickt und versucht den Fehler zu provozieren. Da kam aber nichts, bis ich schon dachte es ist wieder alles in Ordnung und dann hatte ich doch wieder den Fatal Error. Allerdings konnte da ein Neuladen der Seite ziemlich schnell helfen. Das war gestern Abend und ich war soweit zufrieden das der Fehler halt nur sporadisch aufgetreten ist und durch einmal F5 “behoben” war.
Nun muss ich aber heute feststellen das die komplette Deutsche Seite nicht funktioniert. Zumindest wenn ich mehrere Seiten hintereinander aufrufen will. Nach einer Weile warten dann funktionierts mal wieder für ein oder zwei Klicks. Scheint wohl mit dem Apache zusammen zu hängen. Ich bin übrigens auch bei all-inkl.com und die Variable mbstring.func_overload steht auch auf 0.
Ich habe noch ein Testblog auf demselben Server mit einer reinen Deutschen WP Version ohne Plugins und mit deinem Patch und da geht auch nichts mehr seit heute morgen.
Hast du den Patch der in dem PHP Bug angesprochen wird mal getestet? Kannst du sagen ob der funktioniert dann würde ich das mal an all-inkl.com senden.
Antworten »
codestyling
25.07.2008 | 13:49Das ist seltsam. Denn mein neuer Patch (etwas umgestellt) wurde für WP 2.6.1 abgesegnet und eingebaut. Ich hab leider noch keine Zeit gehabt, mir ein PHP selbst zu kompilen mit dem PHP Bug diff-set und dieses zu testen. Allerdings ist die Beschreibung und Verhaltensweise dieses Bugs sehr krass und kann unter Last des Servers zu diesem Problem führen.
Mittlerweile bin ich noch auf einen anderen PHP Bug gestoßen, der den Server crashed, wenn man was runterladen will: ZEND_COMPATIBILITY_MODE hier beschrieben für WP 2.3.1
Ich hab auch noch einen anderen Link (nur im Moment nicht hier zur Hand, wird nachgereicht), der ebenfalls zerstörte binary Dateien betrifft. Das kann auch gut auf die *.mo Dateien zutreffen.
Ich würden in jedem Falle an deiner Stelle mal mit all-inkl.com darüber sprechen. Es sollte ja auch in deren Interesse sein, das die Server funktionieren.
Antworten »
ChristianB
25.07.2008 | 16:23Ich habe das mal alles zusammengefasst und an den Support von all-inkl.com geschickt. Die sind eigentlich meiner Erfahrung nach ziemlich schnell und zuverlässig. Ich hoffe nicht das sich das geändert hat.
Antworten »
ChristianB
26.07.2008 | 15:00Der Support hat empfohlen das ganze über die .htaccess zu lösen. Also habe ich wie oben beschrieben eine .htaccess Datei im WP root Verzeichnis angelegt und siehe da es funktioniert wieder. Ob die jetzt was mit dem Server gemacht haben kann ich nicht sagen aber ich empfehle jedem all-inkl.com Nutzer eine .htaccess Datei anzulegen. Danke auch dir, Heiko, nochmal für die Hilfe und den Patch.
Antworten »
ChristianB
30.07.2008 | 23:00Auch bei mir tritt jetzt der Fehler wieder tagsüber in sehr regelmäßigen Abständen wieder auf. Ich bin noch in Kontakt mit dem all-inkl.com Support.
@Frank kannst du mir mal deine URL oder Mailadresse geben, vielleicht können wir ja gemeinsam bei all-inkl.com was drehen.
Antworten »
Frank
31.07.2008 | 07:53URL: http://www.blumenversand-weltweit.de
Antworten »
Apollo
31.07.2008 | 11:30Hallo ich hab das selbe Problem und mich schon bei all-inkl gemeldet. Die meinen ich soll:
Zitat:”Daher schlage ich vor einfach die Fehlermeldung zu unterdrücken und dem Funktionsaufruf ein @ voranzustellen.”
gemacht hab ich das noch nicht, weil ich jetzt nich gleich weiß wo ich das machen soll
Ich hoffe das löst sich bald mal alles *grml*
MfG
Antworten »
Moguul
31.07.2008 | 18:08Also vielen vielen Dank für deine Mühe. Bei mir funktionierts einwandfrei. Und bis all-inkl reagiert…die sind da etwas vorsichtig ihre ganze Konfigurationsmentalität wegen eines Fehlers umzuwerfen. Aber bis dahin ist es eine gute Lösung. Respekt.
Antworten »
Daniel
10.08.2008 | 21:26Eine Frage @ ChristianB: Was genau steht in dieser .htaccess-Datei drin? Ich habe meine Site auch bei all-inkl.com, aber die sagten nur: “das würde uns auch interessieren
Ich wüsste nicht, was wir dort eintrage könnten.” (bei mir geht es mit dem zweiten Patch (auf dieser Site angeboten) auch nicht, mit dem ersten kommt der Fehler derzeit wenigstens nicht)
LG,
Daniel
Antworten »
codestyling
10.08.2008 | 21:37Also ich greife das nochmal auf. Wie oben schon beschrieben, wurde in die .htaccess Datei am Anfang folgendes aufgenommen:
PHP_VALUE mbstring.func_overload 0Wie gesagt, es ist, soweit ich das beurteilen kann, nur bei diesem Provider ein gravierendes Problem. Alle anderen Provider haben diese Probleme nicht.
Antworten »
Daniel
11.08.2008 | 13:15Ich frag besser nochmal nach:
die .htaccess-Datei im Root-Verzeichnis? Da steht bei mir wegen der individuellen html-Titel folgendes drin:
RewriteEngine On
RewriteBase /blog/
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /blog/index.php [L]
Und da soll ich jetzt einfach so ergänzen, dass da dann drin steht:
PHP_VALUE mbstring.func_overload 0
RewriteEngine On
RewriteBase /blog/
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /blog/index.php [L]
-> und dann brauch ich die neue streams.php nicht hochzuladen oder auch noch? Sorry für die Unklarheit meinerseits
Antworten »
codestyling
11.08.2008 | 13:21Genauso ist das gedacht. Die geänderte streams.php solltest du solange weiter benutzen, um sicherzustellen, das im Falle dein Provider stellt wieder mal was um, das automatisch korrekt läuft. Der von mir hier bereitgestellte Patch wird in etwas abgewandelter Form mit WP 2.6.1 erscheinen, denn das Core Team hat dies bestätigt und eingebaut.
Nur der Fall deines Providers stellt eine Sonderrolle dar, denn hier reicht das allein nicht aus. Es gab einige andere Nutzer, die das mit dem Provider klären wollten. Ich selbst kann nicht viel machen, denn ich hoste wo anders
Antworten »
Specu2
13.08.2008 | 12:54Für alle Leigeplagten, hier die Lösung für das Problem: PHP5 auf die Version 4 umzuwandeln : Link
Auch ich hoste bei all-inkl.com und nun erscheint der Fehler nicht mehr.
Antworten »
codestyling
13.08.2008 | 13:21Das ist leider keine Lösung, denn die Provider werden definitiv bald kein PHP4 mehr anbieten, denn der Supportzyklus ist beendet ! Somit erscheint spätestens dann das Problem wieder.
Es ist meiner Meinung nach Aufgabe des Provider all-inkl.com das zu lösen, denn alle anderen Provider haben dieses Problem nicht. Und der Fall, das PHP so konfiguriert ist, das alle Stringfunktionen mit mb_* Versionen überladen werden, ist ja nun behoben und ab WP 2.6.1 offiziell enthalten.
Antworten »
Paul
13.08.2008 | 20:43Woah! Vielen Dank! Bin ebenfalls bei All-Inkl. und habe immer wieder mit diesem Problem zu kämpfen gehabt. Dank des Einfügens von PHP_VALUE mbstring.func_overload 0 in die .htaccess funktioniert nun alles, zumindest mit der englischen Sprachversion
Ich werd das nachher noch einmal mit der deutschen Sprachdatei probieren, hoffentlich geht auch da alles glatt.
Antworten »
Paul
13.08.2008 | 21:18Auch das funktioniert
Wirklich, tausend Dank!
Antworten »
Paul
13.08.2008 | 22:14Kommando zurück. Mit der deutschen WP-Version tritt der Fehler immer noch auf, mit dem Unterschied dass nun die Zeile 98 in der streams.php genannt wird statt bisher die Zeile 66.
Naja… Mal sehen, vielleicht wird das mit der 2.6.1. besser.
Antworten »
codestyling
13.08.2008 | 22:24Die WP 2.6.1 enthält im Grunde das gleiche, was ich hier schon als Fix zum Download anbiete, nur anders aufgeschrieben. Wenn du also mit dem o.g. Fix das Problem nicht lösen kannst, wird es die WP 2.6.1 ebenfalls nicht lösen. Es ist ein Problem, das nicht mit WP direkt zu tun hat, sondern durch die Konfiguration von Apache und PHP zustande kommt. Leider eben nur auf diesen Provider beschränkt.
Da ich nicht dort hoste, kann ich auch nicht viel mit dem Provider klären, denn sie haben ein immanentes Problem in ihren Servern, wenn das nicht funktioniert.
Antworten »
Paul
14.08.2008 | 07:54Ok, dann werde ich mich mal an All-Inkl. wenden. Vielleicht bringt das ja was …
Antworten »
ChristianB
14.08.2008 | 17:56An alle all-inkl.com Nutzer: Ich habe das Angebot des Supports angenommen und bin auf einen ruhigeren Server umgezogen. Das hat mein unpack-Problem erstmal beseitigt. Ich weiß das ist nur eine Zwischenlösung.
Für alle noch immer leidgeplagten hier mal ein Tip zum ausprobieren. Den Patch von oben installieren und in der .htaccess Datei folgende Zeilen am Anfang einfügen:
PHP_VALUE magic_quotes_runtime OffPHP_VALUE mbstring.func_overload 0
Dann noch ein paar Tage warten ob das Problem weiterhin auftritt. Bei mir war nach dem Patch auch erstmal 2 Tage ruhe und dann kam es wieder zurück.
Antworten »
Brusdeylins
15.08.2008 | 23:53Hi,
vielleicht auch Interessant:
ich hab drei WP-Installationen in der Version 2.3.1 und die laufen tadellos mit deutscher Datei. Sobald ich auf 2.5 ++ umstelle erscheint der Fehler wieder…
Bin auch bei All-Inkl und hab PHP 5…
Hoffen wir, dass das heutige WP-Patch 2.6.1 diesen Fehler komplett besiegt hat…
Antworten »
codestyling
17.08.2008 | 20:47Da befürchte ich, dass es keine Lösung für das all-inkl.com geben wird, denn der Fix in WP 2.6.1 ist der gleiche, nur anders in Code aufgeschrieben, wie der hier zum Download angebotene.
Antworten »
Paul
16.08.2008 | 15:45Hilft bei mir leider überhaupt nicht.
Antworten »
codestyling
17.08.2008 | 20:51Wenn die diesen Patch bzw. WP 2.6.1 meinst, wird das für all-inkl.com nicht helfen. Es gibt ein konfiguratives Problem bei diesem Hoster, dass ich so nicht lösen kann, denn ich hoste da nicht. Alle anderen Provider haben diese Probleme nicht. ich habe aber im Kommentarverlauf hier schon mehrfach die zusätzlichen Probleme erwähnt, die dazu führen können, das dies auch auftritt, nur nachweisen kann ich es leider nicht.
Antworten »
Rix
18.11.2008 | 19:06Auch von mir ersteinmal herzlichen Dank
Wollte dazu erwähnen dsa ich gerade belastungstest für 2.7 beta1 mache und der fehler bei mir aufgetreten ist.
Die Datei ist in der neuen Beta auch nicht dabei.
Habe deine aktuelle streams.php hochgeladen und der fehler ist behoben.
nur so mal zur Info
LG Rix
Antworten »
Rix
18.11.2008 | 20:04sry ich nehm alles zurück…. es funktioniert nur teilweise mal ….
Antworten »
Jan
26.12.2008 | 18:10Hallo,
danke schon mal für deine Mühen. Kannst du evtl. mal den Link zum entsprechenden Wordpress TRAC-Ticket weitergeben, da ich das Problem auch mit Version 2.7 habe - allerdings nur, wenn ich meine DE-Domain auf den Account aufschalten lasse. Bisher lief alles ohne Probleme, nun kommt aber folgende Fehlermeldung:
Fatal error: Allowed memory size of 16777216 bytes exhausted (tried to allocate 71 bytes) in .../html/wp-includes/gettext.php on line 91Gruß
Jan
Antworten »
codestyling
27.12.2008 | 11:37Für WP 2.7 sind 16MB Memory Limit leider ein wenig zu gering, denn durch die vielen Änderungen und neuen Funktionen ist WP zuiemlich viel “dicker” geworden. Zusätzlich verstärken die Plugins, die geladen sind, das Problem noch. Da hilft nur das Limit anzuheben in der wp-config.php mit:
int_set(@ini_set("memory_limit",'32M');oder
define('WP_MEMORY_LIMIT', '32M');oder speziell bei Strato eine php.ini Datei im Rootverzeichnis anlegen, die folgenden Inhalt hat:
memory_limit = "32M"Dann sollte es auch mit der Sprachdatei funktonieren.
Antworten »
matthias
19.01.2009 | 14:15Hi,
habe verschiedene Wordpressinstallationen 2.3 und 2.7, bei denen genau der beschriebene Fehler auftaucht:
] PHP Warning: unpack(): Type V: not enough input, need 4, have 0 in /srv/www/vhosts/falkenhagener-feld-west.de/httpdocs/wordpress/wp-includes/gettext.php on line 85 usw.
mbstring.func_overload ist in der php.ini auf Null gestellt, die Patches für die stream.php haben nichts bewirkt. Nur die Zeile set_magic_quotes_runtime(0); in der wp-config zeigt Wirkung. Zwar gibt es immer noch die Error-Logs, aber Besucher bekommt es nicht mehr mit, denn die Seiten werden nun trrotzdem sehr schnell geladen. Das heißt der Fehler ist immer noch nicht gelöst, auch in wp 2.7. nicht.
Schönen Gruss und vielen Dank für Deine Arbeit
Matthias
Antworten »
codestyling
19.01.2009 | 14:21Kannst du mir ein error.log zur Verfügung stellen, denn mich würde interessieren, was da jetzt noch als Fehler drin steht.
Mit WP hat das erstmal nix zu tun, das ist eine PHP/Server Sache, die nur in WP so gut es geht abgefangen wird. Jedoch kann man nicht alle Servereinstellungen kennen oder abfangen, wenn es auf dem eigenen System nicht passiert.
Antworten »
matthias
19.01.2009 | 21:05Hi,
habe das Error-Log heut nachmittag per Mail geschickt.
Gruss
Matthias
Antworten »
codestyling
20.01.2009 | 02:40Ist in Analyse, melde mich umgehend dazu. Danke für dein Verständnis, wenn es evtl. ein paar Stunden länger dauert, mein Zeitbudget ist derzeit mehr als knapp bemessen.
Antworten »
ChristianB
21.01.2009 | 18:23Hi matthias,
bei welchem Hoster bist du denn und was für eine PHP version hast du laufen? Ich bin bei all-inkl.com und habe das Problem mit der php5-cgi Version gelöst. Das ist nur ein einfacher Eintrag in der .htaccess Datei.
Antworten »
codestyling
21.01.2009 | 18:28Ist auch eine Lösung, nur warum auf Speed verzichten (cgi ist nun mal langsamer). Ich bin immer noch dabei, eine Testumgebung zu erstellen, die mit dem Logfile und den Servereinstellungen übereinstimmt.
Denn ich mag es überhaupt nicht, wenn die Ursache eines Fehlers nicht bekannt ist, denn das kan u.U. auch Schlimmeres nach sich ziehen (Angriffslücken).
Antworten »
Magda
22.03.2009 | 23:10Guten Abend,
jetzt muss ich mich auch einmischen. Seit gerade mal 2 Wochen betreibe ich einen Blog bei WP angelegt über Strato (leider Version 2.5). Am Freitag habe ich mich rangetraut diese abzudaten. Nun tritt dieser Fehler bei mir auch auf :-((( Deinen Patch habe ich geladen und ausgetauscht, OHNE ERFOLG! Ich weiß nicht mehr weiter! Bitte um Hilfe! Was kann ich noch ändern damit mein Blog endlich wieder funktioniert? In den Adminbereich komme ich ohne Probleme rein.
Liebe Grüße
Magda
Antworten »
codestyling
23.03.2009 | 19:14Der Blog hat eine endlos Umleitung. Das scheint die Konfiguration der “Einstellung” -> “Allgemein” was die Blog URL’s betrifft nicht zu stimmen. Solange dies nicht bereinigt ist, kann ich schwer einschätzen was schief läuft.
Antworten »
Magda
23.03.2009 | 21:49hmm… der Blog hat vorher aber tadellos funktioniert. Wo könnte ich das denn ändern? Strato selbst kann/will nicht weiter helfen.
Antworten »