Author Topic: Fehlerhafte Umlaute nach Umstellung von PHP5.4. nach PHP5.6. oder PHP7  (Read 1958 times)

Offline ra-wi

  • Posts: 187
  • Gender: Male
Hallo,
ich möchte die Version 2.8.3SP6 auf 2.8.3SP7 upgraden. Dazu habe ich zunächst die PHP-Version bei Alfahosting von 5.4 auf  PHP7 umgestellt. Daraufhin wurden die Umlaute in der Navigation nicht mehr korrekt dargestellt. Eine Rückstellung versuchsweise auf PHP5.6 brachte keinen Erfolg. Nach Umstellung wieder zurück auf PHP5.4 war alles wieder ok.

Der Fehler tritt nur in der horizontalen Navigation auf. Alle anderen Texte im Backend und Frontend sind nicht betroffen. Ich habe mal ein jpg in die Anlage hochgeladen.

In den WB-Optionen ist utf-8 eingestellt. Im Template ebenfalls (<meta http-equiv="Content-Type" content="text/html; charset=<?php
   echo defined('DEFAULT_CHARSET') ? DEFAULT_CHARSET : 'utf-8'; ?>" />)

Ein Test mit dem Template "Round" brachte übrigens den gleichen Fehler.

Also zusammenfassend tritt der Fehler erst ab PHP 5.6. bis PHP7 auf.

Kann mir da jemand helfen ?

Danke schon mal im Voraus und LG... Rainer



Offline dbs

  • Betatester
  • **
  • Posts: 8012
  • Gender: Male
  • tioz4ever
    • WebsiteBaker - jQuery-Plugins - Module - Droplets - Tests
Re: Fehlerhafte Umlaute nach Umstellung von PHP5.4. nach PHP5.6. oder PHP7
« Reply #1 on: February 06, 2017, 11:06:13 PM »
Hallo, du wirst sicher schon einiges gelesen haben zum Thema UTF8 hier im Forum. Kein einfaches Thema.
Wenn du das durch Korrigieren der Menütitel beheben kannst, ist alles gut.

Offline ra-wi

  • Posts: 187
  • Gender: Male
Re: Fehlerhafte Umlaute nach Umstellung von PHP5.4. nach PHP5.6. oder PHP7
« Reply #2 on: February 07, 2017, 08:40:51 AM »
Ja, ich habe einiges hier gelesen und soeben sogar "zufällig" das Richtige hier  :-)
http://forum.WebsiteBaker.org/index.php/topic,29413.msg206257.html#msg206257

Die config.php wurde erweitert mit: define('DB_CHARSET', 'utf8');

Und siehe da, alles wird korrekt dargestellt.

Danke und Gruß..... Rainer

Offline Herbert

  • Posts: 30
Re: Fehlerhafte Umlaute nach Umstellung von PHP5.4. nach PHP5.6. oder PHP7
« Reply #3 on: February 08, 2017, 03:18:20 PM »
...hab zwar fachlich nichts wesentliches dazu beizutragen, aber mir war bei meinen Seiten nach der Umstellung aufgefallen, dass in den Beschreibungstexten einzelner Seiten ebenfalls die Umlaut-Steuerzeichen vorhanden waren und habe dann den Kopf jeder Seiten nochmals auf korrekte Schreibweise überprüft und ggf. händisch korrigiert. :-)

Herbert

Offline ra-wi

  • Posts: 187
  • Gender: Male
...hab zwar fachlich nichts wesentliches dazu beizutragen, aber mir war bei meinen Seiten nach der Umstellung aufgefallen, dass in den Beschreibungstexten einzelner Seiten ebenfalls die Umlaut-Steuerzeichen vorhanden waren und habe dann den Kopf jeder Seiten nochmals auf korrekte Schreibweise überprüft und ggf. händisch korrigiert. :-)

Herbert

Nachdem ich nun schon wieder das Problem bei einem anderen Upgrade hatte und mit der Ergänzung der config.php das Problem scheinbar nicht gelöst wurde (Umlaute immer noch nicht korrekt) verstehe ich jetzt erst Herberts Hinweis :-)

Bei allen neu erstellten Seiten werden die Umlaute korrekt dargestellt. Die nicht korrekt dargestellten Menüpunkte habe ich dann einfach entsprechend mit den korrekten Umlauten geändert. Erst dann werden sie richtig dargestellt.

Danke :-)

Offline sabo-!

  • Posts: 121
Ich habe zwischenzeitlich etliche Homepages auf WB 2.10.0 upgegraded. Von verschiedenen Providern und von verschiedenen Vorversionen.  Bei allen Upgrades auf WB 2.10.0 gab es Umlautprobleme. Bei früheren Upgrades der anderen Versionen, z.B. auf SP7, etc. trat das Problem bei mir nicht auf. Nicht ein einziges Mal.

Gerade gestern habe ich extra drauf geachtet, dass in der Datenbank die richtige Codierung hinterlegt ist. Egal. Umlautprobleme bei allen Titel und Beschreibungen auch in allen eingesetzten Modulen und sogar im Contentbereich. Im Contentbereich jedoch nicht auf allen Seiten, aber auf fast allen. Es machte auf mich den Eindruck, dass die Umlautprobleme, die im Contentbereich auftraten, nur solche Seiten betrafen, die mal zuvor mit SP7 editiert wurden (zumindest in dem Fall gestern). Seitencontent, der nach dem SP7 Upgrade nicht mehr bearbeitet (gespeichert) wurde, war vom Umlautproblem nach WB 2.10.0 nicht betroffen.

Die hier im Forum erwähnte Ergänzung der config.php nützte nichts.

Alles manuell anzupassen ist schon echt ne Nummer, vor allem, wenn es umfangreichere Seiten sind.

Offline jacobi22

  • Posts: 5865
  • Gender: Male
  • Support also via PM or EMail
    • Jacobi22
Zur Problematik gibt es jede Menge Threads, z.b. den hier -> https://forum.WebsiteBaker.org/index.php/topic,29984.msg210588.html#msg210588

Ursächlich ist die Änderung des Standard-Zeichensatzes innerhalb von PHP ab Version PHP 5.5. (vorher per default leer, ab PHP 5.5 per default auf UTF8) Ab PHP 7 wirst du kaum noch Anbieter finden, die etwas anderes als UTF8 im Angebot haben. Neuverträge oder neue Datenbanken werden standardmäßig auf UTF8 gesetzt. Man kann sich das wohl alles wieder auf alte Charsets anpassen, verschiebt damit aber nur das Problem der nötigen Umstellung. WB hat sich (ab WB 2.8.3 SP7) dieser Entwicklung angepasst und verwendet ebenfalls nur noch UTF8 innerhalb von WB, also auch bei der Verbindung zur Datenbank.
Das funktioniert in Neuinstallationen auch ohne Probleme, weil eben alles auf diesen Zeichensatz ausgerichtet ist.
Es macht allerdings Probleme bei älteren Datenbanken, wenn dort in der Vergangenheit etwas anderes als UTF8 verwendet wurde, z.b. das im deutschsprachigem Raum früher beliebte ISO 5589-x, in der Datenbank-Collation mit latin-xxx gekennzeichnet.
Das Ganze ist übrigens kein WB-Problem, es zieht sich durch alle Content Management Systeme im deutschen Sprachraum.
Die meisten Leute, die mit Webseiten und CMS beruflich zu tun haben, verwenden immer schon diesen Zeichensatz (UTF8), weil sich damit eben auch jedes Schriftzeichen der Welt darstellen läßt und wer mehrsprachige Seite betreut, kommt da eh nicht drum herum.

Quote
Gerade gestern habe ich extra drauf geachtet, dass in der Datenbank die richtige Codierung hinterlegt ist
ist eher untypisch, das da wer hinschaut  :wink:

Quote
Umlautprobleme bei allen Titel und Beschreibungen auch in allen eingesetzten Modulen und sogar im Contentbereich
Contentbereich? - hier sollte zumindest alles, was in Wysiwyg-Sectionen steht ohne Probleme dargestellt werden oder eine der Einstellungen stimmt nicht, passt nicht mit dem Rest zusammen.

Quote
Es machte auf mich den Eindruck, dass die Umlautprobleme, die im Contentbereich auftraten, nur solche Seiten betrafen, die mal zuvor mit SP7 editiert wurden

kommt auf den Editor und deren Einstellungen an. In älteren CKEditor-Versionen war die Voreinstellung in der include.php auf Verwendung von HTML-Entities ( aus einem ä wird in der Datenbank dann ein &auml; ). Diese Voreinstellung wurde im Editor, der ab SP7 verwendet wurde, deaktiviert,
Code: [Select]
$ckeditor->config['entities'] = false;weil es in der reinen Verwendung in einem UTF8-System nicht notwendig ist und die Kodierung von Sonderzeichen durch die Einstellungen der Zeichensätze in WB und der Datenbank übernommen wird.

Hast du denn beim Upgrade irgendetwas an der Datenbank gemacht? Es gibt ja hier und im Web unzählige Hinweise, wie eine Konvertierung alter Zeichensätze nach UTF8 erfolgen soll.
Wurde da etwas konvertiert, z.b. mit Notenpad++ die Backup-SQL-Datei umschreiben lassen, liegt der Fehler wohl beim Import der konvertierten Datei zurück in die Datenbank.
Wurde nichts konvertiert, fehlt genau dieser Schritt

Auch möglich: in der Datenbank ist alles korrekt, aber im Frontend-Template steht ein falscher Zeichensatz.

Ein einfacher Test wäre die manuelle Korrektur eines betroffenen Seiten- oder Menütitels in den jeweiligen Seiteneinstellungen . Als Beispiel: ein Menü-Titel "Über uns", der im Frontend falsch dargestellt wird, in den Seiteneinstellungen genau so neu eintragen "Über uns" (egal, was schon im Feld steht), dann im Frontend kontrollieren. Wird er immernoch falsch dargestellt, liegt das Problem in der Datenbank (default-charset, table_collation etc)
Das in den (erweiterten) WB-Einstellungen UTF8 als Zeichensatz eingestellt sein muß, setze ich voraus. Diese Einstellmöglichkeit wird wohl verschwinden, da WB nur noch mit UTF8 läuft. Ich weiß aber nicht, ob dieser Schriftsatz in der DB-Tabelle settings automatisch umgeschrieben wird, wenn da vorher etwas anderes als UTF8 drin stand.

P.S.: solch Konvertierung auf UTF8 ist eine einmalige Sache, einmal richtig durchgeführt, sollte man nie wieder Probleme damit haben. Weltweit sind es sicher mehr als 90% aller Webprojekte, die diesen Zeichensatz verwenden, das wird niemand wieder ändern.
Hausgemachte Probleme, die es in einigen Modulen noch gibt (z.b. diverse xxx_encode oder xxx_decode) können natürlich immernoch Probleme machen, aktuell fällt mir aber keines mehr ein, das solche Methoden verwendet außer zur Erstellung von Emails an die User.
Wer nicht will, findet Gründe, wer will, findet Wege.