Fehlermeldungen nach Update auf 2.5

Da ich nicht testen kann, warum das 1. Zeichen verschoben ist, würde aus
"Artikel schreiben" -> "rtikel schreibenA"
Der 1. weg, dafür von folgenden "Artikel löschen" das A hinten dran.

Passiert der Fehler auch im Frontend ? Dann müssten doch nur Fehlermeldung ausgeliefert werden oder ?

Ja manchmal trat der Fehler auch im Frontend auf. Genau wie Du sagst, erschien dann nur eine weiße Seite mit der besagten Fehlermeldung. Wir können mal folgendes machen: Ich könnte Dir nen FTP Account einrichten und dann kannst Du Deine Test auf meinem Testblog fortführen, quasi am lebenden Objekt.

Zitat von infected

Ja manchmal trat der Fehler auch im Frontend auf. Genau wie Du sagst, erschien dann nur eine weiße Seite mit der besagten Fehlermeldung. Wir können mal folgendes machen: Ich könnte Dir nen FTP Account einrichten und dann kannst Du Deine Test auf meinem Testblog fortführen, quasi am lebenden Objekt.

Ich hab da noch einen Vorschlag: Wir "müllen" das Thema hier erstmal nicht weiter zu als unser persönlichen Chat :mrgreen: sondern ich schickt dir meine E-Mail Adresse und Skype Kontakt, sofern du Skype hast, das geht einfacher.

Und ich würde eine Protokollfunktion in der gettext.php erstmal einbauen, die den Fehler erkennt und in dem Falle ein Logfile (Text) schreibt mit Zeitstempel, Serverauslastung und Fehlerstelle. Dann kann man das auch mal mit den Logs vergleichen und schauen, was in diesem Moment passiert ist.

Zitat von codestyling

Sehr gut möglich. Aber evtl. könntest du ein var_dump für die ersten 10 Einträge hier reinbauen (gettext.php):
[...]
und das Ergebnis im Fehlerfall bereitstellen ?

Hab ich gemacht. Hier das Ergebnis:

array(1) { [1]=> int(-1794895138) } array(1) { [1]=> int(1577058304) } array(1) { [1]=> int(469762056) } array(1) { [1]=> int(201326592) } array(1) { [1]=> int(687865923) }

Zitat von codestyling

Ich hab noch einen, gerade im Labortest: Da es ja offensichtlich die Index Adressierung zu den Strings zermüllert (manchmal jedenfalls), wäre es eine Option, einen korrekten Index (ohne Absturz und ohne substr) zu haben, auch wenn dann die Beschriftungen evtl. um 1 Zeichen verschoben sind (1. fehlt, dafür 1. von nächsten hinten dran) und der Speed dem von vorher entspricht?

Ist zwar auch eine Krücke aber besser als keine Seite ausliefern. Und im Frontend sollte es deutlich weniger auffallen und wenn dann beim nächsten Reload ggf. weg sein.

Die Strings sind nicht vorne abgeschnitten und hinten verlängert, sondern vorne verlängert und hinten abgeschnitten, daher kann es sein (nicht nachgeguckt), dass eine 0 am Ende des vorherigen Strings dem Nachfolgestring gleich ein Ende macht. Ich habe das zum testen mal auf die Schnelle implementiert und es kam dann im Fehlerfall immer die englische Seite. Für mich ist das keine Lösung, denn der Fehler tritt ständig auf.

Vielleicht hab ich am Wochenende mal Zeit mir das genauer anzusehen und eine "echte" Lösung zu implementieren. Wahrscheinlich werde ich das .mo-File parsen und auf ewig große Strings verzichten.

Zitat von Beatinu

Die Strings sind nicht vorne abgeschnitten und hinten verlängert, sondern vorne verlängert und hinten abgeschnitten, daher kann es sein (nicht nachgeguckt), dass eine 0 am Ende des vorherigen Strings dem Nachfolgestring gleich ein Ende macht.

Musst du mir mit deinen Daten mal erklären:

DE 12 04 95 [COLOR=Red]00[/COLOR] [COLOR=Blue]00 00 00 5E[/COLOR] 08 00 00 1C 00 00 00 
-1794895138    FFFFFFFF950412DE
1577058304  [COLOR=Blue]5E000000[/COLOR]
469762056   1C000008
201326592   0C000000
687865923   29000043

Mit diesem 1 Byte Offset auf Strings bezogen, fehlt leider das 1. Zeichen, weil er ja den String um 1 Byte zu weit hinten anfängt zu interpretieren.
... wollt ich nur mal gesagt haben. :)

Zitat von codestyling

Mit diesem 1 Byte Offset auf Strings bezogen, fehlt leider das 1. Zeichen, weil er ja den String um 1 Byte zu weit hinten anfängt zu interpretieren.
... wollt ich nur mal gesagt haben. :)

Da hatte ich einen Endian-Knoten im Hirn ;-) Du hast recht.

Nur für diejenigen, die hier mitlesen und Hilfe suchen. Ein Patch ist in Kooperationsarbeit mit infected im Test und wird veröffentlicht, wenn er so funktioniert, wie er soll. Dann ist der Speed immer wie im Originalzustand nur der Fehler tritt dann nicht mehr auf.
Sobald das durchgetestet ist und Bestand hat, werde ich das veröffentlichen und bei WordPress einen Patch einreichen.
Anmerkung: Der Fehler ist nicht die Schuld von WordPress , so wie es derzeit aussieht, ist das ein PHP/Apache Fehler.

error in gettext.php gelöst

Ich hab heute den Fehler und die Lösung an WordPress Trac weitergegeben, vielen Dank nochmal an infected für die Unterstützung bei der Suche nach dem Fehler und dessen Lösung.

Für die Eiligen unter euch hab ich das nochmal erklärt und einen Patch Download bereitgestellt, solange das nicht offiziell zu haben ist:
Code Styling Project » WordPress Sprachdateien erzeugen Fehler in gettext.php

Feedback und Kritik gleichermaßen erwünscht.

Kurzes Zwischenfeedback nach 2 Wochen Testerei... Bei mir gab´s seitdem keinerlei Probleme mehr. :mrgreen:

Wollte nochmal schnell ne Rückmeldung bezgl. des Patches geben. Nach etlichen Wochen testen, funktioniert immer noch alles reibungslos (auch mit der aktuellen 2.6). Danke nochmal an codestyling für sein Engagement.

Sehr schön. Mittlerweile gibt es, basierende auf dem finalen 2. Patch, den ich ebenfalls veröffentlicht habe, einen offiziellen Patch in WP 2.6, der mit der 2.6.1 ausgeliefert wird: Changeset 8421 - WordPress Trac - Trac