Upgrade from 2.8.3 SP7 to 2.10 Umlaute

Luisehahne

Quote from: jacobi22 on October 25, 2017, 01:15:04 PM
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
Note: Once the code has been generated, it is easy to debug. It's not a bug, it's a feature!

Gast

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

arothe

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

Gast

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

Luisehahne

Danke für den Hinweis,

DEFAULT_CHARSET bekommt als default utf-8, was einige Probleme beheben sollte.

Dietmar
Note: Once the code has been generated, it is easy to debug. It's not a bug, it's a feature!

Gast

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

Gast

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 ersetzen. Ich schau derweil mal, an welcher Stelle das Charset da eingefügt wird

Gast

Quotewenn 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)

arothe

#19
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'

Gast

QuoteAllerdings 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

arothe

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

Craxx

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
Craxx;)

Gast

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). 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

Craxx

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???
Craxx;)

Hollol

Ich bin bei all-inkl und habe die Datenbanken in den Standardeinstellungen 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.

Gast

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

Hollol

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.

Gast

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

tsaenger

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

dbs

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.
[url="https://onkel-franky.de"]https://onkel-franky.de[/url]

Gast

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


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

QuoteDEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci

dann noch eine Einstellung, zu sehen in PHPmyAdmin-> Server->Datenbanken

dbs

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.
[url="https://onkel-franky.de"]https://onkel-franky.de[/url]

Gast


hillschmidt

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!)

Gast

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