WebsiteBaker Community Forum
WebsiteBaker Support (2.10.x) => General Help & Support => 
Hilfe & Support (deutsch) => Topic started by: tsaenger on March 06, 2017, 01:13:23 PM
-
Hello,
i upgraded my version from 2.8.3 SP7 to 2.10 and i got a problem with the german Language:
Frontend and Backend does not German display "Umlaute" ä ö ü. ( http://mws-mainz.srv.sit-mainz.info/WB/ )
What can i do to repair this?
thanks a lot
Tobias
-
1.
Steht deine DB noch auf "latin1" oder schon auf "utf8_unicode_ci"?
2.
Ist im BE unter "erweitere Option" utf8" eingestellt?
-
sieht von außen nach reinem Mix der Zeichensätze aus - als Schnellreparatur würde ich die Sachen in den Textfeldern manuell korrigieren
Langfristig empfiehlt es sich, die Datenbank mal "aufzuräumen" (SQL-Backup machen, durch einen Konverter laufen lassen und wieder einspielen, dann ist für die Zukunft erstmal Ruhe)
manuelle Korrekturen in
- Seiteneinstellungen bei Menü, Seitentitel, Beschreibung, Keywords
- WB-Optionen - Webseitentitel und -beschreibung
andere Module wie Gästebuch, Form, News - wenn in den Optionen andere als die original-Texte verwendet wurden
-
Das Problem hatte ich heute auch nach dem 2.10 Update meiner ersten Site - auf die Schnelle alle Seiten korrigiert ... (hilfreich war auch das SEO Modul für Description & Keywords!)
-
hilfreich war auch das SEO Modul für Description & Keywords!
http://addon.WebsiteBaker.org/pages/en/browse-add-ons.php?id=0E7618D1
-
Hatte auch das Problem. Ein paar händische Korrekturen reichten aber zum Glück.
Geht wohl vielen so, die ihre Seite durch etliche Upgrades geschleppt haben. Obwohl DEFAULT_CHARSET uft8 schon vorher in der config stand.
-
das Problem ist eigentlich in der SQL-Datei vom Backup zu sehen, am Ende jeder Tabelle steht in aller Regel das Charset der Tabelle und die sog Table-Collation
etwa so
(https://i.gyazo.com/fd97586b835e91e555d7f85c446da915.png)
mit Einträgen wie diesen hier (nur ein Bruchteil der möglichen Varianten, aber die meist gebräuchlichen im deutschen Sprachraum)
CHARACTER SET latin1,
COLLATE latin1_german2_ci,
COLLATE latin1_general_ci',
DEFAULT CHARSET=latin1 COLLATE=latin1_german2_ci,
DEFAULT CHARACTER SET latin1 COLLATE latin1_swedish_ci,
DEFAULT CHARSET=latin1,
und diese Einträge müssen dann ersetzt werden durch
DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci
dann noch eine Einstellung, zu sehen in PHPmyAdmin-> Server->Datenbanken
(https://i.gyazo.com/45e7089653b94ff0937c182722bfa3da.png)
-
Für meine Seite kann ich sagen, dass alles vorher schon auf utf8 stand.
In einer sp7 sql nochmal nachgeschaut. Alle module haben DEFAULT CHARSET=utf8, manche auch collate=utf8_general_ci.
In der Übersicht zeigen alle collation utf8_general_ci.
Deshalb war ich etwas verwundert nach Upgrade ein paar Menüeinträge falsch zu sehen. Waren 2 Zeichen, glaube die UTF8-Schreibweise.
Aber eigentlich egal. Irgendwann hat man die Altlasten ersetzt.
-
Hallo zusammen,
ja, die Tabellen standen auf "latin1_swedish_ci"
Ich habe Sie nun auf utf8 gealtert
ALTER TABLE my_table CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;
Wie bekomme ich denn nun die Umlaute geändert?
Das sind ziemlich viele. Per Hand ist das sehr mühsam.
Vielen Dank.
Gruß
Tobias
-
Hab dir eine PN mit Tool und Erklärung gesandt per PN. Bitte so mal durchführen, idealerweise auf einer Testdomain. im schlimmsten Fall die alte DB wieder einspielen
Viel Erfolg
-
Selbiges Problemchen hier auch wieder.
Upgrade von 2.8.3 +SP7 auf 2.10.
Datenbank und alle Tabellen auf UTF8.
Die WYSIWYG-Einträge werden korrekt dargestellt. (Y)
Gästebucheinträge auf einmal sind voll mit Sonderzeichen. (N)
Ebenso die Titel und Menünamen. (N)
Gästebuch ist die neueste Version. Da ist aufgrund der vielen Einträge nichts mit mal schnell manuell ändern.
Hier hilft wieder nur -> Datenbank runterladen, Sonderzeichen durch Suchen&Ersetzen anpassen, Datenbank wieder hochladen.
-
Werden beim Module-Install keine Charsets und Table-Collations mitgegeben, werden die Einstellungen der Server-Datenbank verwendet. Standardeinstellung bei Strato und 1&1 in den letzten Jahren bei latin1
P.S.: das hat nichts damit zu tun, welcher Zeichensatz in WB oder auch PHP eingestellt wurde
Bekommst auch gleich ne PN
-
Ich bin bei all-inkl und habe die Datenbanken in den Standardeinstellung en auf UTF8 eingestellt.
Scheint allerdings wirklich nur ältere Datenbanken (Tabellen) zu betreffen, die schon Upgrades hinter sich haben.
Beholfen habe ich mir jetzt damit, dass ich vor dem Upgrade auf WB 2.10 die Datenbank herunterlade und durch Suchen&Ersetzen im Notepad++ "alles" von "latin1" in "utf8" umändere - dann die Datenbank auf dem Server löschen und neu importieren.
Damit entfällt hinterher die Suche nach einzelnen Sonderzeichen.
-
Hallo Zusammen,
ich habe nach dem Update von SP7 auf 10 folgendes Problem, siehe angehängte Datei.
Was kann ich tun?
Danke
Craxx
PS: wie kann ich hier Bilder direkt hochladen???
-
Problem 1: direkter Bilderupload
ein direkter Bildupload ist im Forum nicht mehr möglich. Du benötigst eine öffentlich zugängliche Quelle, einen Image-Hoster (ich selbst nutze Gyazo in der Free-Version (https://gyazo.com/download?lang=de)). Die von dir eben verwendete Variante, das Bild in ein ZIP einzupacken, ist aber auch völlig in Ordnung
Problem 2 : Design im Backend
Hier ist wahrscheinlich die alte Version des Backend-Themes noch im Browser-Cache, STRG + F5, STRG + R wären mögliche Tastenkombinationen . Auch ein erneutes Ausführen des Upgrade-Scriptes über das InfoFenster könnte das Problem beseitigen
Problem 3: Umlautproblem nach Umstellung auf UTF8
sofern es nur die Seiten- und Menütitel betrifft, würde ich das in den jeweiligen Seiteneinstellungen manuell beheben. Kontrolliere dabei auch eventuelle Einträge in den Textfeldern der WB-Optionen wie Website-Header, WebsiteFooter usw
-
D A N K E super schnell geholfen.
STRG+F5 hilft Wunder.
Die Tabellen habe ich auf UTF8 umgestellt und die letzten Mängel noch manuell geändert.
Vielen Dank!!!
Craxx
-
Hallo zusammen,
ich habe das gleiche Problem beim Update auf 2.10 gehabt und mich deshalb gefreut diesen Forum Eintrag gefunden zu haben.
Alle Vorschläge hier habe ich sehr aufmerksam gelesen und auch umgesetzt. Meine Datenbank ist jetzt vollständig auf utf8_general_ci geändert.
Allerdings bleibt immer noch ein dickes Problem. Der Inhalt einer versendeten Mail aus dem integrierten Formmailer und/oder auch aus mpform enthält statt der Umlaute nur Fragezeichen. Mein Webserver läuft mit PHP 7.0, aber selbst wenn ich auf PHP 5.6 zurück schalte habe ich auch das Problem - also kann es daran nicht liegen. Es macht auch keinen Unterschied ob ich mit PHP oder SMTP die Mail versende. In der WebsiteBaker Version 2.8.3 SP7 war alles OK!
Es muß also mit dem Update auf 2.10 zusammenhängen. Ich vermute einen Bug in einer im Update neu enthaltenen Datei. Allerdings reichen meine Kenntnisse nicht aus, den Fehler zu finden.
Hat jemand von Euch eine Idee, woran es liegen könnte, bzw. wo ich suchen könnte. Bin für jede Hilfe dankbar !!!
PS: Auf meinem Server läuft auch zusätzlich noch ownCloud und Rainloop Webmail, beide Programme versenden unter PHP 7.0 Mails ohne das Umlaute Problem. Deshalb kann ich meinem Webhoster STRATO leider keinen Vorwurf machen.
Vorab vielen Dank für jede angebotene Hilfe.
arothe
-
Allerdings bleibt immer noch ein dickes Problem. Der Inhalt einer versendeten Mail aus dem integrierten Formmailer und/oder auch aus mpform enthält statt der Umlaute nur Fragezeichen
mach es bitte mal etwas genauer. Geht es um Daten, die der Besucher eingegeben hat oder um Daten, die bereits im Formular enthalten sind, wie z.b. Feldtitel oder Texte, die z.b. als Standard-Info mitgeschickt werden? Falls Letzteres, müßte das direkt im jeweiligem Modul korrigiert werden. Falls doch Besucher-Eingaben, bitte mal
1. in einem anderen Mailprogramm betrachten, z.b. Webmail
2. in den Quelltext der Mail schauen, da stehen Angaben wie z.b.
Subject: Elternstammtisch
Message-ID: <46060ffb-4af3-2a34-e54c-1e6646a2ef92@online.de>
Date: Tue, 26 Sep 2017 21:19:43 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
Thunderbird/45.8.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
P.S.: verschiedene Mailanbieter haben Probleme mit UTF8, bekannt ist da z.b. GMX
P.S.: könnte ich da mal eine solche Mail haben oder solch Formular mal testen? Adresse gern auch als PN
-
Vielen Dank zunächst für die Hilfe. Im Anhang habe ich zwei Screenshots beigefügt. Einmal die Return Seite der Homepage und dann die übermittelte Mail. Man erkennt, dass Umlaute im Betreff gar nicht angezeigt werden und im Mailtext als Fragezeichen erscheinen. Der Fehler ist vollkommen unabhängig vom verwendeten Mail Programm, er tritt auf dem Smartphone, dem Desktop PC und auch im Webmailer auf. Habe ich alles schon für eine Fehlersuche gecheckt gehabt. Ich kann Dir auch gerne den Link zu meiner extra für diesen Zweck eingerichteten Testseite schicken, wenn Du mir bitte kurz erklärst, wie ich über dieses Forum eine PN versenden kann. Ich würde Dir dann gerne auch die Original Mail zur Analyse schicken.
PS: Es gibt auch noch einen Tippfehler in der Betreffzeile, dass Wort 'Formular' steht dort als 'Forumlar'
-
wenn Du mir bitte kurz erklärst, wie ich über dieses Forum eine PN versenden kann
am einfachsten über einen der im Bild hier rechten Icons, die jeweils am Linken Rand eines Beitrages unter dem Avatarbild sind
oder über den Menüpunkt "Meine Mitteilungen" im Usermenü oberhalb der Beiträge.
Könntest du auch noch Angaben über die PHP- und MySQL-Version machen, die bei dir läuft. Diese Angaben findest du im Info-Fenster deines WB-Backends (i-Button)
-
von den Bildern her schaut es mir eher nach einer falschen Kodierung in der Mail aus
Lt Mailquelltext wird kein Charset mitgeliefert, von daher weiß das Mailprogramm nicht, "in welcher Sprache" das dargestellt werden soll. Aus dem Formmodul kommt der Text aber korrekt raus
Bitte einfach mal zur Sicherheit den Ordner include/phpmailer mit gleichnamigem Ordner aus einen frischen Download (http://addon.WebsiteBaker.org/pages/en/browse-add-ons.php?download=0EC5EAC3) ersetzen. Ich schau derweil mal, an welcher Stelle das Charset da eingefügt wird
-
definiert wird der Wert in der Datei framework/class.wbmailer.php // Zeilen an 130 in diesem Code
// set default charset
if(defined('DEFAULT_CHARSET')) {
$this->set('CharSet', DEFAULT_CHARSET);
} else {
$this->set('CharSet', 'utf-8');
}
Das Ganze wird dann an den PHPMailer gesendet und nicht vorhandene Werte ersetzt bzw anders herum - alle überlieferten Werte ersetzen die Standardwerte des PHPMailers. Meiner Meinung nach ist es technisch möglich, das die Konstante DEFAULT_CHARSET wohl definiert wurde, also TRUE ist, aber keinen Wert hat. Das könnte der Fall nach einem Upgrade sein, wenn der Wert in der Datenbank ggf geändert wurde
Variante 1: im Info-Fenster (i-Button) das Upgrade-Script noch einmal starten, danach erneut testen
Variante 2: in der Datei framework/class.wbmailer.php im oben gezeigten Code mal diese Zeile hier abändern auf
original
$this->set('CharSet', DEFAULT_CHARSET);
testweise
$this->set('CharSet', 'utf-8');
damit möchte ich umgehen, das die Konstante leer ist
-
Danke für den Hinweis,
DEFAULT_CHARSET bekommt als default utf-8, was einige Probleme beheben sollte.
Dietmar
-
war nicht als Hinweis gedacht, aktuell nur ein Vorschlag für den User zur Identifikation des Problems.
Leider habe ich momentan keine weiteren Kenntnisse, charset:utf8 steht in den Metatags, könnte da aber auch fest eingetragen sein. In den Mails fehlt diese Angabe. Die Vermutung ging dahin, das das Charset in der DB nicht umgeschrieben wurde. Sollte DEFAULT_CHARSET zur Verfügung stehen, ist das wo möglich ein anderes Problem.
Per Mail haben wir uns darauf verständigt, das das WB-Paket noch einmal mit anderer Methode als Filezilla übertragen wird, sowie der User die Zeit dafür findet. Dann sehen wir mehr
-
Problem konnte Dank des hervorragenden Supports behoben werden. Es war tatsächlich der nach dem Update auf 2.10 fehlende default_charset: utf-8 Eintrag in der WB Settings Tabelle.
Nochmals an dieser Stelle vielen Dank für die schnelle und unkomplizierte Hilfe.
Gruß Andreas
-
So, noch einmal nachgefragt
offensichtlich wurde der unter WB 2.8.3 vorhandene Eintrag in der settings-Tabelle
`wb_settings` (`name`,`value`) VALUES ('default_charset','utf-8');
mit einem leeren Wert überschrieben. Und das nicht als Einzelfall, sondern schon mehrfach bei verschiedenen Upgrades. Dieses Verhalten wurde schon auch hin und wieder bei den damaligen Test's beobachtet, ließe sich dann aber nicht mehr nachvollziehen
-
So, noch einmal nachgefragt
offensichtlich wurde der unter WB 2.8.3 vorhandene Eintrag in der settings-Tabelle
`wb_settings` (`name`,`value`) VALUES ('default_charset','utf-8');
mit einem leeren Wert überschrieben.
Wie bereits erwähnt haben wir dies für die nächste Version gefixt.
Dietmar