Vor gerau­mer Zeit begeg­ne­te ich immer wie­der einer ner­vi­gen Fehlermeldung:
Warning: unpack() [function.unpack]: Type V: not enough input,
need 4, have 0 in /***/wp-includes/gettext.php on line 85
Hier­bei han­delt es sich um PHP-Dateien einer WordPress-Installation (Ver­si­on 2.2.3 DE und Ver­si­on 2.3 DE). Unter Unix ist GNU get­text eine weit ver­brei­te­te Biblio­thek. Sie macht im Grun­de nichts ande­res, als einen über­ge­be­nen “ori­gi­na­len” String (in der Regel ein eng­li­scher Text) in einen ent­spre­chen­den String einer ande­ren Spra­che zu über­set­zen. Das Map­ping zwi­schen die­sen Strings befin­det sich in so genann­ten MO-Dateien (z.B. “de_DE.mo”). Auch Wor­d­Press setzt sol­che Datei­en für die Über­set­zung ein.

(Gelöst mit Wor­d­Press 2.6.1 — Details wei­ter unten…)
PHP könn­te direkt mit gettext-Support kom­pi­liert wer­den. Dadurch stün­den ent­spre­chen­de Funk­tio­nen direkt zur Ver­fü­gung. Doch wür­de solch ein Pro­gramm nicht auf einem Rech­ner ohne ent­spre­chen­de Unter­stüt­zung lau­fen. Aus die­sem Grund wur­de in Wor­d­Press das Pro­jekt PHP get­text inte­griert. Die Imple­men­tie­rung liegt in den Datei­en “gettext.php” und “streams.php” im “wp-includes”-Verzeichnis. Wor­d­Press erhält dadurch die Fähig­keit die­se MO-Dateien ein­zu­le­sen. Doch genau hier ent­stan­den ab und zu Probleme.

Betrachtung des Problems

Die oben dar­ge­stell­te Feh­ler­mel­dung kam bei mir spo­ra­disch. Und ich ken­ne die Feh­ler­stel­le genau. Sie befin­det sich in der Datei “streams.php” in der Klas­se StringReader. Und dort in der Funk­ti­on read($bytes). Hier lie­fer­te die Zei­le $data = substr($this->_str, $this->_pos, $bytes); nicht immer den rich­ti­gen Teil­st­ring zurück. Manch­mal war der Inhalt genau um ein Byte ver­scho­ben. Dadurch wur­den in der Datei “gettext.php” in der Funk­ti­on gettext_reader(…) Struk­tur­in­for­ma­tio­nen einer MO-Datei falsch inter­pre­tiert, was wie­der­um dazu führ­te, dass Men­gen­an­ga­ben kom­plett falsch ein­ge­le­sen wur­den. In solch einem Feh­ler­fall wur­de die seekto() Funk­ti­on mit einem gro­ßen nega­ti­ven Wert auf­ge­ru­fen, was dazu führ­te, dass der Stream-Positionszeiger an das Ende der Daten gesetzt wur­de. Dadurch lie­fer­te jeder wei­te­re Auf­ruf der Lese­me­tho­de einen Leer­st­ring zurück. Und genau solch ein Leer­st­ring wur­de der Metho­de unpack() in der Datei “gettext.php” in der Zei­le 85 über­ge­ben, was zu der oben besag­ten Mel­dung führte.
Es ist zwar nicht wirk­lich eine Lösung, doch hat­te ich die oben benann­te Code­zei­le tem­po­rär mit fol­gen­den Kom­man­dos ausgetauscht:
Alter Code:

$data = substr($this->_str, $this->_pos, $bytes);

Neu­er Code, der immer den rich­ti­gen Teil­st­ring ermittelt:

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

Gibt man hier noch eine Mel­dung aus, sobald die bei­den ermit­tel­ten Teil­strings unter­schied­lich sind, dann merk­te man, dass die­se gleich­zei­tig mit dem hier beschrie­be­nen Feh­ler auf­tauch­te. Ver­glich man die Inhal­te, sah man, dass bei einer Start­po­si­ti­on > 0 der Teil­st­ring aus substr() um ein Zeichen/Byte ver­scho­ben war. Statt z.B. den Inhalt von Index 4–7 zu ermit­teln, lie­fer­te die­se Metho­de dann die Zei­chen 5–8. Wohl bemerkt, dies aber nur sehr sporadisch!
Eigent­lich eine fata­le Sache, wenn ein regu­lä­rer PHP-Befehl Pro­ble­me ver­ur­sacht. Die­ser Befehl, der Tei­le aus gege­be­nen Tex­ten extra­hiert, kommt in Wor­d­Press häu­fi­ger zum Ein­satz. Am sicht­bars­ten ist er in Kom­bi­na­ti­on mit der Datei “gettext.php”, da hier ein Feh­ler gewor­fen wird. Aber mir ist eben­falls auf­ge­fal­len, dass es auch Pro­ble­me mit dem Abspei­chern geschrie­be­ner Inhal­te gab. Hier kam es vor, dass an Stel­len ein­ge­bun­de­ner Steu­er­codes (Links, Code-Tags) Tei­le des Inhal­tes ver­schwan­den. Man bemerk­te die Feh­ler­si­tua­ti­on, da der berühm­te gettext-Fehler auf­trat. Aus die­sem Grund ließ ich die oben beschrie­be­nen neu­en Code­zei­len auch nicht in mei­ner Instal­la­ti­on. Mir sind mit die­sem Code schon Inhal­te ver­schwun­den, ohne dass ich dies sofort bemerkte.

Lösungswege

Auf jeden Fall muss­te die Pro­ble­m­ur­sa­che an einer Server-Konfiguration oder –Kom­po­nen­te lie­gen. Ich ver­wal­te noch eine wei­te­re WordPress-Webseite und dort bekam ich noch kei­ne Feh­ler. Zu erwäh­nen ist auch, das bei­de Sei­ten beim glei­chen Pro­vi­der gehos­tet wer­den, die glei­che PHP-Version instal­liert war und inzwi­schen bei bei­den Wor­d­Press in der Ver­si­on 2.3 vorlag.
Mei­ne tem­po­rä­re Lösung bestand dar­in, dass ich auf mei­ner Sei­te die ori­gi­na­le eng­li­sche Ver­si­on von Wor­d­Press instal­lier­te. Somit trat der Feh­ler sel­te­ner auf, da eine Sprach­da­tei weni­ger ein­ge­le­sen wer­den muss­te. Er ver­schwand aber nicht kom­plett, weil noch PlugIns mit Sprach­da­tei­en instal­liert waren. Dies mach­te sich dann aber eher im Admin-Bereich, vor allem beim Spei­chern der Bei­trä­ge bemerkbar.
Dank dem schnel­len und moti­vier­ten Sup­port mei­nes Pro­vi­ders All-Inkl.de dach­ten wir zuerst, dass wir den Feh­ler ein­däm­men konn­ten. Der ers­te Ver­such bestand dar­in, den ZEND-Optimizer zu instal­lie­ren und wei­te­re PHP-Parameter an den Para­me­tern des Ser­vers mei­ner ande­ren WordPress-Präsenz anzu­pas­sen. Lei­der ohne dem gewünsch­ten Ergeb­nis. Ein Update der PHP-Installation von der Ver­si­on 5.2.3 auf 5.2.4, sowie die Aktua­li­sie­rung der Apache-Installation von der Ver­si­on 2.2.4 auf 2.2.6 lie­ßen den ner­vi­gen Feh­ler dann kurz­zei­tig doch ver­schwin­den. Ver­mut­lich besitzt substr() in PHP 5.2.3 nicht die erhoff­te Stabilität.
Update 24.10.07:
Das Pro­blem tritt seit heu­te lei­der wie­der auf! Womög­lich lag es doch nicht an der alten PHP-Version. Ich ver­fol­ge das weiter…
Update 30.10.07:
Das ist scha­de, aber auch das Update auf Wor­d­Press 2.3.1 DE brach­te nicht den erhoff­ten Erfolg. Wir sind lei­der so lang­sam am Ende mit dem Suchen, auch mit der Geduld. Der nächs­te Schritt besteht wohl dar­in, mei­nen Webs­pace inner­halb mei­nes Pro­vi­ders auf einen ande­ren Ser­ver zu ver­schie­ben. Zur Zeit habe ich die Datei “/wp-includes/languages/de_DE.mo” ent­fernt, damit der Feh­ler nicht mehr so häu­fig auftritt.
Update 03.11.07:
Mein Pro­vi­der All-Inkl hat nun mei­ne Web­sei­te auf einen ande­ren Ser­ver instal­liert. Seit dem scheint die Web­sei­te ohne Pro­ble­me zu funk­tio­nie­ren. Scha­de ist nur, dass wir nun nicht genau wis­sen, wel­che Server-Einstellung / Hardware-Kombination hier wohl Pro­ble­me mit der Funk­ti­on substr() aus PHP 5 verursacht.
Update:
Der Feh­ler taucht wie­der auf…
Update 15.11.07:
Heu­te wur­de PHP 5.2.5 auf dem Web­ser­ver instal­liert. Laut All-Inkl bin ich der Ers­te, der die­se Instal­la­ti­on tes­ten darf. Ich lau­fe nun auch wie­der auf der ori­gi­na­len deut­schen Ver­si­on. Bis jetzt sind mir noch kei­ne Pro­ble­me begeg­net. Die Zeit wird zei­gen, ob das die Lösung war…
Update 26.02.08:
Im Kom­men­tar Nr. 48 berich­tet Niko_K, dass das Pro­blem wohl durch nicht über­ein­stim­men­de Sprach­ein­stel­lun­gen zwi­schen der WordPress-Configuration und dem Linux-System (Varia­ble LANG) auf­tritt. Danke!
Ich ver­mu­te stark, dass PHP-String-Funktionen wie das substr() wohl abhän­gig von den Sys­tem­ein­stel­lun­gen sind und somit mit den rich­ti­gen Daten befüt­tert wer­den müssen.
Update 25.04.08:
Im Kom­men­tar Nr. 60 berich­tet Kretz­sch­mar dar­über, dass der Feh­ler unter PHP 4 nicht mehr auf­taucht. Die Umstel­lung von PHP 5 auf PHP 4 kann beim Pro­vi­der All-Inkl wohl selbst vor­ge­nom­men werden.
Ubda­te 24.06.08:
Der Bug ist inzwi­schen schon bei Wor­d­Press regis­triert (Bug 5599 — dan­ke an Code­sty­ler für den Hin­weis). Hier wird aktu­ell eine Alter­na­ti­ve zu substr() ein­ge­setzt. Die­se Lösung ist ele­gan­ter als die oben beschrie­be­ne. Lei­der ist die kor­ri­gier­te Stel­le nicht die ein­zi­ge mit dem Befehl substr(), wes­we­gen man trotz­dem ein Fehl­ver­hal­ten bzw. Daten­ver­lust in der Anwen­dung erwar­ten kann.
Update 15.08.08:
End­lich! Wor­d­Press 2.6.1 lie­fert nun ein Bug­fix zu die­sem Pro­blem. Der Feh­ler tritt auf, sobald man in der php.ini den Ein­trag mbstring.func_overload auf einen ande­ren Wert als 0 stellt. Meist erlau­ben die Pro­vi­der es, die­sen Wert für die eige­ne Web-Präsenz zu ändern. Ein Bug im Apache-Modul mod_php sorgt aller­dings bei die­ser Art der Umstel­lung dafür, dass sie für alle V‑Hosts des Ser­vers gilt! Sobald also ein User des glei­chen V‑Hosts an die­ser Ein­stel­lung dreht, erschei­nen bei den ande­ren WordPress-Präsenzen auf dem Ser­ver wohl die­se Feh­ler, zumin­des bis eine ande­re Prä­senz die­sen Wert wie­der auf 0 stellt. Nähe­res hier­zu unter code-styling.de.

Native Lösung

Es lief eini­ge Tage gut, nun sind seit heu­te (06.11.2007) alle WordPress-Seiten auf dem neu­en Ser­ver wohl auch betroffen…
Im deutsch­spra­chi­gen WordPress-Forum bin ich nun auf eine wei­te­re Lösung gesto­ßen: Ein­satz des ori­gi­na­len get­text() Kom­man­dos. Die­se Lösung kann lei­der nur dann ange­wen­det wer­den, wenn get­text auf dem ent­spre­chen­den Ser­ver instal­liert ist. Ein Blick in die PHP-Info lie­fert hier­zu Informationen:
GetText Support enabled
Wor­in besteht 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 instal­lier­te Funk­ti­on get­text() anstel­le der pro­ble­ma­ti­schen gettext-Vertretung auf­ge­ru­fen wird. Dazu muss die Sprach­da­tei /wp-includes/languages/de_DE.mo zu wordpress.mo umbe­nannt und in ein neu­es Ver­zeich­nis kopiert wer­den. Der Name des Ver­zeich­nis­ses ist abhän­gig von der ein­ge­stell­ten Codie­rung in der Datei wp-config.php:
Eine Sprach­de­fi­ni­ti­on defi­ne (‘WPLANG’, ‘de_DE.UTF‑8’); benö­tigt das Ver­zeich­nis wp-includes/locale/de_DE.UTF‑8/LC_MESSAGES/.
Lau­tet die Sprach­de­fi­ni­ti­on defi­ne (‘WPLANG’, ‘de_DE’); muss das Ver­zeich­nis den Namen wp-includes/locale/de_DE/LC_MESSAGES/ tragen.
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 Datei­en gettext.php und streams.php löschen.
Damit die Umstel­lung schnell voll­zo­gen wer­den kann, hab ich für Wor­d­Press 2.3.1 Deutsch ein klei­nes ZIP-File mit allen nöti­gen Ände­run­gen erstellt:
Native_gettext_WordPress_2.3.1.zip
ACHTUNG:
hier bit­te auf die rich­ti­ge Codie­rung ach­ten, damit beim Pos­ten kei­ne Inhal­te ver­lo­ren gehen. Am Bes­ten vor­her ein Back­up der Daten­bank anle­gen. Wenn eine ande­re WordPress-Version unter­stützt wer­den soll, dann ein­fach die Sprach­da­tei­en aus dem ZIP-File ent­spre­chend der obi­gen Anlei­tung selbst generieren.
Und nicht ver­ges­sen: somit ist das Anzeige-Problem gelöst, der Feh­ler taucht nicht mehr auf, aber es gibt noch vie­le ande­re substr()-Aufrufe, wel­che schief lau­fen kön­nen. Auf­fäl­lig ist dabei Daten­ver­lust an den Steuer-Tags aus der Code-Ansicht.