CONTENIDO Forum

So, habe das Problem endlich gefunden und möchte hiermit den BUG melden.

Symptom:
In 4.9.2 geht man auf ein Layout, oder auf ein Modul, und , die Textfelder sind leer.
Ein kurzer Blick in die DB zeigt aber, dass die Daten sehr wohl vorhanden sind.

Mysterium
Warum also werden die Daten von der DB nicht im Textfeld ausgegeben?

Ursache
Die Ursache liegt in der Codierung. Speichere ich die Daten in der DB in UTF-8 ab (so wie es ja mittlerweile "State of the Art" sein sollte ), zerschießt dass die Ausgabe vom Contenido-Backend - soll heißen, die Felder werden nicht ausgegeben.
Dies geschieht dann, wenn man Sonderzeichen in seinem Quellcode nutzt, wie das im DE-Sprachraum oft äöü usw. sind. (Übrigens, da ich die DB auf UTF-8 umgestellt habe, führt das normale Speichern im Contenido-Backend zu diesem Fehler. Gebe also ein Ü in Modul-Input oder Output ein, und wundere dich nicht, wenn nach dem speichern alle Felder wieder leer sind)

Speichert man die Daten in der DB als ISO ab (hab ich über ein DB-Tool gemacht), werden Sie wieder in den Textfeldern ausgegeben.

Fazit
Contenido ist NICHT UTF-8 save.

Große bitte an 4fb, bitte schnellstmöglich fixen. Ohne UTF-8 wird Contenido wohl nie für Fremdsprachige Websites (vor allem Kyrillischer Sprachraum) interessant. Und auch große Firmen in DE haben ausländische Niederlassungen in Russland, China, etc.

TODO
Künftige Contenido-Versionen ausschließlich mit Folgender DB-Einstellung ausliefern und weiterentwickeln:

Collation utf8_general_ci

Hallo rethus,

wollte das nachprüfen, da es mich interessiert hat und ich dieses von dir beschriebene Verhalten nicht kenne.

Habe soeben eine frische Installation mit 4.9.3 durchgeführt, während der Installation als Zeichensatz der DB-Verbindung UTF-8 gewählt, danach jeweils 1 Layout und ein Modul mit Umlauten angelegt.

Im Folgenden alle wichtigen Screenshots, da wurde nichts manipuliert oder angepasst:

Default-Zeichensatz in PHP (Ab Version 5.4 ist es per default immer UTF-8)



Collation der Tabellen in der Datenbank



Encoding der CONTENIDO Datenbankverbindung



Encoding der PHP-Einstellungen in CONTENIDO



Das Encoding der Sprache Deutsch im CONTENIDO Backend



Layout mit Umlauten

(Siehe auch Content-Type in der Response Header)


Modul mit Umlauten

(Siehe auch Content-Type in der Response Header)


Startseite im Frontend

(Siehe auch Content-Type in der Response Header)


Wie man sieht funktioniert CONTENIDO wunderbar mit UTF-8, es gibt nirgendwo Probleme, alle Bereiche (PHP, DB-Verbindung, Collation der Tabellen, Ausgabe der Seiten im Backend und im Frontend) laufen unter UTF-8.

Daher vermute ich, dass bei dir irgendwo das Encoding nicht stimmt. Eventuell ist es vielleicht PHP, da PHP vor 5.4 noch mit dem default-Zeichensatz ISO-8859 lief...

Gruß
xmurrix

Ok, danke für deinen ausführlichen Test.
Da gab es noch Stellen, die ich nicht bedacht habe.

Folgendes war bei mir noch nicht gesetzt (vielleicht hilft es jemand weiter, der mit den gleichen Symptomen kämpft):
Sprache war im BE noch auf ISO-8859-1 gestellt.

Nachdem ich es auf UTF-8 eingestellt habe, ging es. Problem saß also zwischen Rückenlehne und Monitor.

Ich glaube, ich habe das gleiche Problem aber mit einer 4.8.15 Installation. Scheint also nicht direkt mit der Version zusammen zu hängen.
Manche Module und Modul-Templates erscheinen nicht, obwohl sie in der Datenbank und im Dateisystem vorhanden sind.
Die Kodierung der Codes scheint mir ISO-8859-2 zu sein und in Sprache ist aber ISO 8859-1 eingetragen.
Das werde ich bald herausfinden, ob es daran liegt.

Habt Ihr inzwischen schon neue Erkenntnisse? Mich würde Euer Ergebnis auch sehr interessieren!

Ich muss das etwas erklären, weil ich noch nicht ganz genau weiß, was da alles falsch gemacht worden ist.

Also in meinen immer noch aktuellen Fall war es so, dass ich in der Datenbank alle Module vorfand (es ist noch eine 4.8.x Version), auch die, die nicht angezeigt wurden.
So war es kein Problem, direkt mit einem Client (z.B. HeidiSQL) in die DB zu gehen und dort den Code zu bearbeiten.
Ich musste dann doch ein neues Modul einbauen, weil das bisherige nicht kompatible zur Übersetzung war.
Da hatte jemand die hauseigenen Contenido-Methoden für Mehrsprachigkeit mit einer Eigenkonstruktion umschifft, i18n war zum Beispiel raus und Ausgabetext direkt im Code.
Nur war das neue Modul in dem Moment nicht mehr zu sehen, nachdem ich es abgespeichert hatte!

In der Datenbank war es aber noch da.
Ich hatte dann nochmal auf speichern geklickt und weg war das Modul auch aus der Datenbank.
Irgendwie logisch, weil wenn nichts im Codefenster ist, wird der DB-Inhalt mit "nichts" ersetzt.

Die Seite war wohl nur für Deutsch erstellt worden und folglich findet sich 8859-1 in der Spracheinstellung.
In diesem Fall jetzt sehe ich aber bei den Modul-Templates, dass sie ins ANSI gespeichert ist.
ANSI ist aber nicht identisch mit ISO 8859-1.
http://www.alanwood.net/demos/charsetdiffs.html

Eigentlich sollte ich jetzt alles auf utf-8 umstellen, da ich wegen Fremdsprachen innerhalb der deutschen Spracheinstellung diese Sprachzeichen benötige.
Aber dann finde ich in Modulen sowas hier: Ich weiß nicht, was mein Vorgänger alles gemacht hat und mich beschleicht das Gefühl, sobald ich auf UTF-8 umstellen, geht nichts mehr und mich erwartet viel Arbeit, da die ganze Webseite mit solchen Modul-Eigenkonstruktionen aufgebaut ist.
Das gibt der winzige Auftrag aber nicht her, ich sollte eigentlich nur mal schnell vor Weihnachten ... ihr wisst schon

Mich beschleicht der leise Verdacht, dass hier einmal auf utf-8 umgestellt wurde und dann wieder zurück auf iso 8859-1, oder etwas ähnliches.
Was würde schlimmstenfalls passieren, wenn ich auf utf-8 umstelle?
Da es ein Live-Projekt ist, kann ich nicht daran herum experimentieren, die Seite läuft 24/7.

Inzwischen habe ich darum ein Contenido-Standardmodul umgebaut, so dass der fremdsprachliche Text mit Code-Nummern dargestellt wird: @ = @
Das funktioniert in kleinem Rahmen und war Quick n' Dirty.

Die Module werden aber immer noch nicht im Backend angezeigt.
Liegt es daran, dass in der Sprache ISO 8859-1 eingestellt ist, aber die Dateien ANSI sind?
Ich vermute mal, die Zeichen aus ANSI werden irgendwo gebraucht.
Daher kann ich das nicht durch ISO 8859-1 ersetzen.
Und ich vermute einfach mal, dass irgendwo im Contenido Code die Diskrepanz von ANSI und ISO 8859-1 zu dem Effekt führt, dass nichts angezeigt wird.
Bestehende Standard-Module von Contenido kann ich sehen, aber sobald ich da was ändere und nach dem Abspeichern ist nichts sichtbar, obwohl es in der DB ist.
Folglich ändert sich etwas beim Speichern.

Ich sage mal vorsichtig so:
Wenn du den Mandant auf UTF-8 umstellst, und nichts speicherst (also nur mal zum schauen), dürfte da nichts passieren.

Fakt ist aber : NIEMALS, wirklich NIEMALS an einem LIVE-System basteln.
Contenido ist ja sehr einfach und schnell auch lokal aufgesetzt (auch als kopierte Instanz). Tue dir einen Gefallen und tüftel lokal daran rum. Wenn du dann einen Workarround hast, übertrag es ins Live (BACKUP vorher nicht vergessen!)

rethus hat geschrieben:Ich sage mal vorsichtig so:
Wenn du den Mandant auf UTF-8 umstellst, und nichts speicherst (also nur mal zum schauen), dürfte da nichts passieren.

Na doch, sämtliche Dateien werden in UTF-8 Format umgewandelt!
Daten, die danach in Formularen eingegeben werden, landen dann als UTF-8 in der Datenbank zusammen mit Daten, die nicht UTF-8 sind oder waren.
Gemischte Daten sind der Supergau, das kriegst du nachher kaum noch auseinander.
Das geht vor allem nicht mehr so einfach rückgängig zu machen.
Es ist viel einfacher, ein System neu als utf-8 aufzubauen als ein bestehendes von ISO auf utf-8 umzustellen.

Fakt ist aber : NIEMALS, wirklich NIEMALS an einem LIVE-System basteln.

Ich bastel ja auch nicht am Livesystem, ich weiß meistens genau was ich tue und wenn nicht, mache ich es nicht (siehe Artikel davor).
Aber entwickelt habe ich schon oft am Live-System, weil manchmal oder oft oder generell geht es nicht anders.
Ich habe ja nicht nur mit Contenido zu tun sondern auch mit anderen Projekten, die man nicht eben schnell als Kopie woanders aufsetzen kann.
Ich habe schon genug Abende, Nächte und Wochenenden an einem Live-System gehangen um es wieder zum laufen zu bringen, Hacker auszusperren, DDoS abzuwenden, oder Nachts umfangreichere Arbeiten zu machen weil tagsüber zu viel Traffic war.
Man kann auch in einer Kopie nicht alles simulieren, manchmal oder sogar öfter braucht man den Live-Traffic, wenn z.B. 1000 User gleichzeitig online sind, die Datenbank rödeln und die automatischen "Bots" laufen und man diesen Input-Output-Strom braucht. "Fließendes" kann man nur beim Fließen beobachten.
Natürlich muss man wissen, was man tut und wo Gefahren lauern und was man tun kann, wenn's doch mal kracht. Bei ganz heiklen Dingen wurde das im User-Forum und in den News vorher von mir oder den Untergebenen (Coder ) bekannt gegeben und vom Hoster noch eine extra DB-Sicherung gefahren.
Es sind nicht immer kleine Webseiten, an denen ich arbeite

Contenido ist ja sehr einfach und schnell auch lokal aufgesetzt (auch als kopierte Instanz).

Auch das nicht immer, sondern nur, wenn es eine kleine Contenido Webseite ist.
Aber mit Contenido kann man bekanntlich (?) mehr machen als nur eine Homepage.
Wenn das z.B. mal mehrsprachig mit mehreren Mandanten und vielen Usern gleichzeitig auf spezielleren Systemen (Scientific Linux, krude DB- und Servereinstellungen) läuft, wird es schwerer, das "schnell mal" zu kopieren und zu simulieren.

Tue dir einen Gefallen und tüftel lokal daran rum. Wenn du dann einen Workarround hast, übertrag es ins Live (BACKUP vorher nicht vergessen!)

Das Problem liegt ja nicht daran, dass ich nicht wüsste, wie man sowas sicher abwickelt, sondern am Auftrag:
Ich bin in diesem Fall ein Subunternehmer, habe keinen direkten Kundenkontakt.
Das Budget ist nicht da, es ging "nur um eine Kleinigkeit".
Wie so oft halt ... also lassen wir das
Ich werde jedenfalls nichts tun, wofür ich nicht den Auftrag habe. Weil wenn dann was passiert, wird es erst recht heikel für mich.
Aber ich muss trotzdem wissen, wie man das Problem am besten lösen könnte und was schlimmstenfalls passiert. Das kann ich dann meinen Kunden weiter geben und die dann ihren Kunden.
Vielleicht steckt ja schon ein Fortpflanzungsfehler im System, der sich gar nicht so einfach lösen lässt, aber in Zukunft noch mehr Probleme machen könnte.

Zum lokal aufsetzen möchte ich noch anmerken, dass ein lokales System nicht dem Server im Internet entspricht.
Wenn ich also vergleichbare Umstände haben möchte, dann setze ich eine Kopie auf dem gleichen Server auf, in einer Subdomain und möglichst gleicher Datenbank (ev. mit anderem Prefix).
So kommen dann keine Überraschungen, wenn es tragende Unterschiede zwischen lokalem System und dem Hoster-System gibt.
Gerade vor Weihnachten fragte mich noch ein Kollege, wie man denn sicher Wordpress von lokal auf online setzt.
Das ist wegen mancher Plugins und Caches gar nicht immer so einfach wie man denkt, auch bei Contenido nicht, wie ich feststellen musste.
Manche Entwickler schreiben in umfangreichen Plugin- und Modul-Konstrukten, sowie CSS, HTML und Javascript die absoluten Pfade rein und dann geht gar nichts mehr bei einem Umzug.
In den Datenbanken steckt das dann auch noch in verschiedenen Tabellen drin, oft encoded.
Sogar scheinbar identische online Contenido Systeme waren es mal nicht, bei einem lief die Article-List-Advanced und Mod-Rewrite problemlos, beim andern gar nicht.
Und das heimtückischste für Entwickler ist das homogene Arbeitsumfeld.
Es passt alles und man übersieht, dass man sich alles passend gemacht hat und fremde Computer anders sind und vielleicht nicht passend, besonders auch die Browsereinstellung.
Lokal kann dann alles gut laufen, aber im Internet beim Abruf von fremden Computern kracht es dann.
Darum, am Live-System arbeiten ist manchmal nicht so falsch, wenn man weiß, was eher harmlos ist und wo es kritisch wird.
Und utf-8 ist kritisch.

Trotzdem danke