WebsiteBaker Support (2.10.x) > Hilfe & Support (deutsch)

Update auf 2.10.0 scheitert

<< < (5/6) > >>

xandi:
nochmals vielen dank!

für alle mit gleichem problem. ERST DEN TIPP VON JAKOBI22 ausführen. Der funzt!

Nur bei den seiten die ich zwischenzeitlich manuell ausgebessert habe nicht. da steht jetzt überall ein kasten mit Fragezeichen statt der Umlaute :x

jacobi22:
ein "Kasten mit Fragezeichen" steht für ein Zeichen, das in deinem verwendetem Zeichensatz nicht enthalten ist. Ursache (in aller Regel) ein Umschreiben der alten Table_Collation zur neuen, oft durch Import mit anderem Zeichensatz als das Original

Eventuell wurde auch ein mit UTF8-codiertes Zeichen beim Speichern und der gleichzeitigen Benutzung eines anderen Zeichensatzes als UTF8 (einfach gesagt) nochmals codiert und aus einem ü wird dann z.B. ein ü

Ist man mit PHPmyAdmin, Adminer oder wie Datenbankverwaltung sprogramme alle heißen, vertraut, korrigiert man es am besten gleich dort, setzt natürlich voraus, das man weiß, in welcher Tabelle was drin steht

Eine andere Methode für einen Laien wäre das Einspielen der vorhandenen Datenbank-Backup-Datei und ein erneutes Starten des Upgrade-Scripts über solch Verwaltungsprogramm, allerdings ist das für viele Leute auch ein Angstthema, darum ist der Weg über die manuelle Korrektur oft doch der einfachste.

P.S.: Wichtig für die Darstellung im Frontend ist dort natürlich auch der korrekte Zeichensatz.
Dieser wurde in den meisten WebsiteBaker-Templates durch solch Code flexibel gehalten, d.h. es wird auch die WB-Zeichensatzeinstellung (utf8) ausgelesen.

früher mit

--- Code: ---<meta http-equiv="Content-Type" content="text/html; charset=<?php if(defined('DEFAULT_CHARSET')) { echo DEFAULT_CHARSET; } else { echo 'utf-8'; }?>" />
--- End code ---

heute ab WB 2.8.3 SP7 reicht dieser Code

--- Code: ---<meta charset="utf-8" />
--- End code ---

Hier lohnt auch immer mal ein Blick in den Quellcode der Frontend-Seite, ob dort auch wirklich utf8 drin steht

xandi:
Uff, man merkt sofort wer sich auskennt und wer nicht! :-(  ich bin´s auf jeden Fall nicht.

ich denke das liegt daran dass der Befehl mit utf-8 nichts gebracht hat, der mit define('DB_CHARSET',      'utf8mb4_unicode_ci'); dagegen ging.

ich habe nun zu fuss alles ausgebesserte ausgebessert. dabei ist folgende seltsamkeit passiert. manche texte war im frontend zu sehen und im backend nicht  :-o :-o :-o
Laienhaft habe ich die Texte rüberkopiert. ob das eine gute Idee war weiß ich nicht! ich hoffe das ganze system ist nicht nun total verschossen.

kann oder soll ich denn nun auch das update auf 2.11.0 wagen?

ruebenwurzel:
Hallo,

hatte auch mal das Problem, dass nach Umstellen auf UTF8 insbesonders in der Datenbank abgespeicherte Sonderzeichen von Textfeldern von WB aber auch von einigen Modulen falsch dargestellt wurden. Da ich zu faul war alles händisch zu suchen und zu ersetzen bin ich damals einen anderen Weg gegangen. Folgende Schritte habe ich unternommen:

1.) Export der gesamten Datenbank in einne .sql Datei (über phpmyadmin)
2.) Editieren dieser Datei mit einem Texteditor (Notepad++)
3.) Importieren der bearbeiteten Datei wieder in die Datenbank.

Beim Editieren (Punkt 2) gibt es mehrere Möglichkeiten:
- entweder über suchen und ersetzen alle falschen Zeichen ersetzen
- oder die Textdatei in UTF8 konvertieren (meine bevorzugte Version)

Die Schritte beim konvertieren habe ich mir leider nicht notiert, insofern kann es sein dass die folgenden Schritte in der falschen Reihenfolge dargestellt sind. Muss das später noch einmal durchexerzieren, und würde gegebenenfalls die richtigen Schritte nochmals posten.
- Die Datei, die phpmyadmin liefert ist vermutlich eine UTF8 Datei.
- Diese Datei muss man dann speichern unter ANSI (nicht konvertieren !!)
- Dann die ANSI Datei konvertieren in UTF8
Bei dieser Konvertierung ist es völlig wurscht, wo Sonderzeichen sind, am Ende sollten dann alle Sonderzeichen korrekt in der Datenbank stehen (also "ö" als "ö" und nicht als Zeichenwirrwarr)

Da man sich bei dieser Aktion die Inhalte der Datenbank auch sehr schnell komplett zerlegen kann, bitte immer die im ersten Schritt exportierte .sql Datei als Sicherung separat abspeichern. Falls beim konvertieren und einspielen irgenetwas schief geht, kann man dann die Sicherung wieder einspielen und man hat zumindest den Ursprungszustand wieder.

Die Konvertierung muss in der Regel nur bei älteren WB-Installationen durchgeführt werden. Aktuelle Installationen von WB 2.10 und WB 2.11 sollten alles korrekt darstellen. Da ich WB bereits seit Version 2.3.1 (ja, die gab es auch mal) einsetze und sowohl WB als auch die damaligen Webserver mit dem Zeichensatz sehr abenteuerlich umgegangen sind, musste ich viele Datenbanken nachträglich konvertieren. Habe das aber schon vor einigen Jahren gemacht, so seht mir bitte nach, wenn in obiger Anleitung ein Fehler drin ist. Das schöne am konvertieren ist, hat man einmal seine Datenbankinhalte sauber auf UTF8 konvertiert und setzt eine aktuelle WB-Version ein, hat man nie mehr Probleme mit Sonderzeichen.

Gruß
Matthias

jacobi22:

--- Quote ---define('DB_CHARSET',      'utf8mb4_unicode_ci'); dagegen ging
--- End quote ---

What??   :-o :-o :-o
war da schon WB 2.11 drauf oder wurde solch Install/Upgrade auf WB 2.11dort schon versucht?


--- Quote ---kann oder soll ich denn nun auch das update auf 2.11.0 wagen?
--- End quote ---

Wenn du mich fragst, darf ich hier eh nur mit JA antworten. Ich halte es aber durchaus für möglich, das in der Datenbank 4-Bit-Zeichen (utf8mb4) vorhanden sind statt den für utf8 üblichen 2-Bit Zeichen
Wer nicht wagt, der gewinnt auch nicht ;-)

Eventuell löst sich das Problem dann auch in Luft auf   :wink:

Navigation

[0] Message Index

[#] Next page

[*] Previous page