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 Word­Press setzt sol­che Datei­en für die Über­set­zung ein.

(Gelöst mit Word­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 Word­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. Word­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 Word­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 Word­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 Word­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 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 Word­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 Webspace 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 Word­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! Word­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 Word­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 Word­Press bzw. an deutsch­spra­chi­gen Plugins, d.h., wenn ich auf die eng­li­sche WordPress‐Version zurück­grei­fe und kei­ne deutsch­spra­chi­gen Plugins 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 Webspace 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 Word­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 Word­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 Word­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 Word­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 Word­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 Plugins? Mög­li­cher­wei­se benut­zen wir ja bei­de ein Plugin, wel­ches NEBENBEI die­sen Feh­ler ver­ur­sacht?

    antworten
  12. Matthias Brusdeylins  November 18, 2007

    Hier mal mei­ne instal­lier­te Plugins:
    Akis­met (2.0.2)
    Bre­ad­crumb (0.5.1)
    Easy HTML Meta­da­ta (1.2) — mein Plugin
    Follow‐URL (1.0)
    Gravatars2 (2.7.0)
    Light­box JS v2.03.3 Plugin (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 Plugins 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)
    * Free­Ty­pe Sup­port : Ja
    * Free­Ty­pe Linkage : with free­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 Plugins für Word­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 (Word­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 Word­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 Word­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 Word­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)
    Word­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
    Word­Press gettext‐Problem zu beschäf­ti­gen.
    Das Pro­blem scheint nicht an der neu­en Word­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­ne­r­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 Word­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 ansos­n­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 Word­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 Syt­sems 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 Word­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 Word­Press 2.5 zu instal­lie­ren… Aber prü­fe erst, ob all dei­ne Plugins auch den Ver­si­ons­sprung über­stan­den haben…

    antworten
  53. Kretzschmar  April 6, 2008

    Ich habe bereits Word­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 Plugins 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 Word­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 Word­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… Word­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 Word­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 Plugins VERLANGEN PHP5. Ich selbst nut­ze z.B. das “Now Rea­ding” Plugin. Die­ses ver­lang tin der aktu­el­len Ver­si­on eine PHP5 Instal­la­ti­on.
    Da Word­Press offi­zi­ell PHP4.? vor­aus­setzt, ist ALLINKL 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 Word­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

    Word­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

Lassen Sie eine Antwort, um Matthias Brusdeylins
Klicken Sie hier, um die Antwort abzubrechen


Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.