phpwcms Support Forum

Hallo phpwcms-Gemeinde!

Habe dieses Problem eigentlich schon seit Version 1.2.8. Doch nach Einstellungen, die ich wegen der neuen Version vornehmen musste, hab ich mal mein Wehwehchen wieder herausgekramt. Sämtliche Suchergebnisse hier im Board halfen leider nicht weiter.

Also, folgendes: Die Umlaute in Suchanfragen werden alle mit einem Fragezeichen ersetzt. "?"

In der config.inc habe ich folgendes zu stehen:

Code: Select all

$phpwcms['db_charset']        = 'utf8';
$phpwcms['db_collation']      = 'latin1_german2_ci';

Die Einstellung bei "db_collation" habe ich umstellen müssen nach Update von 1.2.8 nach 1.3.0. So wie hier schon im Forum beschrieben, da sonst alle Umlaute fehlerhaft waren.

Desweiteren

Code: Select all

$phpwcms['charset']           = 'UTF-8';

So, jetzt hab ich das Problem, dass die Zeichensätze alle Bunt gemischt sind, was ja Oli als "Problematisch" bezeichnet. Muss ich da etwa etwas umstellen?

Was mir auch Spanisch vorkommt ist, dass bei
Kollation bei meiner Datenbank "latin1_swedish_ci" steht,
als MySQL-Zeichensatz UTF-8 Unicode (utf8) fettgedruckt ist und
ich bei Zeichensatz / Kollation der MySQL-Verbindung utf-8_general_ci ausgewählt habe.

Was muss ich einstellen um diese scheußlichen Fragezeichen zu entfernen?!

Vielen Dank für eure Hilfe!!

Grüße
MrPotter

Also wie oft denn noch...

Es spielt für die eigentliche Funktionsweise KEINE Rolle, wenn z.B. die Datenbanktabellen mit Collation latin1_swedish_ci angelegt sind. Das ist MySQL und hat erst mal NICHTS mit phpwcms zu tun.

Wenn die Datenbank > 4.0 ist (steht in $phpwcms['db_version'], so wird die Verbindung zur Datenbank auf Basis der Variablen:
$phpwcms['db_charset']
$phpwcms['db_collation']
initialisiert. Ist nun der Charset/Collation von phpwcms und MySQL unterschiedlich, so ist MySQL in der Lage hier eine Charsetkonvertierung durchzuführen.

Es ist aber NICHT ratsam hier unterschiedliche Charsets zu mischen. Das hier ist FALSCH!
$phpwcms['db_charset'] = 'utf8';
$phpwcms['db_collation'] = 'latin1_german2_ci';

Entweder:
$phpwcms['db_charset'] = 'utf8';
$phpwcms['db_collation'] = '';

oder:
$phpwcms['db_charset'] = 'utf8';
$phpwcms['db_collation'] = 'utf8_general_ci';

oder aber (empfohlen solange Latin Sprache):
$phpwcms['db_charset'] = 'latin1';
$phpwcms['db_collation'] = 'latin1_german2_ci';

Oliver

Hallo Oliver,
sorry, sorry, sorry, dass ich dir so viel Probleme bereite, anderen hier im Forum auch, jedoch habe ich selbst mit deiner Lösung noch kein Erfolg gehabt.

Zum einen hat mein MySQL-Server die neuere Version 4.1.11. Und, bevor denkst, dass ich keine anderen Threads gelesen hast - irrst du dich. Ich sitzte schon den ganzen Abend an diesem Problem und habe schon zig Möglichkeiten probiert.

So habe ich deinen Update-Hinweis befolgt/getestet: http://www.phpwcms.de/forum/viewtopic.php?t=13890

Die Datenbank nach defekten umlauten durchsucht, wie hier beschrieben:
http://www.phpwcms.de/forum/viewtopic.p ... c&start=15

Leider hat das Dumper-Tool keine Defekten Zeichensätze gefunden!
Deine Einstellungen (s.o) brachten auch kein Erfolg. Im Gegenteil, sie hatten alles noch schlimmer gemacht. Es ergaben sich nämlich dann Anzeigeprobleme mit der ganzen Seite. Also nicht nur mit der Suchfunktion.

Es tut mich wirklich leid. Aber ich weiß nicht mehr weiter.

Grüße
MrPotter

meine infos sind unabhängig von der MySQL Version.

War denn Dein Charset schon immer auf UTF-8?
$phpwcms['charset'] = 'UTF-8';

Oliver

Ja, war es.

So sah meine Konfiguration vor dem Update nach 1.3.0 aus:

Code: Select all

$phpwcms['db_charset']      = 'utf8';
$phpwcms['db_collation']     = 'utf8_general_ci';

$phpwcms['charset']           = 'UTF-8';  //default charset 'iso-8859-1'

MrPotter

Vielleicht hilft es dir ja wenn ich mal nen Link poste
Klick
Als Suchbegriff benutze mal "Aktivitäten" oder schau dich mal bei Aktuelles um (siehe M?rz)

in der 1.2.8 war ein Bug, bezüglich des Setzens der Collation. So dass letztlich der Query fehlgeschlagen sein dürfte.

Am Besten setze beide Werte test halber mal auf was bewusst falsches, z.B.
$phpwcms['db_charset'] = 'ugaga';
$phpwcms['db_collation'] = 'ugigi';

Dann müsste das beim Initialisieren fehl schlagen und dem Stand der alten Version entsprechen.

Oliver

Hi

sind die 'falsch' angezeigten Zeichen in der Suche zufällig alle in Contentparts WYSIWYG ???
dann liegt das Problem nicht an phpwcms sondern am WYSIWYG-(FCK?) Editor
der wandelt die Umlaute in z.B. ü um und das ist kein UTF !
also wenn dem so ist ändere mal in der fckconfig.js

Code: Select all

FCKConfig.ProcessHTMLEntities	   = true ;

auf

Code: Select all

FCKConfig.ProcessHTMLEntities	   = false ;

die Suche dürfte mit den HTML Entities kein Problem haben.

Oliver

dürfte - sollte - könnte - müsste

was hilfts wenn nicht geht

ist nur meine Erfahrung die ich gerade mit der 1.3.0 in einer Testinstallation gesammelt habe ( Neuinstallation - XAMPP PHP 5.1.2 mySQL 5.0.18 - Lokal - alles UTF )
aber vielleicht mach ich ja auch was flasch

@Pico - beispiel, link, screenshot?

@Oliver - Mail geschickt

Wow, echt super, dass ihr mich alle so fleißig unterstützt. Großes Lob an Euch!!

Nun zur Auswertung euer Tipps. Also Oli, der Tipp mit den falschen Werten hab ich getestet. Es hat sich jedoch nichts geändert. Alles so wie vorher mit den gemischten Werten. Aber du hattest recht, es war der Stand, wie bei v. 1.2.8. Denn dort hatte ich ja wie schon erwähnt das gleiche Problem.

Was jetzt - zumindest bei den Suchergebnisse half war - alle Artikel mit Umlauten zu öffnen und neu zu speichern. Nur dann werden keine ? mehr angezeigt!
Diesen Tipp hat mir jojostg per PN geschickt. Dabei spielte es jedoch keine Rolle was für einen Editor man benutzte.

Neue Artikel, die ich anlegte enthielten ebenfalls keine Fragezeichen.

@pico: Bei mir stand der Wert auf true, habe jedoch im Quelltext ganz normale Umlaute zu stehen. Habs trotzdem mal umgestellt. Wer weiß was es bringt . . .

Damit wäre mein Problem fast schon gelöst. Es gibt aber leider immer noch Zeichenfehler beim Artikellisting. Ich verwende für die Datumsanzeige in der .tmpl - Datei dieses Replacementtag:

Code: Select all

{DATE:d. M:DE}

Angezeigt wird bei mir z.B 10. M?rz.
Das ist nicht schön.

Grüße
MrPotter

schau dir mal die ../include/inc_land/date/de.date.lang.php
an

Hmm. Ich bin ja auch gerade dabei das update zu machen, und habe mir gerade mal die lang.inc.php angesehen. Da sieht man dann folgendes:

// profile.updateaccount.inc.php
$BL['be_profile_account_err1'] = 'Benutzername {VAL} ist ungültig';
$BL['be_profile_account_err2'] = 'Kennwort zu kurz (nur {VAL} Buchstaben: mind. 5 nötig)';
$BL['be_profile_account_err3'] = 'Kennwortwiederholung stimmt nicht mit Kennwort überein';
$BL['be_profile_account_err4'] = 'E-Mail {VAL} ist ungültig';

Dann können die Umlaute ja nicht richtig angezeigt werden, oder? Das ist im übrigen nur ein Beispiel. Wenn ich es richtig überblicke sind alle Umlaute falsch, also nicht vorhanden.

pico wrote:schau dir mal die ../include/inc_land/date/de.date.lang.php
an

hab ich. Da stand

Code: Select all

$month_long[ 3]	= "März";	$month_short[ 3]		= "März";

Hab ich mal geändert in

Code: Select all

$month_long[ 3]	= "M&auml;rz";	$month_short[ 3]		= "M&auml;rz";

Und siehe da, es funktioniert!! Aber warum musste ich das anpassen?

@Nomax2000
Das ist schon richtig so. Dein Browser interpretiert diese Zeichen als Umlaute. So ist zum Beispiel die Kombination ä ein ä.

Aber warum die eine Datei so aufgebaut ist und in der de.date.lang.php die Umlaute direkt stehen, versteh ich selber nicht.

Viele liebe Grüße und Merci für die Unterstützung!
MrPotter

phpwcms Support Forum

Wieder Umlautproblem 1.3.0

Wieder Umlautproblem 1.3.0