Import-Umlautproblem bei <h1/2/3> u. Bildbezeichner

[kukki]

Beim Import bemerke ich ein Umlaufproblem, dass mit erst heute aufgefallen ist:



Woran könnte das nun liegen?

[top]

Ursprungsseite:

Code: Select all

  <meta http-equiv="content-type" content="text/html; charset=iso-8859-1" />

Deine Spielwiese:

Code: Select all

  <meta charset="utf-8" />

Die Textblöcke sind nicht betroffen, da dort (vermutlich durch den wysiwyg-Editor) statt z.B. "ü" ein "&uuml;" abgespeichert wurde.

[kukki]

Stimmt, der Editor wandelt selbständig diese Sonderzeichen um
Wie kann man nun ohne gleich eine Textmanipultion per jQuery/ PHP einzusetzen, das Problem in Griff kriegen. Immerhin haben wir zu früheren Zeiten noch keine UTF-8 -Codierung benutzt, sondern halt eben ISO-8859-1. Und deswegen die Datenbank umrubel (ob das überhaupt geht) ?

[Oliver Georgi]

Mit JavaScript ist das eh nicht möglich.

Du musst Dich halt darum kümmern und entsprechende Funktionen definieren, siehe:

Code: Select all

$phpwcms['output_function_filter'] = array('trim', 'utf8_encode');

oder über die URL

Code: Select all

Nach UTF-8 phpwcms_output_action=F-utf8_encode--S-EVENTS
Von UTF-8 phpwcms_output_action=F-utf8_decode--S-EVENTS

oder eben eine eigene Funktion schreiben, die sich speziell um alles selbst kümmert.

Mehr utf8_encode(), utf8_decode().

[update]

Dieses phpwcms_output_action scheint ja etliche weitere Möglichkeiten zu beherbergen, die so noch gar nicht klar sind, oder? Es gibt nicht zufällig eine (kleine) Liste der Möglichkeiten?

[Oliver Georgi]

Das habe ich alles schon mal beschrieben. Rest ist schlicht von Eurer Kreativität und Bedarf abhängig.

[Jensensen]

... phpwcms_output_action ...

miracles: wunderbar geheime killerfunktionen

Das habe ich alles schon mal beschrieben. ...

das hat eine housefrau, wie ich, in 2009 schon nicht mehr begriffen und fünf jahre später leider immer noch nicht.

[Oliver Georgi]

OK, gebe zu, komplexes Thema — richtet sich aber wirklich vor allem an Entwickler. Das Grundprinzip ist aber simpel.

Über den Parameter phpwcms_output_action werden die Anweisungen an phpwcms übermittelt.

Code: Select all

phpwcms_output_action=F-function1|function2|…--S-section1|section|…

• F: eine oder mehrere PHP Funktionen, die einen ermittelten Contentbereich parsen
• S: einer oder mehrere Contentbereiche <!--SECTION_NAME_START//--> <tag>Seiteninhalt</tag> <!--SECTION_NAME_END//-->

Um nicht jede beliebige Funktion benutzen zu können (Sicherheit), kann über F nur auf Funktionen zurückgegriffen werden, die in

Code: Select all

$phpwcms['output_function_filter'] = array();

definiert worden sind.

Diese werden dann beim Ausführen auf den jeweiligen ermittelten Contentbereich angewendet. Jede auf den Contentbereich auszuführende Funktion muss über phpwcms_output_action festgelegt werden. Die Definition dieser Konfigurationsparamter erfolgt am besten in frontend_init. Eine eigene Filterfunktion wäre z.B.

Code: Select all

function custom_section_filter($text='') {
    $text = str_replace('Find mich', 'Ersetz mich', $text);
    return $text;
}

Dann sähen zugrundeliegende Konfigurationswerte etwa so aus:

Code: Select all

//Zulässige Funktionen über phpwcms_output_action
$phpwcms['output_function_filter'] = array('custom_section_filter', 'trim', 'utf8_encode', 'utf8_decode');

Standardfunktionen, werden dann gemischt mit Werten aus phpwcms_output_action und in der Reihenfolge wie definiert abgearbeitet. Achtung!!! Es wird nur die Schnittmenge benutzt, siehe.

So könnte dann ein Aufruf aussehen:

Code: Select all

phpwcms_output_action=F-trim|utf8_encode|custom_section_filter--S-BEREICH1

Mehrere abgefragte Contentbereiche werden getrennt geparst und am Ende zu einem zusammengezogen und zurückgegeben.

[RalfB]

Müssen alle 47 Tabellen in der Datenbank von latin1_general_ci auf utf8_general_ci in der Kollation umgestellt werden?
Ich habe das vorhin mal zu Probe mit Allen gemacht.
Habe aber Panik bekommen und alles zurückgestellt, weil plötzlich in den Vorlagen alle Eintragungen in HTML Kopf, Kopfzeile Haupt.... weg waren. Alles Leer. Sah zumindest so aus.
Auch die Angaben in im css . Sah aus als ob alles weg war.

[Oliver Georgi]

NIEMALS nachträglich die Collation der Datenbanktabellen umstellen! Serialisierte Arrays, die Non-Ascii-Zeichen enthalten, gehen flöten.

[RalfB]

NIEMALS nachträglich die Collation der Datenbanktabellen umstellen! Serialisierte Arrays, die Non-Ascii-Zeichen enthalten gehen flöten.

Also ich habe es noch einmal geprüft.
Den Effekt: "plötzlich in den Vorlagen alle Eintragungen in HTML Kopf, Kopfzeile Haupt.... weg waren. Alles Leer. Sah zumindest so aus."
habe ich schon, wenn ich die Umstellung von "$phpwcms['charset'] = 'iso-8859-1';" auf "$phpwcms['charset'] = 'utf-8';" in der conf.inc.php mache.
(und im Hinweistext schreibst du ja man solle keine Andere Einstellung wählen. // default charset 'utf-8' do not use soemthing different any longer)

[Oliver Georgi]

Aber NICHT hinterher!!! Einmal festgelegt, ist es nur sehr schwer, dass wieder zu ändern oder man weiß genau, was man dort macht.

$phpwcms['charset'] und $phpwcms['db_charset']/$phpwcms['db_collation'] hängen unmittelbar zusammen und voneinander ab.

Das hat, wie gesagt, vor allem mit serialisierten Arrays zu tun, die an vielen Stellen im System benutzt werden. Würde ich heute so nicht mehr machen.
http://stackoverflow.com/questions/2853 ... er-2853670

[nameless1]

Das hat, wie gesagt, vor allem mit serialisierten Arrays zu tun, die an vielen Stellen im System benutzt werden. Würde ich heute so nicht mehr machen.

tritt nach meiner erfahrung vor allem bei image_special, formular und shop auf. in der theorie ist es möglich jede spalte mit einer routine abzufragen und mit neuer charset zu speichern. war uns aber jedes mal viel zu aufwendig. schneller und sauberer ging manuell neuanlage.

[juergen]

naja, wenn, wie in dem Beispiel die richtige Länge des Strings als falsch deklariert wird, gibts ja wirklich keine verlässliche Methode das zu ändern. Bevor ich das gelesen habe hätte ich behauptet, dass ein CSV Export das repariert. Aber wenn die Kollation wechselt ist das dann selbst da im Eimer.

Erinnert mich an base64 Kodierte EMail Parts, genauso ein Wischi Waschi ....

[nameless1]

naja, wenn, wie in dem Beispiel die richtige Länge des Strings als falsch deklariert wird, gibts ja wirklich keine verlässliche Methode das zu ändern.

türlich gibt es den - in der theorie. holst es in der richtigen Kollation ab, wandelst es in die neue um und speicherst es zurück.