Probleme mit gettext

Vor gerau­mer Zeit begeg­ne­te ich immer wie­der einer ner­vi­gen Feh­ler­mel­dung:
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 Pro­ble­me.

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­string 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­string zurück. Und genau solch ein Leer­string 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ühr­te.
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 aus­ge­tauscht:
Alter Code:

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

Neu­er Code, der immer den rich­ti­gen Teil­string ermit­telt:

$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­string 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 spo­ra­disch!
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 bemerk­te.

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 vor­lag.
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 Plug­Ins 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 bemerk­bar.
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 Sta­bi­li­tä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 wei­ter…
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 auf­tritt.
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 ver­ur­sacht.
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. Dan­ke!
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üs­sen.
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 wer­den.
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 betrof­fen…
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 Infor­ma­tio­nen:
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/ tra­gen.
Wenn man will, kann man in der Datei wp-settings.php die Zei­len
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 gene­rie­ren.
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.

78

Kommentare

  1. probek  Oktober 26, 2007

    Ich habe das Pro­blem auch. Und dass Du das auch mit einem Update auf WP 2.3 nicht hin­be­kom­men hast, macht mir Sor­gen, da ich das bis­her als Lösungs­weg sah.
    Liegt es denn sicher an einem “deut­schen” Pro­blem, d.h. an der de-Version von Wor­d­Press bzw. an deutsch­spra­chi­gen Plug­ins, d.h., wenn ich auf die eng­li­sche WordPress-Version zurück­grei­fe und kei­ne deutsch­spra­chi­gen Plug­ins mehr instal­liert habe, geht’s wie­der? Und wie bekom­me ich das hin?
    Oder kann der Pro­vi­der was machen? Wäre auch nett, wenn man im deut­schen WordPress-Forum mehr dazu lesen könn­te. Aber wenn Du hier die Lösung fin­dest, wäre mir/uns/vermutlich auch ande­ren auch schon gehol­fen.

    antworten
  2. probek  Oktober 26, 2007

    Lus­ti­ger­wei­se (naja, wenn man’s lus­tig fin­det) ist gera­de auch beim Absen­den des obe­ren Kom­men­tars die Feh­ler­mel­dung erschie­nen…

    antworten
  3. Matthias Brusdeylins  Oktober 27, 2007

    Der Feh­ler taucht wohl in der sub­str() Funk­ti­on von PHP 5 auf (oder hast du noch PHP 4.x instal­liert?)… Und die­se wird häu­fig bei der Über­set­zung der Tex­te auf­ge­ru­fen. Des­we­gen ist hier wohl die Wahr­schein­lich­keit des Auf­tre­tens eines Feh­lers erhöht.
    Ob es sich hier um einen Fol­ge­ef­fekt eines noch unbe­kann­ten Pro­blems han­delt ist mir unklar. Fakt ist, dass ich noch einen wei­te­ren Webs­pace mit WP 2.3 DE beim glei­chen Pro­vi­der habe. Und hier erscheint die­ser Feh­ler nicht!
    Wenn man die Über­set­zun­gen unter /wp-includes/languages/de_DE.mo ent­fernt, soll­te schon das Pro­blem stark redu­ziert sein. Ansons­ten kann man ein­fach alle PHP-Dateien (Aus­nah­me wp-config.php, .htac­cess uns sons­ti­ge eige­ne Dateien/Verzeichnisse) mit der eng­li­schen Ver­si­on von Wor­d­Press erset­zen.
    Die Datenbank-Struktur inner­halb der glei­chen Ver­si­on ist zwi­schen der deut­schen und eng­li­schen Ver­si­on gleich. Wenn man auf 2.3 Updaten willst, fin­dest sich unter der ent­spre­chen­den WordPress-Seite die Anlei­tung zum Updaten.
    Zur­zeit lauf ich noch auf der deut­schen Ver­si­on, um den Feh­ler bes­ser zu beob­ach­ten. Soll­te eine Lösung aller­dings nicht bald gefun­den wer­den, spie­le ich die eng­li­sche Ver­si­on wie­der auf.

    antworten
  4. Kretzschmar  November 1, 2007

    Ich bin eben­falls von die­ser ner­vi­gen Feh­ler­mel­dung geplagt. Vor der deut­schen Ver­si­on 2.3 ist sie nie auf­ge­tre­ten.
    Vie­leicht liegt es ja doch an all-inkl. Ich bin näm­lich eben­falls dort auf php5 gehosted.

    antworten
  5. probek  November 2, 2007

    Bin nicht bei All-Inkl, habe PHP5 und inzwi­schen die neu­es­te WordPress-Version — und bin immer noch betrof­fen. Wir sind übri­gens nicht allei­ne — eine Google-Suche nach der Feh­ler­mel­dung lie­fert ein paar schö­ne Tref­fer mit gera­de betrof­fe­nen Blogs. Kann man das Pro­blem nicht in die offi­zi­el­le Feh­ler­lis­te von Wor­d­Press auf­neh­men?

    antworten
  6. Matthias Brusdeylins  November 2, 2007

    Viel­leicht soll­te man den Feh­ler eher an die PHP-Entwickler wei­ter­lei­ten. Da doch die Metho­de sub­str() hier aus irgend­ei­nem Grund ver­sagt.
    Mein Pro­vi­der All-Inkl hat nun den Umzug auf einen ande­ren inter­nen Ser­ver voll­zo­gen. Inzwi­schen läuft auch wie­der die deut­sche Ver­si­on. Bis­her sind mir kei­ne Feh­ler mehr begeg­net, aber da will ich erst ein­mal noch ein biß­chen wei­ter­tes­ten, bevor ich dies zu laut raus­schreie…

    antworten
  7. Michael  November 6, 2007

    Auf mei­ne Sei­te kom­men seit heu­te eben­falls die doo­fen Mel­dun­gen. Mei­ne Sei­ten sind auch bei all inkl auf PHP5, habe mich sofort bei denen kun­dig gemacht. Und her­aus­ge­kom­men ist: “Das Pro­blem liegt nicht bei All Inkl, son­der das es ein Wor­d­Press Feh­ler ist und das ich mich direkt an Wod­Press Ent­wick­ler rich­ten soll.” Also soll­te der Feh­ler auf jeden Fall von Wor­d­Press beho­ben wer­den.

    antworten
  8. Thomas  November 8, 2007

    Da bei mir die deut­sche Sprach­da­tei nach einem Ser­ver­um­zug auf amd64 nicht mehr funk­tio­nier­te, habe ich auch die­se nati­ve Lösung ver­wen­det.
    Bleibt noch hin­zu­zu­fü­gen, dass man jetzt noch in wp-settings.php die Zei­le

    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

    Hal­lo zusam­men,
    schö­ner, zusam­men­ge­fass­ter Bei­trag. Bin auch durch goog­le auf dein Pos­ting gesto­ßen und eben­falls von dem Feh­ler betrof­fen. Hat­te den Feh­ler noch nie, bei kei­ner mei­ner Wor­d­Press Sei­ten… Heu­te das ers­te mal. Bin auch bei allinkl auf php5 ser­ver… mal beob­ach­ten
    *book­mar­ked*

    antworten
  10. Matthias Brusdeylins  November 15, 2007

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

    antworten
  11. Kretzschmar  November 17, 2007

    Ich bin Dir gefolgt und habe PHP aktua­li­sie­ren las­sen. Bei mir ist die Feh­ler­mel­dung gera­de erneut drei­mal erschie­nen (auf mei­nem Blog). Bei Dir habe ich sie noch NIE gese­hen (auf die­ser Sei­te).
    Hast Du eine Über­sicht über Dei­ne ver­wen­de­ten Plug­ins? Mög­li­cher­wei­se benut­zen wir ja bei­de ein Plug­in, wel­ches NEBENBEI die­sen Feh­ler ver­ur­sacht?

    antworten
  12. Matthias Brusdeylins  November 18, 2007

    Hier mal mei­ne instal­lier­te Plug­ins:
    Akis­met (2.0.2)
    Bre­ad­crumb (0.5.1)
    Easy HTML Meta­da­ta (1.2) — mein Plug­in
    Follow-URL (1.0)
    Gravatars2 (2.7.0)
    Light­box JS v2.03.3 Plug­in (1.7)
    Next­GEN Gal­le­ry (0.72)
    o42-clean-umlauts (0.2.0)
    Role Mana­ger (2.0.8)
    Search Pages (2.0)
    Simp­le Track­back Vali­da­ti­on (2.1)
    Top Level Cate­go­ries (1.0)
    Yet Ano­t­her Advan­ced Paged Navi­ga­ti­on (1.05)

    antworten
  13. Kretzschmar  November 18, 2007

    Ich habe alle Plug­ins deak­ti­viert, die mit Dei­nen iden­tisch sind. Es hat aber nichts gehol­fen. Der Feh­ler tritt regel­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 wenig genervt.

    antworten
  14. Matthias Brusdeylins  November 19, 2007

    Also am Sonn­tag Abend hab ich ihn auch wie­der gehabt! Ich ver­mu­te da eher Über­las­tungs­pro­ble­me…
    Womög­lich Ausführungs-Speicher zu knapp…

    antworten
  15. Marc Köberlein  November 21, 2007

    Hat­te auch bei dei­ner Sei­te heu­te eini­ge Male die Mel­dung erhal­ten. Hast du dei­nen letz­ten Lösungs­vor­schlag bereits ein­ge­baut ?
    Scheint wohl die bit­te­re Rea­li­tät zu sein, dass man eini­ge Zeit mit dem Feh­ler leben 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. Lei­der lief das gera­de mal eine Woche gut, dann kamen die Feh­ler immer häu­fi­ger vor. Laut mei­nem Pro­vi­der All-Inkl wur­de aber am Ser­ver nichts geän­dert. Doch ich hab nun fest­ge­stellt, dass mein Ser­ver wie­der auf PHP 5.2.3 läuft !!!

    antworten
  17. Kretzschmar  November 21, 2007

    Ich hat­te jetzt eini­ge Zeit kei­ne Pro­ble­me mehr. Aber immer dann schlägt es erbar­mungs­los zu. Nach der Ruhe kommt der Sturm. Ein Feh­ler jagt dann den nächs­ten und nie­mand kann sagen war­um.

    antworten
  18. Matthias Brusdeylins  November 22, 2007

    was sagt dein info­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 einem neu­en Ser­ver mit 65MB Memory-Limit (davor 40MB) und PHP 5.2.5… Eins muss man las­sen: mein Pro­vi­der All-Inkl gibt sich echt Mühe!
    Jetzt heißt es wie­der: beob­ach­ten…

    antworten
  20. Kretzschmar  November 22, 2007

    Server- Ein­stel­lun­gen
    * Betriebs­sys­tem : Linux
    * Ser­ver : Apache/2.2.6
    * Spei­cher­ver­brauch : 17,23 MByte
    * MyS­QL Ver­si­on : 5.0.45-community-log
    * SQL Modus : Nicht gesetzt
    * PHP Ver­si­on : 5.2.5
    * PHP Safe Mode : Aus
    * PHP Allow URL fopen : An
    * PHP Memo­ry Limit : 65M
    * PHP Max Upload Size : 200M
    * PHP Max Post Size : 200M
    * PHP Max Script Exe­cu­te Time : 30s
    GD Unter­stüt­zung
    * GD Ver­si­on : bund­led (2.0.34 com­pa­ti­ble)
    * Fre­e­Ty­pe Sup­port : Ja
    * Fre­e­Ty­pe Linkage : with fre­e­ty­pe
    * T1Lib Sup­port : Ja
    * GIF Read Sup­port : Ja
    * GIF Crea­te Sup­port : Ja
    * JPG Sup­port : Ja
    * PNG Sup­port : Ja
    * WBMP Sup­port : Ja
    * XPM Sup­port : Ja
    * XBM Sup­port : Ja
    * JIS-mapped Japa­ne­se Font Sup­port : Nein
    Ich habe seit eini­gen Tagen kei­ne Pro­ble­me mehr. Schät­ze, dass all-inkl da etwas geän­dert haben.

    antworten
  21. Matthias Brusdeylins  November 22, 2007

    Bei mir läuft es heu­te auch schon feh­ler­frei, soweit ich das sehe. Die Para­me­ter 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 Lis­te ermit­telt?

    antworten
  22. Kretzschmar  November 23, 2007

    Ich benut­ze Next­Gen­Gal­le­ry und im NGG Panel wer­den die­se Infor­ma­tio­nen aus­ge­ge­ben. Kein phpin­fo() not­wen­dig. Klas­se. Ist über­haupt eines der bes­ten Plug­ins für Wor­d­Press.

    antworten
  23. Kretzschmar  November 24, 2007

    Heu­te trat der Feh­ler wie­der auf (nach­dem ich Akis­met wie­der akti­viert hat­te). Ver­such mal, ob es viel­leicht dar­an liegt.

    antworten
  24. Matthias Brusdeylins  November 24, 2007

    Next­Gen­Gal­le­ry und Akis­met lau­fen bei mir auch…
    bist jetzt bin ich kei­nem Feh­ler mehr begeg­net…
    Kam der Feh­ler bei dir trotzt PHP 5.2.5 oder wur­dest du da auch zurück­ge­stellt wie es bei mir war…

    antworten
  25. Kretzschmar  November 26, 2007

    Trotz 5.25. Komi­scher­wei­se geht es jetzt. Ich bin trotz­dem ohne Hoff­nung.

    antworten
  26. Kretzschmar  November 27, 2007

    Ich hat­te Recht, kom­me kaum auf mei­ne Sei­te heu­te. Muss immer wie­der neu laden.

    antworten
  27. Matthias Brusdeylins  November 27, 2007

    Somit liegt die Lösung also auch nicht in PHP 5.2.5…
    Frag mal bei AllInkl nach, ob du an den bestimm­ten Zei­ten irgend eine Über­las­tung auf dei­nem Ser­ver hast… hab ich auch gemacht und es gab die­se wohl…

    antworten
  28. Kretzschmar  November 28, 2007

    Ich glau­be nicht an Über­las­tung. Denn manch­mal läuft es nach einem rel­oad wun­der­bar schnell wei­ter. Kei­ne sicht­ba­ren Ver­zö­ge­run­gen usw.
    Im SVN (Wor­d­Press 2.4 alpha) ist die gepatch­te gettext.php bereits ent­hal­ten. Ich habe die­se Ver­si­on eben­falls aus­pro­biert und erhal­te den­noch die Feh­ler­mel­dung.

    antworten
  29. Matthias Brusdeylins  November 29, 2007

    Ver­such mal die “Nati­ve Lösung” mit UTF-8 wie oben beschrie­ben. Die habe ich zur Zeit auf http://bcxp.de lau­fen. Wie es aus­sieht funk­tio­niert die ziem­lich gut… mach aber zur Sicher­heit regel­mä­ßig DB-Backups… Ich hab kei­ne Ahnung, ob es noch an ande­ren Stel­len Pro­ble­me mit PHP5 gibt, die sich nicht gleich bemerk­bar machen…

    antworten
  30. Kretzschmar  November 30, 2007

    Die nati­ve Lösung klappt bei mir zwar, aller­dings wird dann mein the­me nicht mehr get­text­ed.

    antworten
  31. Matthias Brusdeylins  Dezember 1, 2007

    Also die über­schrie­be­nen Über­set­zungs­funk­tio­nen __() usw. in I10n.php wer­den ja wei­ter­hin auf­ge­ru­fen. Und wenn das neue Ver­zeich­nis “loca­le” mit dem zur Kon­fi­gu­ra­ti­on pas­sen­den Unter­ver­zeich­nis exis­tiert, die Sprach­da­tei aus “lan­guage” ent­spre­chend umbe­nannt wird und dort abge­legt wird, müss­te es eigent­lich gehen. Oder ver­wen­det dein The­me ande­re Funk­tio­nen zum Über­setz­ten, die nicht aus I10n.php kom­men?

    antworten
  32. Stephan  Dezember 2, 2007

    Also ich hab bis­her auch noch kei­ne Lösung gefun­den und auch die im Forum erwähn­te bringt mich nicht wei­ter.
    Hab mich heu­te auch mal an all-inkl gewandt, die mir als Lösungs­an­satz die­ses Blog­post emp­foh­len haben 😉
    Bleibt nur zu hof­fen, dass der Feh­ler in WP2.4 beho­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 womög­lich genau­so wie das Haupt-Language-File ein­bin­den…

    antworten
  34. Kretzschmar  Dezember 6, 2007

    Dan­ke Mat­thi­as, du hat­test Recht. Bei mir klappt es jetzt. Ich bin den­noch nicht zufrie­den, da ich nicht jedes Mal Wor­d­Press patchen möch­te. Wenn get­text von PHP nicht unter­stützt wird, führt dann ein Auf­ruf von ‘bind_textdomain’ zu einer Feh­ler­mel­dung?

    antworten
  35. Matthias Brusdeylins  Dezember 6, 2007

    So wie es aus­sieht, ist dies eines der Funk­tio­nen, die du durch die Native-GetText-Integration dazu bekommst.
    http://www.php-homepage.de/manual/ref.gettext.php
    Es ist schon scha­de, dass hier Wor­d­Press nach jedem Update gepatcht wer­den muss, aber es bleibt wohl kei­ne ande­re Lösung zur Zeit…

    antworten
  36. Kretzschmar  Dezember 9, 2007

    Immer­hin habe ich seit der Ände­rung tat­säch­lich kei­ner­lei Feh­ler mehr.

    antworten
  37. Michael  Dezember 29, 2007

    Hiho du,
    habe das nun so gemacht wie du beschrie­ben hast. Hat alles hin gehau­en, Sei­te ist jetzt gut, lei­der sieht sie nicht mehr gut aus! Biss­le ver­scho­ben und Next­Gen­Gal­le­ry geht nicht mehr. Genau so habe ich nun kei­nen Edi­tor mehr unter Schrei­ben Beitrag/Seiten!!! Womög­lich irgend­was ver­hau­en…
    cu

    antworten
  38. Matthias Brusdeylins  Januar 18, 2008

    So wie ich das sehe geht’s auf dei­ner Sei­te wie­der. Was war das Pro­blem?

    antworten
  39. Niko_K  Februar 10, 2008

    Hal­lo,
    ich habe mir ges­tern die deut­sche WP v. 2.3.3 instal­liert.
    Habe auch das beschrie­be­ne (und anschei­nend mit Ver­wen­dung durch das nati­ve get­text von php gelös­te) Pro­blem.
    Jetzt habe ich die .zip file für v. 2.3.1 instal­liert (also die l10n.php ersetzt), dann in wp-settings.php die bei­den include_once aus­kom­men­tiert und die Sprach­da­tei­en in das loca­le Ver­zeich­niss (mit beach­te­ter Codie­rung aus der wp-config.php) kopiert.
    Der Feh­ler tritt nun auch nicht mehr auf, ABER:
    Bei mir ist der Admin Bereich wie­der kom­plett in Eng­lisch.
    Wo könn­te hier der Feh­ler lie­gen (bzw. wie fin­de ich den Feh­ler)?

    antworten
  40. Matthias Brusdeylins  Februar 10, 2008

    Wel­che PHP-Version läuft bei dir? Bei mir läuft die PHP Ver­si­on 5.2.5 und Wor­d­Press 2.3.1 ori­gi­nal ohne Pro­ble­me. Die neue WP-Version muss ich hier ers­te sel­ber tes­ten…

    antworten
  41. Niko_K  Februar 10, 2008

    Hat­te bis ges­tern noch 5.2.0 (release weis ich lei­der nicht mehr)… habe dann ges­tern in der nacht aber noch ein update gemacht.
    Jetzt bekom­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 habe per phpin­fo(); auch noch­mal geprüft, ob get­text wirk­lich “an” ist… und es scheint alles zu pas­sen (war mir da nicht mehr 100% sicher)
    Wor­d­Press ist wie gesagt 2.3.3 DE
    Hof­fe das hilft ein wenig… wend du mehr Infos braucht, dann ein­fach fra­gen. Der Ser­ver steht hier pri­vat bei mir… soll heis­sen… dem Bas­teln sind (fast) kei­ne Gren­zen gesetzt!

    antworten
  42. Niko_K  Februar 24, 2008

    Ich habe heu­te end­lich wie­der ein wenig Zeit gefun­den mich mit dem
    Wor­d­Press gettext-Problem zu beschäf­ti­gen.
    Das Pro­blem scheint nicht an der neu­en Wor­d­Press Ver­si­on zu lie­gen.
    Ich habe heu­te in die translate-funktion der ver­än­der­ten l10n.php einen log­ging out­put ein­ge­baut (ziem­lich simp­le… ein­fach den String vor und nach der Über­set­zung durch get­text aus­ge­ge­ben) und allem Anschein nach funk­tio­niert bei mir der call zu get­text nicht rich­tig…
    Ich habe jetzt auch schon diver­se Ver­su­che mit der Ord­ner­struk­tur
    “wp-includes/locale” hin­ter mir (habe da jetzt 4 Unter­ver­zeich­nis­se…
    de_AT; de_AT.UTF-8; de_DE und de_DE.UTF-8… um auch wirk­lich ganz sicher zu sein), aber lei­der erfolg­los. Als nächs­tes habe ich dann get­text auf der Shell aus­pro­biert. Auch hier ver­ste­he ich das Pro­blem nicht ganz. Selbst ein “get­text -d locale/de_AT.UTF-8/LC_MESSAGES/wordpress.mo -s “%d topics” über­setzt nicht rich­tig und gibt mir nur wie­der den ori­gi­nal­String “%d topics” zurück. Ich habe das schon mit meh­re­ren text­do­mains ver­sucht (da ich nicht genau weis, was hier rein soll; dar­un­ter “loca­le” und auch
    “locale/de_DE/”). Eine wei­te­re Ver­mu­tung war dann noch, dass ich ein Pro­blem mit den .mo files selbst habe, aber alles was ich hier nach­prü­fen kann sind die Zugriffs­rech­te und die sind okay (hat alles www-data).
    Ent­we­der ver­wen­de ich hier den Text­be­reich falsch, oder get­text über­setzt mit aus irgend­ei­nem Grund nicht. Viel­leicht kennt ja hier jemand die Lösung… ich den­ke jetzt mal, dass es eini­ge gibt, die sich bes­ser mit get­text aus­kennst als Mei­ner­Ei­ner und einen Tipp für mich haben (hof­fent­lich, bit­te, bit­te…).
    An der PHP-Info kann es jeden­falls nicht lie­gen. Die sieht gut aus (get­text Sup­port enab­led)
    LG,
    Niko

    antworten
  43. Matthias Brusdeylins  Februar 24, 2008

    Vie­len Dank für dei­ne aus­führ­li­che Ana­ly­se. Sehe ich das rich­tig, bei dir geht weder die PHP-WordPress-Version von Get­Text, noch die nati­ve Ver­si­on (wel­che du auf der Shell getes­tet hast)? Kann es an irgend­wel­chen Installations-Parametern, -Kom­bi­na­tio­nen oder -Ver­sio­nen der Ser­ver­kom­po­nen­ten lie­gen? Ich den­ke dabei 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() Funk­ti­on schief, was ich mir nicht erklä­ren kann… (Schon mal den SubStr-Ersatz von oben aus­pro­biert?) Läuft dei­ne Umge­bung auf den glei­chen Apache- und PHP Ver­sio­nen wie bei mir (Bezug auf unse­re Mail)? Inzwi­schen habe ich ja wie­der das ori­gi­na­le Wor­d­Press lau­fen und wohl kei­ne Pro­ble­me damit.

    antworten
  44. Niko_K  Februar 26, 2008

    Also die ver­wen­de­te PHP Ver­si­on ist die sel­be. Ich selbst ver­wen­de Apa­che 2.2.3 (alles als .deb Pake­te von dot­deb bzw. von den Ori­gi­nal Debi­an Quel­len)
    Ich konn­ne in der dei­ne PHP-Info die Apa­che Ver­si­on nicht fin­den, aber ansosn­ten sieht alles sehr ähn­lich aus

    antworten
  45. Matthias Brusdeylins  Februar 26, 2008

    Mei­ne 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 Wochen­den mal ver­su­chen, den Apa­che Ver­si­on 2.2.6 instal­lie­ren und nach­se­hen ob sich was ändert (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 Pro­blem nun durch ein wenig her­um­pro­bie­ren lösen kön­nen.
    Es lag nicht an der Apa­che ver­si­on (habe noch kein Update gemacht)
    Das Pro­blem war wohl eine Dis­kre­panz der Spra­chen zwi­schen dem Linux-System selbst und Wor­d­Press. WP hat­te “de_AT” ein­ge­stellt wäh­rend im Sys­tem ein LANG=“de_AT.UTF-8” gesetzt war.
    Ich habe nun WP auf de_AT.UTF-8 gesetzt (in wp-config.php) und nun funk­tio­niert die Über­set­zung wie­der!
    BTW:
    Ich habe noch ein “locale-gen” aus­ge­führt. Da das ja die loca­les des Sytsems selbst über­setzt glau­be ich zwar nicht, dass es einen Ein­fluss auf die Lösung hat, aber sicher­heits­hal­ber will ich es doch erwäh­nen.
    Das Kom­man­do­zei­len get­text arbei­tet bei mir immer noch nicht… aber ich glau­be wirk­lich, dass das an einem feh­ler­haf­ten Auf­ruf mei­ner­seits liegt (ich fin­de lei­der kei­ne gute Anlei­tung im web oder auch in get­text selbst, die mir genau sagt, was ich wie ver­wen­den kann…)

    antworten
  48. Matthias Brusdeylins  Februar 26, 2008

    Super! Dan­ke für die Infos…
    Ich wer­de mal dei­nen Kom­men­tar oben im Text erwäh­nen.

    antworten
  49. probek  März 1, 2008

    Ist die Lösung gefun­den? Und kann jemand den Lösungs­weg so erklä­ren, dass es auch ein Nicht-Programmierer ver­steht?
    Wel­che Lösung gibt es für Blog-Betreiber bei Sha­red Hos­ting? Ein Ein­fü­gen von (‘WPLANG’, ‘de_AT.UTF-8’) in wp-config.php führt bei mir dazu, dass die WP-Admin-Oberfläche statt in Deutsch in Eng­lisch erscheint, das hilft mir also ver­mut­lich nur bedingt wei­ter.

    antworten
  50. Matthias Brusdeylins  März 16, 2008

    Hi Pro­bek,
    hast du es schon mal mit “de_DE.UTF-8” ver­sucht?
    BTW: auf mei­ner Webin­stanz läuft das Wor­d­Press 2.3.1 nun ohne irgend­wel­chen Tricks. Als Spra­che steht bei mir “de_DE” ein­ge­tra­gen. Ob der Pro­vi­der hier was ange­passt hat, kann ich nicht sagen…

    antworten
  51. probek  März 27, 2008

    Bei “de_DE.UTF-8” (schon pro­biert) wird mein The­me nicht über­setzt. Und den Feh­ler habe ich spo­ra­disch immer noch (was man schön über die Goog­le Webmaster-Tools sehen kann).

    antworten
  52. Matthias Brusdeylins  April 3, 2008

    Wenn du dich traust und ein Back­up dei­ner Daten­bank machst, kannst du ja mal ver­su­chen Wor­d­Press 2.5 zu instal­lie­ren… Aber prü­fe erst, ob all dei­ne Plug­ins auch den Ver­si­ons­sprung über­stan­den haben…

    antworten
  53. Kretzschmar  April 6, 2008

    Ich habe bereits Wor­d­Press 2.5 instal­liert. Der Feh­ler tritt bei mir ab und an immer noch auf. Die­se Pro­ble­me habe ich aller­dings nur bei all-inkl. Ande­re Instal­la­tio­nen funk­tio­nie­ren ein­wand­frei.
    Ich habe mitt­ler­wei­le auch eine kom­plett neue Daten­bank ange­legt und alle Bei­trä­ge expor­tiert und in die neue impor­tiert. Ein Daten­bank­pro­blem ist also eher unwahr­schein­lich.
    Auch tritt der Feh­ler ohne Plug­ins auf.

    antworten
  54. Matthias Brusdeylins  April 6, 2008

    Da scheint es bei dei­nem All-Inkl-Server wohl irgend ein Kon­fi­gu­ra­ti­ons­pro­blem zu geben… Spra­che oder Codie­rung (UTF8 ?)… Scha­de dass man da nicht selbst nach­prü­fen kann… Wie schon gesagt, ich bin auch bei All-Inkl und hab kei­ne Pro­ble­me mehr…

    antworten
  55. Holger  April 10, 2008

    Hi Mat­thi­as,
    ich habe das glei­che Pro­blem (übri­gens eben­falls all-inkl.), und habe Dei­ne nati­ve Lösung aus­pro­biert. Es scheint zu klap­pen, aller­dings bekom­me ich nun im Backend beim Auf­ruf des Rei­ters “Ver­wal­ten” (WP 2.5) fol­gen­de Feh­ler­mel­dung:
    Fatal error: Call to unde­fi­ned func­tion __ngettext_noop() in /www/htdocs/w009abf0/wp-admin/includes/post.php on line 522
    Was kann denn hier pas­siert sein?
    Grü­ße

    antworten
  56. Nikolaus Krismer  April 14, 2008

    Hal­lo die Run­de,
    also ich habe heu­te ein Update auf Ver­si­on 2.5 durch­ge­führt… und… man mag es kaum glau­ben… es geht wie­der nix mehr.
    Also:
    Nach dem ers­ten Ver­such mit dem Wor­d­Press “inter­nen” Mecha­nis­mus die Page über­set­zen zu las­sen (ein­fach in der wp-config.php als WP_LANG de_DE ange­ben) bekam ich nen Feh­ler, dass gettext.php und in wei­ter­ter fol­ge auch stream.php zu lan­ge brau­chen (ich weis die genau Feh­ler­mel­dung nicht mehr… aber Apa­che meker­te im error.log, dass mehr als 60sec benö­tigt wur­den… nach­dem der Ser­ver hier mein eige­ner is… sehr wenig Appli­ka­tio­nen drauf lau­fen und auch die Hard­ware recht neu ist, bin ich mir sicher, dass es nichts nützt den timeout-wert nach oben zu set­zen)
    Mit dem hier vor­ge­schla­ge­nen Mecha­nis­mus, der mich ja schon in Ver­si­on 2.3.3 eini­ges an Ner­ven gekost­tet hat (sie­he oben), funk­tio­niert das Über­set­zen… dach­te ich… also:
    Das Front­end (Datums­an­ge­ben, etc.) wer­den pro­blem­los über­setzt. Nur im Backend is das alles nicht soo super. Ers­tens wer­den nicht alle Strings über­setzt (ja ich habe die neue Sprach­da­tei der Ver­si­on 2.5 in das LC_MESSAGES Ver­zeich­nis kopiert und ver­wen­de nicht mehr die alte Sprach­da­tei der Ver­si­on 2.3.3) und zwei­tens kann ich dann man­che Sei­ten gar nicht mehr öff­nen (bekom­me eine lee­re Sei­te). Den Feh­ler hier­bei konn­te ich noch nicht fin­den…
    …aus Grün­den der Ver­zweif­lung wer­de ich Wor­d­Press wohl erst mal eini­ge Zeit auf eng­lisch ver­wen­den.
    LG,
    Niko

    antworten
  57. Matthias Brusdeylins  April 15, 2008

    Scha­de dass es so vie­le Pro­ble­me gibt…
    Hier mal mei­ne Para­me­ter aus der wp-config.php:
    define(‘DB_CHARSET’, ‘utf8’);
    define(‘DB_COLLATE’, ”);
    defi­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 value — no value
    iconv sup­port: enab­led
    iconv imple­men­ta­ti­on: glibc
    iconv libra­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 sowie WP 2.3.3 (bei­de Ori­gi­nal) wohl ohne Pro­ble­me. Bei­de Ser­ver sind von All-Inkl.
    @Holger:
    Ich den­ke, dass es eine neue Funk­ti­on in der Ver­si­on 2.5 gibt, die in der Lösung in mei­nem Zip (Ver­si­on 2.3.1) nicht vor­han­den ist. Schau dir mei­nen Code an und ver­glei­che die­sen mit den Funk­tio­nen in der neu­en l10n.php von WP 2.5. Womög­lich musst du ent­spre­chend die neue Funk­ti­on hin­zu­fü­gen und auf den Nativ-Aufruf umlei­ten.
    @Niko:
    Du hast doch Komplett-Zugriff auf dei­nen Ser­ver? Kannst du mal nach­se­hen, ob es irgend­wo ent­spre­chen­de Ein­stel­lun­gen der Spra­che oder (viel­leicht wich­ti­ger) des ver­wen­de­ten Zei­chen­sat­zes (z.B. UTF-8 oder ISO-8859–1) gibt? Has­te schon “de_DE.UTF-8” ver­sucht? Wäre cool wenn du einen System- /Server- /PHP-Parameter fin­dest, der die ori­gi­na­le Lösung zum Lau­fen bringt…
    Grü­ße, Mat­thi­as

    antworten
  58. Niko_K  April 19, 2008

    Ich habe lei­der noch kei­ne wei­te­ren Ein­stel­lun­gen gefun­den.
    UTF-8 scheint jedoch nicht die Lösung zu sein, wenn ich die­sen Para­me­ter in der WP_LANG anhän­ge, dann erscheint alles auf eng­lisch… Wor­d­Press ver­sucht dann nicht ein­mal zu über­set­zen (wie gesagt… ohne das UTF-8 in der WP_LANG bekom­me ich eine Zeit­über­schrei­tung, aber da ver­sucht WP wenigs­tens die Sei­te zu über­set­zen)

    antworten
  59. Kretzschmar  April 21, 2008

    Da ich nicht wirk­lich php5 benö­ti­ge, habe ich kur­zer­hand ein­mal mei­nen Account auf php4 “zurück­ge­stellt”. Seit­dem habe ich kei­ne Pro­ble­me mehr. Mit Hil­fe eines klei­nen Ein­griffs in die .htacess klappt das sogar, ohne den Sup­port in Anspruch neh­men zu müs­sen.
    Unter # END Wor­d­Press in der .htacess
    muss nur hin­zu­ge­fügt wer­den:
    AddHand­ler php4-cgi .php
    (Wenn kei­ne .htacess Datei vor­han­den ist, weil Per­ma­links nicht genutzt wer­den, muss die­se ange­legt wer­den!)

    antworten
  60. Holger  April 22, 2008

    Hmm­ja, scheint bei mir auch zu funk­tio­nie­ren, ich fra­ge mich nur, ob die älte­re PHP-Version zu irgend­wel­chen ande­ren Pro­blem im Betrieb von WP führt…?

    antworten
  61. Kretzschmar  April 22, 2008

    Das soll­te grund­sätz­lich nicht der Fall sein. Allen­falls ein­zel­ne Plug­ins VERLANGEN PHP5. Ich selbst nut­ze z.B. das “Now Rea­ding” Plug­in. Die­ses ver­lang tin der aktu­el­len Ver­si­on eine PHP5 Instal­la­ti­on.
    Da Wor­d­Press offi­zi­ell PHP4.? vor­aus­setzt, ist ALL-INKL nicht mal unbe­dingt etwas vor­zu­wer­fen.
    Ich ärge­re mich nur dar­über, dass ich mona­te­lang sel­ber her­um­pro­bie­ren muss­te. Eine Suche nach unpack() zeigt ja, dass sehr vie­le Web­sei­ten unter die­sem Pro­blem lei­den.

    antworten
  62. Matthias Brusdeylins  April 25, 2008

    Viel­leicht funk­tio­niert auch der Ein­satz von mb_subsr() im Quell­code:
    http://de.php.net/mb_substr
    Man müss­te die oben beschrie­be­ne Code­zei­le 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 einem ame­ri­ka­ni­schen Hos­ter gewech­selt bin.

    antworten
  64. codestyling  Juni 23, 2008

    Ich hab das Pro­blem eben­falls ana­ly­siert und einen per­for­man­ten Ersatz für die spon­tan feh­ler­haf­te PHP sub­str() Funk­ti­on gefun­den.
    Dies hab ich bereits im WP Trac gemel­det und einen Fix bereit­ge­stellt: http://www.code-styling.de/deutsch/wordpress-sprachdateien-erzeugen-fehler-in-gettext-php
    Ich konn­te dies bereits auf einen betrof­fe­nen Sys­tem tes­ten, denn bei mir trat dies nicht auf.

    antworten
  65. Matthias Brusdeylins  Juni 24, 2008

    Dan­ke für den Hin­weis. Doch bedenkt, dass im Pro­gramm­code von Wor­d­Press der Befehl sub­str() noch öff­ters vor­kommt… Womög­lich ist das Fehl­ver­hal­ten von sub­str() nun an einer ande­ren Stel­le sicht­bar…

    antworten
  66. Matthias Brusdeylins  August 15, 2008

    Wor­d­Press lie­fert mit der Ver­si­on 2.6.1 nun end­lich eine Lösung. Dies haben wir wohl dem Ein­satz von “Code­sty­ling” zu ver­dan­ken. Er beschreibt hier die Ursa­che auf sei­ner Sei­te näher:
    http://www.code-styling.de/deutsch/wordpress-fehler-durch-sprachdateien-die-ursache

    antworten
  67. probek  August 16, 2008

    Zei­chen und Wun­der.

    antworten
  68. Paul  August 16, 2008

    Selt­sa­mer­wei­se kommt es bei mir eben­falls zu die­sem Feh­ler, obwohl ich die eng­li­sche WordPress-Version 2.6.1 nut­ze. Hat da jemand eine Idee, wor­an das lie­gen kann?

    antworten
  69. Matthias Brusdeylins  August 24, 2008

    Has­te in dei­ner .htac­cess mal die fol­gen­den Zei­len ver­sucht (sie­he Bei­trag 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, habe ich. Der Feh­ler kommt immer noch 🙁 Bin da völ­lig rat­los.

    antworten
  71. Frank Stolle  Oktober 16, 2008

    Ich hat­te den Feh­ler auch, konn­te Ihn jedoch dank der vie­len Infor­ma­tio­nen behe­ben. Pro­blem ist hier ein Bug in PHP (mod_php). Wenn nur irgend­wer auf dem Ser­ver in der .htac­cess den Wert mbstring.func_overload den Wert auf 0 unter­schied­lich setzt, kann es zu die­sen Pro­ble­men kom­men. Eine nähe­re Beschrei­bung inkl. Patch gibt es unter:
    http://bugs.php.net/bug.php?id=27421&edit=1
    In der nächs­ten PHP Ver­si­on (5.2.7?) soll­te dies dann auch mit auf­ge­nom­men sein.

    antworten
  72. Matthias Brusdeylins  November 3, 2008

    Heu­te bekam ich eine eMail von mei­nem Pro­vi­der All-Inkl:
    “Im Netz habe ich gele­sen das Sie eben­falls von dem wordpress/unpack Pro­blem betrof­fen sind. Ich habe eben auf Ihrem Ser­ver ein aktu­el­les PHP mit dies­be­züg­li­chem Patch instal­liert. Könn­ten Sie mich bit­te dahin­ge­hend unter­stüt­zen zu ver­su­chen den Feh­ler zu pro­vo­zie­ren?
    Dies wür­de mir bei der end­gül­ti­gen Besei­ti­gung erheb­lich hel­fen.”

    Mei­ne PHP-Version lau­tet nun 5.2.6.
    Also falls einem von euch der Feh­ler hier auf mei­ner Web­sei­te begeg­net, lasst es mich bit­te wis­sen…

    antworten

Schreibe einen Kommentar