[TYPO3-german] TYPO3 4.2.x: Jetzt migrieren?

Mon Nov 24 14:54:59 CET 2008

Hallo Michael,

danke für die ausführliche Erklärung.
Nun, den genauen Vorgang habe ich mir nicht angesehen.
Aber ich mache seither bei einem Update ohnehin neben einer 
Datenbank-Sicherung auch eine Sicherung der Konfiguration (Setup und 
Constants).
Somit ist das Problem behoben.
Immerhin hatte ich über 80 T3-Installationen auf den neuesten Stand zu 
bringen.
Mein Server war einmal in Zeiten von V3.8 noch als ISO-8859.
Voriges Jahr habe ich dann alles auf UTF-8 gebracht und heuer hatte ich 
eben diese Probleme damit ...

LG Gerhard

Michael Stucki schrieb:
> Hallo Gerhard & Co.
>
> das von dir beschriebene Szenario trifft zum Glück nur in sehr wenigen
> Fällen zu. Um nicht den falschen Eindruck zu hinterlassen, TYPO3 4.2
> würde bewusst Daten zerstören, möchte ich mich kurz dazu äussern:
>
> Es gelten folgende Voraussetzungen, damit der Fehler auftaucht:
>
> - Es werden Umlaute im Template verwendet
> - Die enthaltenen Daten lassen sich nicht nach UTF-8 konvertieren,
>   sprich sie sind bereits früher in einem falschen Zeichensatz
>   gespeichert worden.
>
> Eine Möglichkeit dafür wäre z.B., dass jemand seine DB via MySQL direkt
> von ISO-8859-1 nach UTF-8 konvertiert hat, als die betroffenen Felder
> noch vom Typ "blob" waren. MySQL würde dabei die Inhalte als binär
> betrachten und sie darum nicht konvertieren. Das Ergebnis wäre ein UTF-8
> kodiertes Feld mit ISO-8859-1 Inhalt.
>
> Der eigentliche Fehler passiert bei der anschliessenden Konvertierung
> des Felds von "blob" nach "text" wie in TYPO3 4.2 implementiert. Da das
> "blob"-Feld Daten enthält, welche nicht UTF-8 sind, wird MySQL alles
> hinter dem ersten fehlerhaften Zeichen abschneiden, ohne dabei den
> Benutzer zu informieren.
>
> Der User könnte diesen Fehler im Voraus feststellen und beheben, indem
> er vor dem Update das betroffene Template einmal bearbeitet und
> entsprechend anpasst. Der Umlaut wird - wenn betroffen - ziemlich
> kryptisch (etwa in Form eines schwarzen Kästchen) dargestellt.
>
> Das bedeutet: Würde man zu diesem Zeitpunkt den fehlerhaften Eintrag
> korrigieren, dann wäre der Fehler danach behoben.
>
> So oder so ist die Konvertierung nach "text" welche in TYPO3 4.2 erfolgt
> ist ein richtiger und vor allem wichtiger Schritt, denn nur so können
> wir genau solche Probleme in Zukunft (irgendwann kommt UTF-16 usw.)
> verhindern.
>
> Ich denke nach wie vor, dass der Fehler hierbei vor allem auf Seite von
> MySQL liegt, welches ungefragt Daten entfernt. Wäre ich MySQL, würde ich
> das Query an der Stelle mit einem Hinweis abbrechen, den man dann
> explizit ignorieren muss.
> Ausserdem würde ich wenn schon nur das betreffende Zeichen abschneiden
> und nicht gleich alles was dahinter steht.
>
> Trotz allem: Anhand der Anzahl Feedbacks auf dieses Problem bin ich mir
> sicher, dass nur einige Ausnahmefälle davon betroffen sind bzw. waren.
>
> Liebe Grüsse
> - michael
>
> Gerhard Obermayr schrieb:
>   
>> Hallo Manfred,
>>
>> ich würde beim migrieren auf 4.2.x einmal gar nicht so auf die
>> Extensions schauen.
>> Viel wichtiger wird sein, das Setup und die Constants vorher zu sichern.
>> Oder Du schreibst alle Umlaute um - Ä --> Ae, ö --< oe, ß --> ss und so
>> weiter.
>> Wenn Du nämlich dort Einträge mit Umlauten hast wird ab dem ersten
>> Umlaut allse weitere abgeschnitten.
>> Im Klartext:
>> Das Problem beim Update ist es, dass T3 die blob Felder auf text Felder
>> umwandelt - dann kickt mysql alles ab dem ersten Umaut, da die blob
>> Felder keine UTF-8 Zeichen enthalten...
>> Super gemacht von den T3 Entwicklern ;) - die schieben aber die Schuld
>> wieder auf MySQL und so weiter.
>> Wobei zu bemerken wäre, dass MySQL 5 früher da war als TYPO3 4.0.x ...
>> Eh schon wissen wie das ist.
>> Wäre schön, wenn das auch einmal offiziell auf der download-Seite stehen
>> würde und man nicht alle doof im Regen stehen ließe.
>> Noch besser wäre es natürlich, wenn beim Update-Vorgang darauf verwiesen
>> würde mit der Frage, ob man damit einverstanden ist - oder ähnlich.
>> Oder gleich automatisch konvertiert. Wo anders geht das ja auch!
>> Mir ist es nun schon zum wiederholten Male so gegangen, aber derzeit
>> habe ich alle Websites auf 4.2.1 und hoffentlich kommt nicht wieder bei
>> einem Update so ein Blödsinn ...
>> Trotz allem aber bin ich ein notorischer Verfechter von TYPO3 ...
>>
>> Liebe Grüße aus Haag
>> Gerhard Obermayr
>>
>> _______________________________________________________
>>
>> A-3350 Haag, Holzleiten 83
>> +43 7434 42181 - Fax: DW 25
>>
>> URL Firma: http://www.cgc.at - E-Mail: design at cgc.at
>>
>> URL`s Privat:
>> http://www.cgc.co.at
>> http://www.gerhard-obermayr.com
>> http://www.alpha-foto.at
>> http://www.hdr-foto.at
>> _______________________________________________________
>>
>> Widmann, Manfred schrieb:
>>     
>>> Ok, klar, das Problem liegt eigentlich beim Umsteieg von PHP4 auf
>>> PHP5, das ist aber Haarspalterei, denn was bleibt, sind Probleme, die
>>> man fixen muss. Ich steige ja nciht aus Gaudi auf PHP5 um, sondern
>>> weil mich 4.2. dazu zwingt, oder? Aber: Streit um des Kaisers Bart ...
>>>
>>> Und das mit der Wahlfreiheit ist auch so eine Sache: Früher oder
>>> später wird man migrieren müssen, weil es für 4.1. einfach keine neue
>>> Versionen (vom Core und von den Extensions) mehr geben wird - war das
>>> nicht schon beim jüngsten Security-Fix von phpmyadmin so, den es nur
>>> für 4.2. gibt?
>>>
>>> Also wie gesagt: Eine Liste wäre schön, in der inkompatible Extensions
>>> verzeichnet sind - könnte man nicht das Repository nach den häufigsten
>>> Kompatibilitäts-Killern durchsuchen und die so eruierten Ext.
>>> markieren? Heißt zwar nicht, dass die anderen kompatibel sind, würde
>>> aber ungemein helfen ... zumindest könnten dann auch die
>>> Ext.-Entwickler angemailt werden und um einen entsprechenden Fix
>>> gebeten werden.
>>>
>>> Ist ja schon peinlich, wenn - egal aus welchem Grund - die
>>> Aufwärtskompatibilität plötzlich nicht mehr gegeben ist! Da kann man
>>> stehen, wo man will, aber wenn nach der Installation einer neueren
>>> Version plözlich alte Sachen nicht mehr funktionieren ... na ja!
>>> Sauber ist was anderes, das muss ich bei aller Leidenschaft für TYPO3
>>> schon sagen. Und genau das sollte der Anlass sein, dieses Problem so
>>> gut wie möglich abzufedern - also z.B. durch eine Inkompatibilitätsliste.
>>>
>>> lg
>>> Manfred
>>>
>>>  
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> TYPO3-german mailing list
>>> TYPO3-german at lists.netfielders.de
>>> http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-german
>>>       
>
>
>   