Formbuilder kann keine Umlaute?

rage_all · 27. März 2018 13:50

Hallo zusammen,

ich bin verpuzzelt. FormBuilder hat mir stets gute Dienste geleistet und nie Schwierigkeiten gemacht. Jetzt komme ich kein Stück der Lösung näher und verzweifle langsam... neutral

Die komplette Seite ist einwandfrei mit Sonderzeichen und Umlauten dargestellt. Lediglich FormBuilder weigert sich und wandelt mir alles was nicht Standardzeichensatz ist, in Zeichen um.
Wenn ich in meinem Profil den Vorschaueditor deaktiviere und im Nur-Text-Mode die Felder bearbeite, gibt es kein Problem.

Tatsächlich wird mir das, was in der Datenbank als "ö" gespeichert ist, in dieses Fehlersymbol gewandelt.
Wäre vielleicht nicht mal sooo tragisch (immerhin kann man es ja mit etwas Aufwand fixen, direkt in der Datenbank oder eben ohne TinyMCE) ... aber ich kann nicht mal eine Checkbox einbauen, da das Symbol dann auch irgendwo und irgendwie zwischen dem Input und dem Label ausgegeben wird.

Ich hab

die Datenbank gecheckt
die Kollation und Datenbank anders codiert im PHPmyAdmin
eine ganz frische Installation der letzten CMSms Version mit ganz neuer Formbuilder-Instanz
die Ausgabevorlage zurückgesetzt
...

mir fällt nichts mehr ein, was ich noch tun könnte. Und das Ganze, der Ironie halber, eben einen Buchstaben neben den anderen Inhalten, die einwandfrei passen:

Das kommt schon so im Quelltext:

Leider finde ich im Netz auch nach der dritten Stunde Suchen keinen richtigen Hinweis. Umlaute und Sonderzeichen mit Formbuilder wurde zwar schon in diversen Foren beschrieben - aber entweder vor hundert Jahren oder das Problem war ein völlig anderes.

Wonach könnte ich noch suchen - was könnte noch dahinter stecken?
Vielen Dank für Eure Ideen! smile

Andynium · 02. April 2018 09:08

Ohne genauer hinzuschauen hätte ich vermutet, dass du evtl. noch den set_names Parameter in der config explizit setzen müsstest.

rage_all schrieb:

Wenn ich in meinem Profil den Vorschaueditor deaktiviere und im Nur-Text-Mode die Felder bearbeite, gibt es kein Problem.

Eigentlich hast du doch damit deine Frage schon selbst beantwortet, wer hier der Schuldige ist tongue . In Zeiten von UTF-8 gibt es keinerlei Grund mehr, Sonderzeichen in Entitäten umzuwandeln.

https://www.askingbox.com/question/tiny … d-entities

Keine Ahnung, ob das aktuelle Tiny Modul einen derartigen Parameter im Backend hat oder du ggf. manuell in die TinyMCE config eingreifen musst.

rage_all schrieb:

Tatsächlich wird mir das, was in der Datenbank als "ö" gespeichert ist, in dieses Fehlersymbol gewandelt.

Wie gesagt, dass darf erst gar nicht nicht in die Datenbank.

rage_all · 03. April 2018 09:08

Vielen Dank für Deinen Input.
Der set_names Parameter hat nichts weiter geändert. Den habe ich auch sonst bei keiner Installation je gebraucht ... aber gut, sonst bin ich auch nicht bei Strato - das könnte ja irgendwie Fehlerursache sein. hmm

Den Tiny abzuschalten um am FormBuilder zu arbeiten wäre nervig genug - aber machbar (oder alternativ in die Datenbank zu gehen um dort UTF-8 Zeichen zu setzen). Wie dem auch sei, löst es das Problem nicht.

Warum der vorliegende Fall mir wirklich solches Bauchweh gibt, ist weil ich Checkboxes im Formular benötige und die logischerweise beschriften will. Der FormBuilder schlägt mir aber zwischen <input> und <label> das Fragezeichen:
Fragezeichen zwischen Input und Label

Hier der Code im Ganzen:

Hier klicken, um den Code zum Kopieren zu markieren

[== HTML ==]
<div class="required">
  <input type="checkbox" class="form-control" name="cntnt01fbrp__48" value="t"  required id="fbrp__48" />
? <label for="fbrp__48"><span></span> Einverstanden</label>
</div>

Dabei spielt es keine Rolle ob ich den <span> Tag in der Beschriftung habe oder nicht (ich hab das für ein CSS Design das auf dem span liegt). Sobald der <label> Tag nicht leer ist, sprich überhaupt gedruckt wird, kommt zwangsläufig das Fragezeichen vor dem <label>.

Klar geht noch ein (weiterer) Workaround indem ich noch statische Texte zu den Checkboxes hinterlege (auf das wird es jetzt wohl auch hinauslaufen) — aber das kann doch nicht die Lösung sein?

Nochmal anders: Im normalen Content werden meine Sonderzeichen auch in Entitäten umgewandelt. In der ganzen Datenbank existiert kein einziges ä, ö, ü, ß oder sonstiges. Tatsächlich sind in der Datenbank 'ä' vorhanden, z.B. beim Titel, also nicht-Tiny Feldern. Trotzdem: Das einzige Problem liegt doch bei den Inhalten die durch den {FormBuilder} Tag in die Seite kommen. Nur hier müsste ich meine Sonderzeichen 1:1 hinterlegen und hab dann noch immer Probleme. Also steckt doch der Fehler irgendwie hier?

Ich hab sowohl den FormBuilder als auch diese Methode seit Jahr und Tag und noch nie Schwierigkeiten gehabt. Das einzige worüber ich mir beim FormBuilder je (beiläufigst) Gedanken gemacht habe, war die Performance. Um einen Bug in einer neueren Version auszuschließen (oder Upload-Fehler) habe ich Backups von anderen Installationen eingespielt mit demselben Ergebnis. Der Fehler liegt also irgendwie an diesem Hoster oder Datenbank; der CMSms-Version 2.2.7 (hab aber extra deswegen upgedated von weiß-ich-woher - das war in einer tieferen Version bereits); oder etwas ganz, ganz anderem. sad

Beitrag geändert von rage_all (03. April 2018 09:14)

Janl · 03. April 2018 10:43

mal versucht mit eine UDT als erste Zeile in deine Templates

Hier klicken, um den Code zum Kopieren zu markieren

[== php ==]
setlocale (LC_TIME, 'de_DE.UTF8');

Wenn das nicht hilft mal beim Hoster nachfragen welche locales im OS geladen sind, wenn eine fehlt funktionieren Umlauts auch nicht.

MfG
Jan

Beitrag geändert von Janl (03. April 2018 10:44)

rage_all · 03. April 2018 11:02

Hallo Jan,

Danke, hat aber auch nichts gebracht.
Wenn ich im Template {$smarty.now|date_format:"%A %Y-%m-%d %H:%M:%S"} ausgeben lasse, kommt auch "Dienstag ..." stets ohne Probleme, ob mit oder ohne locale-Setting. Wie gesagt - die komplette Seite funktioniert, nur der FormBuilder nicht. Hab ich noch nie erlebt...

Dann mach ich jetzt statische Texte vor die Checkboxes, es hilft ja nichts. Sonst hätte ich wirklich gern eine Grafik über den <span> gelegt damit es hübsch aussieht - die Standard-Checkboxes sind ja gruselig... roll

Andynium · 03. April 2018 11:09

rage_all schrieb:

sonst bin ich auch nicht bei Strato

Allein das spricht Bände - ist seit Jahren Problemträger Nummer 1.

rage_all schrieb:

Den Tiny abzuschalten um am FormBuilder zu arbeiten wäre nervig genug

Ich sagte nicht, dass Du sollst ja auch nicht den Tiny abschalten sollst, sondern lediglich so konfigurieren, dass er Sonderzeichen nicht mehr in Entitäten konvertiert.

Hast du eine Ahnung, wo das Fragezeichen herkommt?

Oder anders formuliert sieht mir das etwas nach einem BOM aus...

Hast du es schon mit einer frischen Formbuilder-Installation probiert?

Janl · 03. April 2018 12:31

Mit CSS kann man Checkboxes gestalten, sehe folgende Seite

http://freefrontend.com/css-checkboxes/

Vielleicht bringt es Dir auf eine andere Idee

MfG
Jan

rage_all · 03. April 2018 15:42

@Jan: Hey, der Link ist cool! Vielen Dank! So wäre das zumindest mal vom Tisch... smile

@cyberman: Ich hab heute den ganzen Tag alles ausprobiert:

Neue Installation auf neuer Datenbank - komplett frisch
Datenbank-Kollationen und Datenbank-Verbindungseinstellungen rauf- und runter
Das ein Jahr alte Backup mit der Datenbank wie ich sie vom alten Hoster bekommen hab
Das alte Backup auf die neueste Version aktualisiert
Alte FormBuilder-Versionen auf sowohl alter als auch neuer Installation
...

Ich bin fertig.
Für mich ist das jetzt eindeutig eine Strato-Sache.

Ist mir zwar nicht ganz klar, zudem ich noch fünf oder sechs weitere Systeme die bei Strato liegen ebenfalls betreue - aber die sind halt auch (bislang) ohne Probleme.

Witzig hier war für mich beim Durchklicken der Tabellen im phpMyAdmin dass einige Tabellen hier keine Indexes zu haben schienen. Immer wieder kam die Fehlermeldung dass der Inhalt der Tabelle nicht bearbeitet werden kann, weil kein eindeutiger Schlüssel vorhanden wäre. Ich hab hin- und her verglichen mit anderen Installationen, konnte aber visuell keinen Unterschied finden.
Es bleibt mir ein Rätsel.
Aber mit dem Style von Jan und einem statischen Text darüber ist das soweit mal vom Tisch. Jetzt schau ich nur noch dass die Inhalte sauber als Email rausgehen und dann soll der Kunde sich sonstwen suchen... monkey
Quark; betreuen muss ich es weiter - aber das hat mich heute den kompletten Tag gekostet und ja letzte Woche schon zuviel Zeit. Irgendwann ist gut. hmm

Vielen Dank an dieser Stelle für Eure Zeit und Ideen! big_smile
Ehrlich, ich weiß das sehr zu schätzen. angel

Janl · 03. April 2018 16:21

Da fällt mir was ein, kontrolliere mal der Mysql-version und ob der auf kompatibel mit ältere Versionen gesetzt ist.
Details habe ich nicht sofort hier aber ich habe auch mal etwas unerklärliches gehabt das damit gelöst war.

MfG
Jan

Andynium · 03. April 2018 21:27

Ein letzter Gedanke - gib mal dies in phpMyAdmin ein

Hier klicken, um den Code zum Kopieren zu markieren

show variables like 'char%';

Sollte im Ergebnis alles auf utf-8 stehen.

rage_all · 04. April 2018 10:39

Vielen Dank erstmal ... hier was ich dazu habe:

Die Datenbank(en) sind Version 5.6.37 (sowohl die Test-Datenbank mit der frischen Installation, den älteren Modulen, dem original-Backup das beim alten Hoster keine Probleme verursachte, usw.)

Von Kompatibilität steht hier nirgends was. Auf der Startseite vom myAdmin steht folgendes:
Zeichensatz/Kollation der MySQL-Verbindung: utf8mb4_general_ci
(die Datenbank selbst ist laut Tab "Operationen" auf 'utf8_general_ci' eingestellt
...
auf meinen anderen, funktionierenden Installationen ist gewöhnlich die Verbindung auf utf8_unicode_ci und die Datenbanken häufig auf latin1_swedish_ci eingestellt - nur eine war auf den ersten Blick dabei mit utf8_general_ci)
Der Rest von Strato sieht aus wie folgt:

Server: rdbms via TCP/IP
Server-Typ: MySQL
Server Version: 5.6.37-log - Source distribution
Protokoll-Version: 10
Benutzer: XXXX@yyy.zzz.xxx.de
Server Zeichensatz: UTF-8 Unicode (utf8)

Die Abfrage show variables like 'char%'; bringt folgendes Ergebnis:

Nach wie vor: Mein Problem ist - soweit erst mal - gelöst.
Jetzt schau ich noch wie die Emails versandt werden ... sollte da nicht noch ein Querschläger kommen, kann es wegen mir auch schief hängen. Ich hab von Anfang an von Strato abgeraten und der Kunde hat sich das selbst ausgesucht. Ich hab wenig Lust auf Bugfixing was bei einem anderen Hoster bereits funktioniert hatte und vermutlich auch jetzt würde.

...huh, das wäre noch eine Idee - ich spiele das nicht-funktionierende Backup von heute einfach mal bei mir auf die Spielwiese in meinem Rechenzentrum ein und schau mal was passiert... wink

Ich danke Euch derweil für Eure Ideen und melde mich evtl. nachher gleich nochmal zurück.
Schöne Grüße! cool

rage_all · 04. April 2018 11:03

Okay, Backup einspielen ging schneller als gedacht und — es funktioniert tatsächlich!
Unterschiede? Puuh. Also im myAdmin steht auf dem anderen Server:

MySQL-Zeichensatz: UTF-8 Unicode (utf8)
Zeichensatz / Kollation der MySQL-Verbindung: utf8_unicode_ci
Und in der Datenbank selbst
Kollation: utf8_unicode_ci

Dann sag ich das dem Kunden so und gut.
Außer Ihr habt Bedenken da sollte noch eine Kompatibilität entwickelt werden, so dass das CMS auch auf Strato einwandfrei funktionieren sollte. Im Zweifelsfall kann ich den Hoster auch anrufen und fragen ob die eine Idee haben wo der große Unterschied liegen kann...

Zwei Tage Ärger für nichts. Ärgerlich bleibt es.
Da hätte ich auch gleich drauf kommen können. roll

Andynium · 10. April 2018 15:50

rage_all schrieb:

Die Abfrage show variables like 'char%'; bringt folgendes Ergebnis:
http://www.smith-design.de/media/etc/cm … x__two.PNG

Genau so etwas in der Art hatte ich befürchtet - ist ein weiterer Beweis für den Strato Murks mad

Es gibt KEINEN Grund, in einem Standard Hosting Account bei der Datenbank unterschiedliche Zeichensätze einzustellen. Wie gesagt, dort sollte überall utf8 drin stehen. Sobald Latin mit im Spiel ist, gibt's Entitäten.

Also dem Support ordentlich Dampf machen cool

Hier dazu noch mal ein paar passende Artikel

www.schnatterente.net/webdesign/php-mysql-utf8
www.toptal.com/php/a-utf-8-primer-for-php-and-mysql

Beitrag geändert von Andynium (10. April 2018 16:03)

Forum für CMS/made simple

#1 27. März 2018 13:50

Formbuilder kann keine Umlaute?

#2 02. April 2018 09:08

Re: Formbuilder kann keine Umlaute?

#3 03. April 2018 09:08

Re: Formbuilder kann keine Umlaute?

#4 03. April 2018 10:43

Re: Formbuilder kann keine Umlaute?

#5 03. April 2018 11:02

Re: Formbuilder kann keine Umlaute?

#6 03. April 2018 11:09

Re: Formbuilder kann keine Umlaute?

#7 03. April 2018 12:31

Re: Formbuilder kann keine Umlaute?

#8 03. April 2018 15:42

Re: Formbuilder kann keine Umlaute?

#9 03. April 2018 16:21

Re: Formbuilder kann keine Umlaute?

#10 03. April 2018 21:27

Re: Formbuilder kann keine Umlaute?

#11 04. April 2018 10:39

Re: Formbuilder kann keine Umlaute?

#12 04. April 2018 11:03

Re: Formbuilder kann keine Umlaute?

#13 10. April 2018 15:50

Re: Formbuilder kann keine Umlaute?

Fußzeile des Forums