phpwcms Support Forum

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



Woran könnte das nun liegen?

Ursprungsseite: Deine Spielwiese: Die Textblöcke sind nicht betroffen, da dort (vermutlich durch den wysiwyg-Editor) statt z.B. "ü" ein "ü" abgespeichert wurde.

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

Mit JavaScript ist das eh nicht möglich.

Du musst Dich halt darum kümmern und entsprechende Funktionen definieren, siehe: oder über die URL oder eben eine eigene Funktion schreiben, die sich speziell um alles selbst kümmert.

Mehr utf8_encode(), utf8_decode().

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?

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

claus wrote:... phpwcms_output_action ...

miracles: wunderbar geheime killerfunktionen

Oliver Georgi wrote: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.

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.

• 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 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. Dann sähen zugrundeliegende Konfigurationswerte etwa so aus: 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: Mehrere abgefragte Contentbereiche werden getrennt geparst und am Ende zu einem zusammengezogen und zurückgegeben.

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.

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

Oliver Georgi wrote: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)

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

Oliver Georgi wrote: 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.

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

juergen wrote: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.