Probleme mit gettext

Vor ge­rau­mer Zeit be­geg­ne­te ich im­mer wie­der ei­ner ner­vi­gen Fehlermeldung:
Warning: un­pack() [function.unpack]: Type V: not en­ough in­put,
need 4, have 0 in /***/wp-includes/gettext.php on li­ne 85

Hierbei han­delt es sich um PHP-Dateien ei­ner WordPress-Installation (Version 2.2.3 DE und Version 2.3 DE). Unter Unix ist GNU get­text ei­ne weit ver­brei­te­te Bibliothek. Sie macht im Grunde nichts an­de­res, als ei­nen über­ge­be­nen “ori­gi­na­len” String (in der Regel ein eng­li­scher Text) in ei­nen ent­spre­chen­den String ei­ner an­de­ren Sprache zu über­set­zen. Das Mapping zwi­schen die­sen Strings be­fin­det sich in so ge­nann­ten MO-Dateien (z.B. “de_DE.mo”). Auch WordPress setzt sol­che Dateien für die Übersetzung ein.

(Gelöst mit WordPress 2.6.1 – Details wei­ter un­ten…)
PHP könn­te di­rekt mit gettext-Support kom­pi­liert wer­den. Dadurch stün­den ent­spre­chen­de Funktionen di­rekt zur Verfügung. Doch wür­de solch ein Programm nicht auf ei­nem Rechner oh­ne ent­spre­chen­de Unterstützung lau­fen. Aus die­sem Grund wur­de in WordPress das Projekt PHP get­text in­te­griert. Die Implementierung liegt in den Dateien “gettext.php” und “streams.php” im “wp-includes”-Verzeichnis. WordPress er­hält da­durch die Fähigkeit die­se MO-Dateien ein­zu­le­sen. Doch ge­nau hier ent­stan­den ab und zu Probleme.

Betrachtung des Problems

Die oben dar­ge­stell­te Fehlermeldung kam bei mir spo­ra­disch. Und ich ken­ne die Fehlerstelle ge­nau. Sie be­fin­det sich in der Datei “streams.php” in der Klasse StringReader. Und dort in der Funktion read($bytes). Hier lie­fer­te die Zeile $da­ta = substr($this->_str, $this->_pos, $bytes); nicht im­mer den rich­ti­gen Teilstring zu­rück. Manchmal war der Inhalt ge­nau um ein Byte ver­scho­ben. Dadurch wur­den in der Datei “gettext.php” in der Funktion gettext_reader(…) Strukturinformationen ei­ner MO-Datei falsch in­ter­pre­tiert, was wie­der­um da­zu führ­te, dass Mengenangaben kom­plett falsch ein­ge­le­sen wur­den. In solch ei­nem Fehlerfall wur­de die seek­to() Funktion mit ei­nem gro­ßen ne­ga­ti­ven Wert auf­ge­ru­fen, was da­zu führ­te, dass der Stream-Positionszeiger an das Ende der Daten ge­setzt wur­de. Dadurch lie­fer­te je­der wei­te­re Aufruf der Lesemethode ei­nen Leerstring zu­rück. Und ge­nau solch ein Leerstring wur­de der Methode un­pack() in der Datei “gettext.php” in der Zeile 85 über­ge­ben, was zu der oben be­sag­ten Meldung führ­te.
Es ist zwar nicht wirk­lich ei­ne Lösung, doch hat­te ich die oben be­nann­te Codezeile tem­po­rär mit fol­gen­den Kommandos aus­ge­tauscht:
Alter Code:

$da­ta = substr($this->_str, $this->_pos, $bytes);

Neuer Code, der im­mer den rich­ti­gen Teilstring er­mit­telt:

$da­ta = "";
for ($i=0; $i<$bytes; $i++) {
    $da­ta .= $this->_str[$this->_pos+$i];
};

Gibt man hier noch ei­ne Meldung aus, so­bald die bei­den er­mit­tel­ten Teilstrings un­ter­schied­lich sind, dann merk­te man, dass die­se gleich­zei­tig mit dem hier be­schrie­be­nen Fehler auf­tauch­te. Verglich man die Inhalte, sah man, dass bei ei­ner Startposition > 0 der Teilstring aus sub­str() um ein Zeichen/Byte ver­scho­ben war. Statt z.B. den Inhalt von Index 4-7 zu er­mit­teln, lie­fer­te die­se Methode dann die Zeichen 5-8. Wohl be­merkt, dies aber nur sehr spo­ra­disch!
Eigentlich ei­ne fa­ta­le Sache, wenn ein re­gu­lä­rer PHP-Befehl Probleme ver­ur­sacht. Dieser Befehl, der Teile aus ge­ge­be­nen Texten ex­tra­hiert, kommt in WordPress häu­fi­ger zum Einsatz. Am sicht­bars­ten ist er in Kombination mit der Datei “gettext.php”, da hier ein Fehler ge­wor­fen wird. Aber mir ist eben­falls auf­ge­fal­len, dass es auch Probleme mit dem Abspeichern ge­schrie­be­ner Inhalte gab. Hier kam es vor, dass an Stellen ein­ge­bun­de­ner Steuercodes (Links, Code-Tags) Teile des Inhaltes ver­schwan­den. Man be­merk­te die Fehlersituation, da der be­rühm­te gettext-Fehler auf­trat. Aus die­sem Grund ließ ich die oben be­schrie­be­nen neu­en Codezeilen auch nicht in mei­ner Installation. Mir sind mit die­sem Code schon Inhalte ver­schwun­den, oh­ne dass ich dies so­fort be­merk­te.

Lösungswege

Auf je­den Fall muss­te die Problemursache an ei­ner Server-Konfiguration oder –Komponente lie­gen. Ich ver­wal­te noch ei­ne wei­te­re WordPress-Webseite und dort be­kam ich noch kei­ne Fehler. Zu er­wäh­nen ist auch, das bei­de Seiten beim glei­chen Provider ge­hos­tet wer­den, die glei­che PHP-Version in­stal­liert war und in­zwi­schen bei bei­den WordPress in der Version 2.3 vor­lag.
Meine tem­po­rä­re Lösung be­stand dar­in, dass ich auf mei­ner Seite die ori­gi­na­le eng­li­sche Version von WordPress in­stal­lier­te. Somit trat der Fehler sel­te­ner auf, da ei­ne Sprachdatei we­ni­ger ein­ge­le­sen wer­den muss­te. Er ver­schwand aber nicht kom­plett, weil noch PlugIns mit Sprachdateien in­stal­liert wa­ren. Dies mach­te sich dann aber eher im Admin-Bereich, vor al­lem beim Speichern der Beiträge be­merk­bar.
Dank dem schnel­len und mo­ti­vier­ten Support mei­nes Providers All-Inkl.de dach­ten wir zu­erst, dass wir den Fehler ein­däm­men konn­ten. Der ers­te Versuch be­stand dar­in, den ZEND-Optimizer zu in­stal­lie­ren und wei­te­re PHP-Parameter an den Parametern des Servers mei­ner an­de­ren WordPress-Präsenz an­zu­pas­sen. Leider oh­ne dem ge­wünsch­ten Ergebnis. Ein Update der PHP-Installation von der Version 5.2.3 auf 5.2.4, so­wie die Aktualisierung der Apache-Installation von der Version 2.2.4 auf 2.2.6 lie­ßen den ner­vi­gen Fehler dann kurz­zei­tig doch ver­schwin­den. Vermutlich be­sitzt sub­str() in PHP 5.2.3 nicht die er­hoff­te Stabilität.
Update 24.10.07:
Das Problem tritt seit heu­te lei­der wie­der auf! Womöglich lag es doch nicht an der al­ten PHP-Version. Ich ver­fol­ge das wei­ter…
Update 30.10.07:
Das ist scha­de, aber auch das Update auf WordPress 2.3.1 DE brach­te nicht den er­hoff­ten Erfolg. Wir sind lei­der so lang­sam am Ende mit dem Suchen, auch mit der Geduld. Der nächs­te Schritt be­steht wohl dar­in, mei­nen Webspace in­ner­halb mei­nes Providers auf ei­nen an­de­ren Server zu ver­schie­ben. Zur Zeit ha­be ich die Datei “/wp-includes/languages/de_DE.mo” ent­fernt, da­mit der Fehler nicht mehr so häu­fig auf­tritt.
Update 03.11.07:
Mein Provider All-Inkl hat nun mei­ne Webseite auf ei­nen an­de­ren Server in­stal­liert. Seit dem scheint die Webseite oh­ne Probleme zu funk­tio­nie­ren. Schade ist nur, dass wir nun nicht ge­nau wis­sen, wel­che Server-Einstellung / Hardware-Kombination hier wohl Probleme mit der Funktion sub­str() aus PHP 5 ver­ur­sacht.
Update:
Der Fehler taucht wie­der auf…
Update 15.11.07:
Heute wur­de PHP 5.2.5 auf dem Webserver in­stal­liert. Laut All-Inkl bin ich der Erste, der die­se Installation tes­ten darf. Ich lau­fe nun auch wie­der auf der ori­gi­na­len deut­schen Version. Bis jetzt sind mir noch kei­ne Probleme be­geg­net. Die Zeit wird zei­gen, ob das die Lösung war…
Update 26.02.08:
Im Kommentar Nr. 48 be­rich­tet Niko_K, dass das Problem wohl durch nicht über­ein­stim­men­de Spracheinstellungen zwi­schen der WordPress-Configuration und dem Linux-System (Variable LANG) auf­tritt. Danke!
Ich ver­mu­te stark, dass PHP-String-Funktionen wie das sub­str() wohl ab­hän­gig von den Systemeinstellungen sind und so­mit mit den rich­ti­gen Daten be­füt­tert wer­den müs­sen.
Update 25.04.08:
Im Kommentar Nr. 60 be­rich­tet Kretzschmar dar­über, dass der Fehler un­ter PHP 4 nicht mehr auf­taucht. Die Umstellung von PHP 5 auf PHP 4 kann beim Provider All-Inkl wohl selbst vor­ge­nom­men wer­den.
Ubdate 24.06.08:
Der Bug ist in­zwi­schen schon bei WordPress re­gis­triert (Bug 5599 – dan­ke an Codestyler für den Hinweis). Hier wird ak­tu­ell ei­ne Alternative zu sub­str() ein­ge­setzt. Diese Lösung ist ele­gan­ter als die oben be­schrie­be­ne. Leider ist die kor­ri­gier­te Stelle nicht die ein­zi­ge mit dem Befehl sub­str(), wes­we­gen man trotz­dem ein Fehlverhalten bzw. Datenverlust in der Anwendung er­war­ten kann.
Update 15.08.08:
Endlich! WordPress 2.6.1 lie­fert nun ein Bugfix zu die­sem Problem. Der Fehler tritt auf, so­bald man in der php.ini den Eintrag mbstring.func_overload auf ei­nen an­de­ren Wert als 0 stellt. Meist er­lau­ben die Provider es, die­sen Wert für die ei­ge­ne Web-Präsenz zu än­dern. Ein Bug im Apache-Modul mod_php sorgt al­ler­dings bei die­ser Art der Umstellung da­für, dass sie für al­le V-Hosts des Servers gilt! Sobald al­so ein User des glei­chen V-Hosts an die­ser Einstellung dreht, er­schei­nen bei den an­de­ren WordPress-Präsenzen auf dem Server wohl die­se Fehler, zu­min­des bis ei­ne an­de­re Präsenz die­sen Wert wie­der auf 0 stellt. Näheres hier­zu un­ter code-styling.de.

Native Lösung

Es lief ei­ni­ge Tage gut, nun sind seit heu­te (06.11.2007) al­le WordPress-Seiten auf dem neu­en Server wohl auch be­trof­fen…
Im deutsch­spra­chi­gen WordPress-Forum bin ich nun auf ei­ne wei­te­re Lösung ge­sto­ßen: Einsatz des ori­gi­na­len get­text() Kommandos. Diese Lösung kann lei­der nur dann an­ge­wen­det wer­den, wenn get­text auf dem ent­spre­chen­den Server in­stal­liert ist. Ein Blick in die PHP-Info lie­fert hier­zu Informationen:
GetText Support en­ab­led
Worin be­steht die Lösung? In der WordPress-Datei /wp-includes/l10n.php wird die WordPress-Version von get­text() auf­ge­ru­fen. Der Code wird nun so ge­än­dert, dass die in­stal­lier­te Funktion get­text() an­stel­le der pro­ble­ma­ti­schen gettext-Vertretung auf­ge­ru­fen wird. Dazu muss die Sprachdatei /wp-includes/languages/de_DE.mo zu wordpress.mo um­be­nannt und in ein neu­es Verzeichnis ko­piert wer­den. Der Name des Verzeichnisses ist ab­hän­gig von der ein­ge­stell­ten Codierung in der Datei wp-config.php:
Eine Sprachdefinition de­fi­ne (‚WPLANG‘, ‚de_DE.UTF-8‘); be­nö­tigt das Verzeichnis wp-includes/locale/de_DE.UTF-8/LC_MESSAGES/.
Lautet die Sprachdefinition de­fi­ne (‚WPLANG‘, ‚de_DE‘); muss das Verzeichnis den Namen wp-includes/locale/de_DE/LC_MESSAGES/ tra­gen.
Wenn man will, kann man in der Datei wp-settings.php die Zeilen
include_once(ABSPATH . WPINC . ‘/gettext.php’);
include_once(ABSPATH . WPINC . '/streams.php');
aus­kom­men­tie­ren und die Dateien gettext.php und streams.php lö­schen.
Damit die Umstellung schnell voll­zo­gen wer­den kann, hab ich für WordPress 2.3.1 Deutsch ein klei­nes ZIP-File mit al­len nö­ti­gen Änderungen er­stellt:
Native_gettext_WordPress_2.3.1.zip
ACHTUNG:
hier bit­te auf die rich­ti­ge Codierung ach­ten, da­mit beim Posten kei­ne Inhalte ver­lo­ren ge­hen. Am Besten vor­her ein Backup der Datenbank an­le­gen. Wenn ei­ne an­de­re WordPress-Version un­ter­stützt wer­den soll, dann ein­fach die Sprachdateien aus dem ZIP-File ent­spre­chend der obi­gen Anleitung selbst ge­ne­rie­ren.
Und nicht ver­ges­sen: so­mit ist das Anzeige-Problem ge­löst, der Fehler taucht nicht mehr auf, aber es gibt noch vie­le an­de­re substr()-Aufrufe, wel­che schief lau­fen kön­nen. Auffällig ist da­bei Datenverlust an den Steuer-Tags aus der Code-Ansicht.

78

Kommentare

  1. probek  Oktober 26, 2007

    Ich ha­be das Problem auch. Und dass Du das auch mit ei­nem Update auf WP 2.3 nicht hin­be­kom­men hast, macht mir Sorgen, da ich das bis­her als Lösungsweg sah.
    Liegt es denn si­cher an ei­nem „deut­schen“ Problem, d.h. an der de-Version von WordPress bzw. an deutsch­spra­chi­gen Plugins, d.h., wenn ich auf die eng­li­sche WordPress-Version zu­rück­grei­fe und kei­ne deutsch­spra­chi­gen Plugins mehr in­stal­liert ha­be, geht’s wie­der? Und wie be­kom­me ich das hin?
    Oder kann der Provider was ma­chen? Wäre auch nett, wenn man im deut­schen WordPress-Forum mehr da­zu le­sen könn­te. Aber wenn Du hier die Lösung fin­dest, wä­re mir/uns/vermutlich auch an­de­ren auch schon ge­hol­fen.

    antworten
  2. probek  Oktober 26, 2007

    Lustigerweise (na­ja, wenn man’s lus­tig fin­det) ist ge­ra­de auch beim Absenden des obe­ren Kommentars die Fehlermeldung er­schie­nen…

    antworten
  3. Matthias Brusdeylins  Oktober 27, 2007

    Der Fehler taucht wohl in der sub­str() Funktion von PHP 5 auf (oder hast du noch PHP 4.x in­stal­liert?)… Und die­se wird häu­fig bei der Übersetzung der Texte auf­ge­ru­fen. Deswegen ist hier wohl die Wahrscheinlichkeit des Auftretens ei­nes Fehlers er­höht.
    Ob es sich hier um ei­nen Folgeeffekt ei­nes noch un­be­kann­ten Problems han­delt ist mir un­klar. Fakt ist, dass ich noch ei­nen wei­te­ren Webspace mit WP 2.3 DE beim glei­chen Provider ha­be. Und hier er­scheint die­ser Fehler nicht!
    Wenn man die Übersetzungen un­ter /wp-includes/languages/de_DE.mo ent­fernt, soll­te schon das Problem stark re­du­ziert sein. Ansonsten kann man ein­fach al­le PHP-Dateien (Ausnahme wp-config.php, .ht­ac­cess uns sons­ti­ge ei­ge­ne Dateien/Verzeichnisse) mit der eng­li­schen Version von WordPress er­set­zen.
    Die Datenbank-Struktur in­ner­halb der glei­chen Version ist zwi­schen der deut­schen und eng­li­schen Version gleich. Wenn man auf 2.3 Updaten willst, fin­dest sich un­ter der ent­spre­chen­den WordPress-Seite die Anleitung zum Updaten.
    Zurzeit lauf ich noch auf der deut­schen Version, um den Fehler bes­ser zu be­ob­ach­ten. Sollte ei­ne Lösung al­ler­dings nicht bald ge­fun­den wer­den, spie­le ich die eng­li­sche Version wie­der auf.

    antworten
  4. Kretzschmar  November 1, 2007

    Ich bin eben­falls von die­ser ner­vi­gen Fehlermeldung ge­plagt. Vor der deut­schen Version 2.3 ist sie nie auf­ge­tre­ten.
    Vieleicht liegt es ja doch an all-inkl. Ich bin näm­lich eben­falls dort auf php5 ge­hosted.

    antworten
  5. probek  November 2, 2007

    Bin nicht bei All-Inkl, ha­be PHP5 und in­zwi­schen die neu­es­te WordPress-Version – und bin im­mer noch be­trof­fen. Wir sind üb­ri­gens nicht al­lei­ne – ei­ne Google-Suche nach der Fehlermeldung lie­fert ein paar schö­ne Treffer mit ge­ra­de be­trof­fe­nen Blogs. Kann man das Problem nicht in die of­fi­zi­el­le Fehlerliste von WordPress auf­neh­men?

    antworten
  6. Matthias Brusdeylins  November 2, 2007

    Vielleicht soll­te man den Fehler eher an die PHP-Entwickler wei­ter­lei­ten. Da doch die Methode sub­str() hier aus ir­gend­ei­nem Grund ver­sagt.
    Mein Provider All-Inkl hat nun den Umzug auf ei­nen an­de­ren in­ter­nen Server voll­zo­gen. Inzwischen läuft auch wie­der die deut­sche Version. Bisher sind mir kei­ne Fehler mehr be­geg­net, aber da will ich erst ein­mal noch ein biß­chen wei­ter­tes­ten, be­vor ich dies zu laut raus­schreie…

    antworten
  7. Michael  November 6, 2007

    Auf mei­ne Seite kom­men seit heu­te eben­falls die doo­fen Meldungen. Meine Seiten sind auch bei all inkl auf PHP5, ha­be mich so­fort bei de­nen kun­dig ge­macht. Und her­aus­ge­kom­men ist: „Das Problem liegt nicht bei All Inkl, son­der das es ein WordPress Fehler ist und das ich mich di­rekt an WodPress Entwickler rich­ten soll.“ Also soll­te der Fehler auf je­den Fall von WordPress be­ho­ben wer­den.

    antworten
  8. Thomas  November 8, 2007

    Da bei mir die deut­sche Sprachdatei nach ei­nem Serverumzug auf amd64 nicht mehr funk­tio­nier­te, ha­be ich auch die­se na­ti­ve Lösung ver­wen­det.
    Bleibt noch hin­zu­zu­fü­gen, dass man jetzt noch in wp-settings.php die Zeile

    include_once(ABSPATH . WPINC . ‚/gettext.php‘);

    aus­kom­men­tie­ren und die Datei gettext.php lö­schen kann.

    antworten
  9. Stephan  November 11, 2007

    Hallo zu­sam­men,
    schö­ner, zu­sam­men­ge­fass­ter Beitrag. Bin auch durch goog­le auf dein Posting ge­sto­ßen und eben­falls von dem Fehler be­trof­fen. Hatte den Fehler noch nie, bei kei­ner mei­ner WordPress Seiten… Heute das ers­te mal. Bin auch bei al­linkl auf php5 ser­ver… mal be­ob­ach­ten
    *book­mar­ked*

    antworten
  10. Matthias Brusdeylins  November 15, 2007

    PHP 5.2.5 wur­de nun in­stal­liert. Bis jetzt sieht es gut aus. Wir wer­den se­hen ob das die Lösung ist…

    antworten
  11. Kretzschmar  November 17, 2007

    Ich bin Dir ge­folgt und ha­be PHP ak­tua­li­sie­ren las­sen. Bei mir ist die Fehlermeldung ge­ra­de er­neut drei­mal er­schie­nen (auf mei­nem Blog). Bei Dir ha­be ich sie noch NIE ge­se­hen (auf die­ser Seite).
    Hast Du ei­ne Übersicht über Deine ver­wen­de­ten Plugins? Möglicherweise be­nut­zen wir ja bei­de ein Plugin, wel­ches NEBENBEI die­sen Fehler ver­ur­sacht?

    antworten
  12. Matthias Brusdeylins  November 18, 2007

    Hier mal mei­ne in­stal­lier­te Plugins:
    Akismet (2.0.2)
    Breadcrumb (0.5.1)
    Easy HTML Metadata (1.2) – mein Plugin
    Follow-URL (1.0)
    Gravatars2 (2.7.0)
    Lightbox JS v2.03.3 Plugin (1.7)
    NextGEN Gallery (0.72)
    o42-clean-umlauts (0.2.0)
    Role Manager (2.0.8)
    Search Pages (2.0)
    Simple Trackback Validation (2.1)
    Top Level Categories (1.0)
    Yet Another Advanced Paged Navigation (1.05)

    antworten
  13. Kretzschmar  November 18, 2007

    Ich ha­be al­le Plugins de­ak­ti­viert, die mit Deinen iden­tisch sind. Es hat aber nichts ge­hol­fen. Der Fehler tritt re­gel­mä­ßig auf. Mich wun­dert, dass er jetzt stän­dig auf­tritt, vor ein paar Tagen aber prak­tisch nicht.
    Ich bin ein we­nig ge­nervt.

    antworten
  14. Matthias Brusdeylins  November 19, 2007

    Also am Sonntag Abend hab ich ihn auch wie­der ge­habt! Ich ver­mu­te da eher Überlastungsprobleme…
    Womöglich Ausführungs-Speicher zu knapp…

    antworten
  15. Marc Köberlein  November 21, 2007

    Hatte auch bei dei­ner Seite heu­te ei­ni­ge Male die Meldung er­hal­ten. Hast du dei­nen letz­ten Lösungsvorschlag be­reits ein­ge­baut ?
    Scheint wohl die bit­te­re Realität zu sein, dass man ei­ni­ge Zeit mit dem Fehler le­ben muss.
    *seufz*

    antworten
  16. Matthias Brusdeylins  November 21, 2007

    Ich lau­fe wie­der im „deut­schen Original-Modus“, da ich tes­ten woll­te, ob das neue PHP-Update die Lösung war. Leider lief das ge­ra­de mal ei­ne Woche gut, dann ka­men die Fehler im­mer häu­fi­ger vor. Laut mei­nem Provider All-Inkl wur­de aber am Server nichts ge­än­dert. Doch ich hab nun fest­ge­stellt, dass mein Server wie­der auf PHP 5.2.3 läuft !!!

    antworten
  17. Kretzschmar  November 21, 2007

    Ich hat­te jetzt ei­ni­ge Zeit kei­ne Probleme mehr. Aber im­mer dann schlägt es er­bar­mungs­los zu. Nach der Ruhe kommt der Sturm. Ein Fehler jagt dann den nächs­ten und nie­mand kann sa­gen war­um.

    antworten
  18. Matthias Brusdeylins  November 22, 2007

    was sagt dein in­fo­php()? Läufst du noch auf PHP 5.2.5?

    antworten
  19. Matthias Brusdeylins  November 22, 2007

    Also seit heu­te bin ich wie­der auf ei­nem neu­en Server mit 65MB Memory-Limit (da­vor 40MB) und PHP 5.2.5… Eins muss man las­sen: mein Provider All-Inkl gibt sich echt Mühe!
    Jetzt heißt es wie­der: be­ob­ach­ten…

    antworten
  20. Kretzschmar  November 22, 2007

    Server- Einstellungen
    * Betriebssystem : Linux
    * Server : Apache/2.2.6
    * Speicherverbrauch : 17,23 MByte
    * MySQL Version : 5.0.45-community-log
    * SQL Modus : Nicht ge­setzt
    * PHP Version : 5.2.5
    * PHP Safe Mode : Aus
    * PHP Allow URL fo­pen : An
    * PHP Memory Limit : 65M
    * PHP Max Upload Size : 200M
    * PHP Max Post Size : 200M
    * PHP Max Script Execute Time : 30s
    GD Unterstützung
    * GD Version : bund­led (2.0.34 com­pa­ti­ble)
    * FreeType Support : Ja
    * FreeType Linkage : with fre­e­ty­pe
    * T1Lib Support : Ja
    * GIF Read Support : Ja
    * GIF Create Support : Ja
    * JPG Support : Ja
    * PNG Support : Ja
    * WBMP Support : Ja
    * XPM Support : Ja
    * XBM Support : Ja
    * JIS-mapped Japanese Font Support : Nein
    Ich ha­be seit ei­ni­gen Tagen kei­ne Probleme mehr. Schätze, dass all-inkl da et­was ge­än­dert ha­ben.

    antworten
  21. Matthias Brusdeylins  November 22, 2007

    Bei mir läuft es heu­te auch schon feh­ler­frei, so­weit ich das se­he. Die Parameter stim­men meist auch mit mei­nen über­ein. Ich den­ke echt, dass es an PHP 5.2.5 liegt, will es aber noch nicht laut raus schrei­en…
    Wie hast du dei­ne Liste er­mit­telt?

    antworten
  22. Kretzschmar  November 23, 2007

    Ich be­nut­ze NextGenGallery und im NGG Panel wer­den die­se Informationen aus­ge­ge­ben. Kein phpin­fo() not­wen­dig. Klasse. Ist über­haupt ei­nes der bes­ten Plugins für WordPress.

    antworten
  23. Kretzschmar  November 24, 2007

    Heute trat der Fehler wie­der auf (nach­dem ich Akismet wie­der ak­ti­viert hat­te). Versuch mal, ob es viel­leicht dar­an liegt.

    antworten
  24. Matthias Brusdeylins  November 24, 2007

    NextGenGallery und Akismet lau­fen bei mir auch…
    bist jetzt bin ich kei­nem Fehler mehr be­geg­net…
    Kam der Fehler bei dir trotzt PHP 5.2.5 oder wur­dest du da auch zu­rück­ge­stellt wie es bei mir war…

    antworten
  25. Kretzschmar  November 26, 2007

    Trotz 5.25. Komischerweise geht es jetzt. Ich bin trotz­dem oh­ne Hoffnung.

    antworten
  26. Kretzschmar  November 27, 2007

    Ich hat­te Recht, kom­me kaum auf mei­ne Seite heu­te. Muss im­mer wie­der neu la­den.

    antworten
  27. Matthias Brusdeylins  November 27, 2007

    Somit liegt die Lösung al­so auch nicht in PHP 5.2.5…
    Frag mal bei AllInkl nach, ob du an den be­stimm­ten Zeiten ir­gend ei­ne Überlastung auf dei­nem Server hast… hab ich auch ge­macht und es gab die­se wohl…

    antworten
  28. Kretzschmar  November 28, 2007

    Ich glau­be nicht an Überlastung. Denn manch­mal läuft es nach ei­nem re­l­oad wun­der­bar schnell wei­ter. Keine sicht­ba­ren Verzögerungen usw.
    Im SVN (WordPress 2.4 al­pha) ist die ge­patch­te gettext.php be­reits ent­hal­ten. Ich ha­be die­se Version eben­falls aus­pro­biert und er­hal­te den­noch die Fehlermeldung.

    antworten
  29. Matthias Brusdeylins  November 29, 2007

    Versuch mal die „Native Lösung“ mit UTF-8 wie oben be­schrie­ben. Die ha­be ich zur Zeit auf http://bcxp.de lau­fen. Wie es aus­sieht funk­tio­niert die ziem­lich gut… mach aber zur Sicherheit re­gel­mä­ßig DB-Backups… Ich hab kei­ne Ahnung, ob es noch an an­de­ren Stellen Probleme mit PHP5 gibt, die sich nicht gleich be­merk­bar ma­chen…

    antworten
  30. Kretzschmar  November 30, 2007

    Die na­ti­ve Lösung klappt bei mir zwar, al­ler­dings wird dann mein the­me nicht mehr get­text­ed.

    antworten
  31. Matthias Brusdeylins  Dezember 1, 2007

    Also die über­schrie­be­nen Übersetzungsfunktionen __() usw. in I10n.php wer­den ja wei­ter­hin auf­ge­ru­fen. Und wenn das neue Verzeichnis „lo­ca­le“ mit dem zur Konfiguration pas­sen­den Unterverzeichnis exis­tiert, die Sprachdatei aus „lan­guage“ ent­spre­chend um­be­nannt wird und dort ab­ge­legt wird, müss­te es ei­gent­lich ge­hen. Oder ver­wen­det dein Theme an­de­re Funktionen zum Übersetzten, die nicht aus I10n.php kom­men?

    antworten
  32. Stephan  Dezember 2, 2007

    Also ich hab bis­her auch noch kei­ne Lösung ge­fun­den und auch die im Forum er­wähn­te bringt mich nicht wei­ter.
    Hab mich heu­te auch mal an all-inkl ge­wandt, die mir als Lösungsansatz die­ses Blogpost emp­foh­len ha­ben 😉
    Bleibt nur zu hof­fen, dass der Fehler in WP2.4 be­ho­ben wird…

    antworten
  33. Matthias Brusdeylins  Dezember 5, 2007

    Geht bei dir die Native-Lösung nicht, weil du noch ein Theme-Language-File hast?
    Wenn ja, dann muss­te die­ses File wo­mög­lich ge­nau­so wie das Haupt-Language-File ein­bin­den…

    antworten
  34. Kretzschmar  Dezember 6, 2007

    Danke Matthias, du hat­test Recht. Bei mir klappt es jetzt. Ich bin den­noch nicht zu­frie­den, da ich nicht je­des Mal WordPress patchen möch­te. Wenn get­text von PHP nicht un­ter­stützt wird, führt dann ein Aufruf von ‚bind_textdomain‘ zu ei­ner Fehlermeldung?

    antworten
  35. Matthias Brusdeylins  Dezember 6, 2007

    So wie es aus­sieht, ist dies ei­nes der Funktionen, die du durch die Native-GetText-Integration da­zu be­kommst.
    http://www.php-homepage.de/manual/ref.gettext.php
    Es ist schon scha­de, dass hier WordPress nach je­dem Update ge­patcht wer­den muss, aber es bleibt wohl kei­ne an­de­re Lösung zur Zeit…

    antworten
  36. Kretzschmar  Dezember 9, 2007

    Immerhin ha­be ich seit der Änderung tat­säch­lich kei­ner­lei Fehler mehr.

    antworten
  37. Michael  Dezember 29, 2007

    Hiho du,
    ha­be das nun so ge­macht wie du be­schrie­ben hast. Hat al­les hin ge­hau­en, Seite ist jetzt gut, lei­der sieht sie nicht mehr gut aus! Bissle ver­scho­ben und NextGenGallery geht nicht mehr. Genau so ha­be ich nun kei­nen Editor mehr un­ter Schreiben Beitrag/Seiten!!! Womöglich ir­gend­was ver­hau­en…
    cu

    antworten
  38. Matthias Brusdeylins  Januar 18, 2008

    So wie ich das se­he geht’s auf dei­ner Seite wie­der. Was war das Problem?

    antworten
  39. Niko_K  Februar 10, 2008

    Hallo,
    ich ha­be mir ges­tern die deut­sche WP v. 2.3.3 in­stal­liert.
    Habe auch das be­schrie­be­ne (und an­schei­nend mit Verwendung durch das na­ti­ve get­text von php ge­lös­te) Problem.
    Jetzt ha­be ich die .zip file für v. 2.3.1 in­stal­liert (al­so die l10n.php er­setzt), dann in wp-settings.php die bei­den include_once aus­kom­men­tiert und die Sprachdateien in das lo­ca­le Verzeichniss (mit be­ach­te­ter Codierung aus der wp-config.php) ko­piert.
    Der Fehler tritt nun auch nicht mehr auf, ABER:
    Bei mir ist der Admin Bereich wie­der kom­plett in Englisch.
    Wo könn­te hier der Fehler lie­gen (bzw. wie fin­de ich den Fehler)?

    antworten
  40. Matthias Brusdeylins  Februar 10, 2008

    Welche PHP-Version läuft bei dir? Bei mir läuft die PHP Version 5.2.5 und WordPress 2.3.1 ori­gi­nal oh­ne Probleme. Die neue WP-Version muss ich hier ers­te sel­ber tes­ten…

    antworten
  41. Niko_K  Februar 10, 2008

    Hatte bis ges­tern noch 5.2.0 (re­lease weis ich lei­der nicht mehr)… ha­be dann ges­tern in der nacht aber noch ein up­date ge­macht.
    Jetzt be­kom­me ich per „php –ver­si­on“ fol­gen­des;
    PHP 5.2.5-0.dotdeb.2 with Suhosin-Patch 0.9.6.2 (cli) (build: Dec 10 2007 08:40:36)
    Ich ha­be per phpin­fo(); auch noch­mal ge­prüft, ob get­text wirk­lich „an“ ist… und es scheint al­les zu pas­sen (war mir da nicht mehr 100% si­cher)
    WordPress ist wie ge­sagt 2.3.3 DE
    Hoffe das hilft ein we­nig… wend du mehr Infos braucht, dann ein­fach fra­gen. Der Server steht hier pri­vat bei mir… soll heis­sen… dem Basteln sind (fast) kei­ne Grenzen ge­setzt!

    antworten
  42. Niko_K  Februar 24, 2008

    Ich ha­be heu­te end­lich wie­der ein we­nig Zeit ge­fun­den mich mit dem
    WordPress gettext-Problem zu be­schäf­ti­gen.
    Das Problem scheint nicht an der neu­en WordPress Version zu lie­gen.
    Ich ha­be heu­te in die translate-funktion der ver­än­der­ten l10n.php ei­nen log­ging out­put ein­ge­baut (ziem­lich simp­le… ein­fach den String vor und nach der Übersetzung durch get­text aus­ge­ge­ben) und al­lem Anschein nach funk­tio­niert bei mir der call zu get­text nicht rich­tig…
    Ich ha­be jetzt auch schon di­ver­se Versuche mit der Ordnerstruktur
    „wp-includes/locale“ hin­ter mir (ha­be da jetzt 4 Unterverzeichnisse…
    de_AT; de_AT.UTF-8; de_DE und de_DE.UTF-8… um auch wirk­lich ganz si­cher zu sein), aber lei­der er­folg­los. Als nächs­tes ha­be ich dann get­text auf der Shell aus­pro­biert. Auch hier ver­ste­he ich das Problem nicht ganz. Selbst ein „get­text -d locale/de_AT.UTF-8/LC_MESSAGES/wordpress.mo -s „%d to­pics“ über­setzt nicht rich­tig und gibt mir nur wie­der den ori­gi­nal­String „%d to­pics“ zu­rück. Ich ha­be das schon mit meh­re­ren text­do­mains ver­sucht (da ich nicht ge­nau weis, was hier rein soll; dar­un­ter „lo­ca­le“ und auch
    „locale/de_DE/“). Eine wei­te­re Vermutung war dann noch, dass ich ein Problem mit den .mo files selbst ha­be, aber al­les was ich hier nach­prü­fen kann sind die Zugriffsrechte und die sind okay (hat al­les www-data).
    Entweder ver­wen­de ich hier den Textbereich falsch, oder get­text über­setzt mit aus ir­gend­ei­nem Grund nicht. Vielleicht kennt ja hier je­mand die Lösung… ich den­ke jetzt mal, dass es ei­ni­ge gibt, die sich bes­ser mit get­text aus­kennst als MeinerEiner und ei­nen Tipp für mich ha­ben (hof­fent­lich, bit­te, bit­te…).
    An der PHP-Info kann es je­den­falls nicht lie­gen. Die sieht gut aus (get­text Support en­ab­led)
    LG,
    Niko

    antworten
  43. Matthias Brusdeylins  Februar 24, 2008

    Vielen Dank für dei­ne aus­führ­li­che Analyse. Sehe ich das rich­tig, bei dir geht we­der die PHP-WordPress-Version von GetText, noch die na­ti­ve Version (wel­che du auf der Shell ge­tes­tet hast)? Kann es an ir­gend­wel­chen Installations-Parametern, -Kombinationen oder -Versionen der Serverkomponenten lie­gen? Ich den­ke da­bei auch an die ZEND-Produkte. Ich kann das hier lei­der nicht sel­ber tes­ten.
    Die WordPress-Version läuft ja hier mit der sub­str() Funktion schief, was ich mir nicht er­klä­ren kann… (Schon mal den SubStr-Ersatz von oben aus­pro­biert?) Läuft dei­ne Umgebung auf den glei­chen Apache- und PHP Versionen wie bei mir (Bezug auf un­se­re Mail)? Inzwischen ha­be ich ja wie­der das ori­gi­na­le WordPress lau­fen und wohl kei­ne Probleme da­mit.

    antworten
  44. Niko_K  Februar 26, 2008

    Also die ver­wen­de­te PHP Version ist die sel­be. Ich selbst ver­wen­de Apache 2.2.3 (al­les als .deb Pakete von dot­deb bzw. von den Original Debian Quellen)
    Ich konn­ne in der dei­ne PHP-Info die Apache Version nicht fin­den, aber an­sosn­ten sieht al­les sehr ähn­lich aus

    antworten
  45. Matthias Brusdeylins  Februar 26, 2008

    Meine Apache-Version lau­tet: 2.2.6 (laut AllInkl) und die PHP-Version ist 5.2.5

    antworten
  46. Niko_K  Februar 26, 2008

    Dann wer­de ich am Wochenden mal ver­su­chen, den Apache Version 2.2.6 in­stal­lie­ren und nach­se­hen ob sich was än­dert (kann ich mir zwar nicht vor­stel­len aber pro­bie­ren geht über stu­die­ren)

    antworten
  47. Niko_K  Februar 26, 2008

    Juhu… hab das Problem nun durch ein we­nig her­um­pro­bie­ren lö­sen kön­nen.
    Es lag nicht an der Apache ver­si­on (ha­be noch kein Update ge­macht)
    Das Problem war wohl ei­ne Diskrepanz der Sprachen zwi­schen dem Linux-System selbst und WordPress. WP hat­te „de_AT“ ein­ge­stellt wäh­rend im System ein LANG=“de_AT.UTF-8″ ge­setzt war.
    Ich ha­be nun WP auf de_AT.UTF-8 ge­setzt (in wp-config.php) und nun funk­tio­niert die Übersetzung wie­der!
    BTW:
    Ich ha­be noch ein „locale-gen“ aus­ge­führt. Da das ja die lo­ca­les des Sytsems selbst über­setzt glau­be ich zwar nicht, dass es ei­nen Einfluss auf die Lösung hat, aber si­cher­heits­hal­ber will ich es doch er­wäh­nen.
    Das Kommandozeilen get­text ar­bei­tet bei mir im­mer noch nicht… aber ich glau­be wirk­lich, dass das an ei­nem feh­ler­haf­ten Aufruf mei­ner­seits liegt (ich fin­de lei­der kei­ne gu­te Anleitung im web oder auch in get­text selbst, die mir ge­nau sagt, was ich wie ver­wen­den kann…)

    antworten
  48. Matthias Brusdeylins  Februar 26, 2008

    Super! Danke für die Infos…
    Ich wer­de mal dei­nen Kommentar oben im Text er­wäh­nen.

    antworten
  49. probek  März 1, 2008

    Ist die Lösung ge­fun­den? Und kann je­mand den Lösungsweg so er­klä­ren, dass es auch ein Nicht-Programmierer ver­steht?
    Welche Lösung gibt es für Blog-Betreiber bei Shared Hosting? Ein Einfügen von (‚WPLANG‘, ‚de_AT.UTF-8‘) in wp-config.php führt bei mir da­zu, dass die WP-Admin-Oberfläche statt in Deutsch in Englisch er­scheint, das hilft mir al­so ver­mut­lich nur be­dingt wei­ter.

    antworten
  50. Matthias Brusdeylins  März 16, 2008

    Hi Probek,
    hast du es schon mal mit „de_DE.UTF-8“ ver­sucht?
    BTW: auf mei­ner Webinstanz läuft das WordPress 2.3.1 nun oh­ne ir­gend­wel­chen Tricks. Als Sprache steht bei mir „de_DE“ ein­ge­tra­gen. Ob der Provider hier was an­ge­passt hat, kann ich nicht sa­gen…

    antworten
  51. probek  März 27, 2008

    Bei „de_DE.UTF-8“ (schon pro­biert) wird mein Theme nicht über­setzt. Und den Fehler ha­be ich spo­ra­disch im­mer noch (was man schön über die Google Webmaster-Tools se­hen kann).

    antworten
  52. Matthias Brusdeylins  April 3, 2008

    Wenn du dich traust und ein Backup dei­ner Datenbank machst, kannst du ja mal ver­su­chen WordPress 2.5 zu in­stal­lie­ren… Aber prü­fe erst, ob all dei­ne Plugins auch den Versionssprung über­stan­den ha­ben…

    antworten
  53. Kretzschmar  April 6, 2008

    Ich ha­be be­reits WordPress 2.5 in­stal­liert. Der Fehler tritt bei mir ab und an im­mer noch auf. Diese Probleme ha­be ich al­ler­dings nur bei all-inkl. Andere Installationen funk­tio­nie­ren ein­wand­frei.
    Ich ha­be mitt­ler­wei­le auch ei­ne kom­plett neue Datenbank an­ge­legt und al­le Beiträge ex­por­tiert und in die neue im­por­tiert. Ein Datenbankproblem ist al­so eher un­wahr­schein­lich.
    Auch tritt der Fehler oh­ne Plugins auf.

    antworten
  54. Matthias Brusdeylins  April 6, 2008

    Da scheint es bei dei­nem All-Inkl-Server wohl ir­gend ein Konfigurationsproblem zu ge­ben… Sprache oder Codierung (UTF8 ?)… Schade dass man da nicht selbst nach­prü­fen kann… Wie schon ge­sagt, ich bin auch bei All-Inkl und hab kei­ne Probleme mehr…

    antworten
  55. Holger  April 10, 2008

    Hi Matthias,
    ich ha­be das glei­che Problem (üb­ri­gens eben­falls all-inkl.), und ha­be Deine na­ti­ve Lösung aus­pro­biert. Es scheint zu klap­pen, al­ler­dings be­kom­me ich nun im Backend beim Aufruf des Reiters „Verwalten“ (WP 2.5) fol­gen­de Fehlermeldung:
    Fatal er­ror: Call to un­de­fi­ned func­tion __ngettext_noop() in /www/htdocs/w009abf0/wp-admin/includes/post.php on li­ne 522
    Was kann denn hier pas­siert sein?
    Grüße

    antworten
  56. Nikolaus Krismer  April 14, 2008

    Hallo die Runde,
    al­so ich ha­be heu­te ein Update auf Version 2.5 durch­ge­führt… und… man mag es kaum glau­ben… es geht wie­der nix mehr.
    Also:
    Nach dem ers­ten Versuch mit dem WordPress „in­ter­nen“ Mechanismus die Page über­set­zen zu las­sen (ein­fach in der wp-config.php als WP_LANG de_DE an­ge­ben) be­kam ich nen Fehler, dass gettext.php und in wei­ter­ter fol­ge auch stream.php zu lan­ge brau­chen (ich weis die ge­nau Fehlermeldung nicht mehr… aber Apache me­ker­te im error.log, dass mehr als 60sec be­nö­tigt wur­den… nach­dem der Server hier mein ei­ge­ner is… sehr we­nig Applikationen drauf lau­fen und auch die Hardware recht neu ist, bin ich mir si­cher, dass es nichts nützt den timeout-wert nach oben zu set­zen)
    Mit dem hier vor­ge­schla­ge­nen Mechanismus, der mich ja schon in Version 2.3.3 ei­ni­ges an Nerven ge­kost­tet hat (sie­he oben), funk­tio­niert das Übersetzen… dach­te ich… al­so:
    Das Frontend (Datumsangeben, etc.) wer­den pro­blem­los über­setzt. Nur im Backend is das al­les nicht soo su­per. Erstens wer­den nicht al­le Strings über­setzt (ja ich ha­be die neue Sprachdatei der Version 2.5 in das LC_MESSAGES Verzeichnis ko­piert und ver­wen­de nicht mehr die al­te Sprachdatei der Version 2.3.3) und zwei­tens kann ich dann man­che Seiten gar nicht mehr öff­nen (be­kom­me ei­ne lee­re Seite). Den Fehler hier­bei konn­te ich noch nicht fin­den…
    …aus Gründen der Verzweiflung wer­de ich WordPress wohl erst mal ei­ni­ge Zeit auf eng­lisch ver­wen­den.
    LG,
    Niko

    antworten
  57. Matthias Brusdeylins  April 15, 2008

    Schade dass es so vie­le Probleme gibt…
    Hier mal mei­ne Parameter aus der wp-config.php:
    define(‚DB_CHARSET‘, ‚utf8‘);
    define(‚DB_COLLATE‘, “);
    de­fi­ne (‚WPLANG‘, ‚de_DE‘);
    Aus der PHP-Info:
    HTTP_ACCEPT_CHARSET: ISO-8859-1,utf-8;q=0.7,*;q=0.7
    Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
    _SERVER[„HTTP_ACCEPT_CHARSET“]: ISO-8859-1,utf-8;q=0.7,*;q=0.7
    default_charset: no va­lue – no va­lue
    iconv sup­port: en­ab­led
    iconv im­ple­men­ta­ti­on: glibc
    iconv li­bra­ry ver­si­on: 2.4
    iconv.input_encoding: ISO-8859-1 – ISO-8859-1
    iconv.internal_encoding: ISO-8859-1 – ISO-8859-1
    iconv.output_encoding: ISO-8859-1 – ISO-8859-1
    Ich lau­fe auf WP 2.3.1 so­wie WP 2.3.3 (bei­de Original) wohl oh­ne Probleme. Beide Server sind von All-Inkl.
    @Holger:
    Ich den­ke, dass es ei­ne neue Funktion in der Version 2.5 gibt, die in der Lösung in mei­nem Zip (Version 2.3.1) nicht vor­han­den ist. Schau dir mei­nen Code an und ver­glei­che die­sen mit den Funktionen in der neu­en l10n.php von WP 2.5. Womöglich musst du ent­spre­chend die neue Funktion hin­zu­fü­gen und auf den Nativ-Aufruf um­lei­ten.
    @Niko:
    Du hast doch Komplett-Zugriff auf dei­nen Server? Kannst du mal nach­se­hen, ob es ir­gend­wo ent­spre­chen­de Einstellungen der Sprache oder (viel­leicht wich­ti­ger) des ver­wen­de­ten Zeichensatzes (z.B. UTF-8 oder ISO-8859-1) gibt? Haste schon „de_DE.UTF-8“ ver­sucht? Wäre cool wenn du ei­nen System- /Server- /PHP-Parameter fin­dest, der die ori­gi­na­le Lösung zum Laufen bringt…
    Grüße, Matthias

    antworten
  58. Niko_K  April 19, 2008

    Ich ha­be lei­der noch kei­ne wei­te­ren Einstellungen ge­fun­den.
    UTF-8 scheint je­doch nicht die Lösung zu sein, wenn ich die­sen Parameter in der WP_LANG an­hän­ge, dann er­scheint al­les auf eng­lisch… WordPress ver­sucht dann nicht ein­mal zu über­set­zen (wie ge­sagt… oh­ne das UTF-8 in der WP_LANG be­kom­me ich ei­ne Zeitüberschreitung, aber da ver­sucht WP we­nigs­tens die Seite zu über­set­zen)

    antworten
  59. Kretzschmar  April 21, 2008

    Da ich nicht wirk­lich php5 be­nö­ti­ge, ha­be ich kur­zer­hand ein­mal mei­nen Account auf php4 „zu­rück­ge­stellt“. Seitdem ha­be ich kei­ne Probleme mehr. Mit Hilfe ei­nes klei­nen Eingriffs in die .ht­acess klappt das so­gar, oh­ne den Support in Anspruch neh­men zu müs­sen.
    Unter # END WordPress in der .ht­acess
    muss nur hin­zu­ge­fügt wer­den:
    AddHandler php4-cgi .php
    (Wenn kei­ne .ht­acess Datei vor­han­den ist, weil Permalinks nicht ge­nutzt wer­den, muss die­se an­ge­legt wer­den!)

    antworten
  60. Holger  April 22, 2008

    Hmmja, scheint bei mir auch zu funk­tio­nie­ren, ich fra­ge mich nur, ob die äl­te­re PHP-Version zu ir­gend­wel­chen an­de­ren Problem im Betrieb von WP führt…?

    antworten
  61. Kretzschmar  April 22, 2008

    Das soll­te grund­sätz­lich nicht der Fall sein. Allenfalls ein­zel­ne Plugins VERLANGEN PHP5. Ich selbst nut­ze z.B. das „Now Reading“ Plugin. Dieses ver­lang tin der ak­tu­el­len Version ei­ne PHP5 Installation.
    Da WordPress of­fi­zi­ell PHP4.? vor­aus­setzt, ist ALL-INKL nicht mal un­be­dingt et­was vor­zu­wer­fen.
    Ich är­ge­re mich nur dar­über, dass ich mo­na­te­lang sel­ber her­um­pro­bie­ren muss­te. Eine Suche nach un­pack() zeigt ja, dass sehr vie­le Webseiten un­ter die­sem Problem lei­den.

    antworten
  62. Matthias Brusdeylins  April 25, 2008

    Vielleicht funk­tio­niert auch der Einsatz von mb_subsr() im Quellcode:
    http://de.php.net/mb_substr
    Man müss­te die oben be­schrie­be­ne Codezeile von gettext.php da mal aus­tau­schen…

    antworten
  63. Kretzschmar  April 27, 2008

    Das wer­de ich nicht mehr tes­ten kön­nen, da ich mitt­ler­wei­le zu ei­nem ame­ri­ka­ni­schen Hoster ge­wech­selt bin.

    antworten
  64. codestyling  Juni 23, 2008

    Ich hab das Problem eben­falls ana­ly­siert und ei­nen per­for­man­ten Ersatz für die spon­tan feh­ler­haf­te PHP sub­str() Funktion ge­fun­den.
    Dies hab ich be­reits im WP Trac ge­mel­det und ei­nen Fix be­reit­ge­stellt: http://www.code-styling.de/deutsch/wordpress-sprachdateien-erzeugen-fehler-in-gettext-php
    Ich konn­te dies be­reits auf ei­nen be­trof­fe­nen System tes­ten, denn bei mir trat dies nicht auf.

    antworten
  65. Matthias Brusdeylins  Juni 24, 2008

    Danke für den Hinweis. Doch be­denkt, dass im Programmcode von WordPress der Befehl sub­str() noch öff­ters vor­kommt… Womöglich ist das Fehlverhalten von sub­str() nun an ei­ner an­de­ren Stelle sicht­bar…

    antworten
  66. Matthias Brusdeylins  August 15, 2008

    WordPress lie­fert mit der Version 2.6.1 nun end­lich ei­ne Lösung. Dies ha­ben wir wohl dem Einsatz von „Codestyling“ zu ver­dan­ken. Er be­schreibt hier die Ursache auf sei­ner Seite nä­her:
    http://www.code-styling.de/deutsch/wordpress-fehler-durch-sprachdateien-die-ursache

    antworten
  67. probek  August 16, 2008

    Zeichen und Wunder.

    antworten
  68. Paul  August 16, 2008

    Seltsamerweise kommt es bei mir eben­falls zu die­sem Fehler, ob­wohl ich die eng­li­sche WordPress-Version 2.6.1 nut­ze. Hat da je­mand ei­ne Idee, wor­an das lie­gen kann?

    antworten
  69. Matthias Brusdeylins  August 24, 2008

    Haste in dei­ner .ht­ac­cess mal die fol­gen­den Zeilen ver­sucht (sie­he Beitrag auf http://www.code-styling.de)?
    PHP_VALUE magic_quotes_runtime Off
    PHP_VALUE mbstring.func_overload 0

    antworten
  70. Paul  August 25, 2008

    Ja, ha­be ich. Der Fehler kommt im­mer noch 🙁 Bin da völ­lig rat­los.

    antworten
  71. Frank Stolle  Oktober 16, 2008

    Ich hat­te den Fehler auch, konn­te Ihn je­doch dank der vie­len Informationen be­he­ben. Problem ist hier ein Bug in PHP (mod_php). Wenn nur ir­gend­wer auf dem Server in der .ht­ac­cess den Wert mbstring.func_overload den Wert auf 0 un­ter­schied­lich setzt, kann es zu die­sen Problemen kom­men. Eine nä­he­re Beschreibung inkl. Patch gibt es un­ter:
    http://bugs.php.net/bug.php?id=27421&edit=1
    In der nächs­ten PHP Version (5.2.7?) soll­te dies dann auch mit auf­ge­nom­men sein.

    antworten
  72. Matthias Brusdeylins  November 3, 2008

    Heute be­kam ich ei­ne eMail von mei­nem Provider All-Inkl:
    „Im Netz ha­be ich ge­le­sen das Sie eben­falls von dem wordpress/unpack Problem be­trof­fen sind. Ich ha­be eben auf Ihrem Server ein ak­tu­el­les PHP mit dies­be­züg­li­chem Patch in­stal­liert. Könnten Sie mich bit­te da­hin­ge­hend un­ter­stüt­zen zu ver­su­chen den Fehler zu pro­vo­zie­ren?
    Dies wür­de mir bei der end­gül­ti­gen Beseitigung er­heb­lich hel­fen.“

    Meine PHP-Version lau­tet nun 5.2.6.
    Also falls ei­nem von euch der Fehler hier auf mei­ner Webseite be­geg­net, lasst es mich bit­te wis­sen…

    antworten

Schreibe einen Kommentar