WBCE CMS – Way Better Content Editing.
Du bist nicht angemeldet.
Hallo,
ich hab gestern kurzentschlossen mein WBCE bei Strato von 1.4.0 auf 1.4.1 aktualisiert. Upgrade-Skript ist ohne Fehler durchgelaufen. Daraufhin habe ich aber im Frontend Umlaute aus den WYSIWYG-Abschnitten als <?> angezeigt bekommen. Sind non-breakable spaces ( ) im html-Quellcode der section, lässt sie sich auch nicht mehr speichern.
Stelle ich in den EInstellungen global von utf-8 auf iso-8859-1 um, dann sieht es im Frontend wieder Ok aus, dafür sind im Backend die Symbole vom Font Awesome (?) ausgetauscht (sprich: es werden einfach die falschen Bildchen dargestellt).
Ich hab erst am ckeditor rumprobiert, den deinstalliert und neu hochgeladen, aber das war's nicht. Wahrscheinlich müsste ich die Datenbank auch auf utf-8 konvertieren. Da aber das WBCE wahrscheinlich schon als utf-8 codierte Inhalte rein geschrieben hat, darf ich auch nicht die ganze DB als Dump konvertieren, sondern muss wohl irgendwie Tabelle für Tabelle manuell durchgehen.
Hat jemand schon ähnliche Probleme beobachtet oder hat jenand einen guten Rat dazu?
Martin
Offline
cybernet333
Spaß mit Strato...
.htaccess im Root anlegen, bzw. falls vorhanden in selbiger ergänzen:
AddDefaultCharset UTF-8Wir Benötigen: Cents, Euros... jetzt spenden!
Online
stefanek
super, danke. Damit funktionierts 
Offline
stefanek
Tja, leider funktioniert damit das Backend schön, unabhängig von der Einstellung der Encodierung in den Settings.
Das Frontend ist aber leider trotzdem zerschossen. Menüs, Breadcrumbs usw. werden mit Umlauten richtig dargestellt.
Im ckeditor im Backend sieht es auch ok aus. -> also habe ich mir das wysiwyg-Modul angeschaut und siehe da:
ändere ich die letzte Zeile der view.php von
[== PHP ==]
echo html_entity_decode($content, ENT_HTML5);zu einem simplen
[== PHP ==]
echo $content;dann sieht's auch im Frontend richtig aus. Die Änderung hat commit b10bd11 eingebracht.
Offline
wie eigenartig. Beim Testen (allerdings nicht bei Strato zugegebenermaßen) vorm Release war dieses Problem nicht aufgetreten, und bei Webseiten, die bei verschiedenen anderen Hostern liegen, die ich auf 1.4.1 aktualisiert habe, ist das auch nicht vorgekommen. Auf diesen scheint es aber auch keinen Unterschied zu machen, ob nun echo $content oder echo html_entity_decode($content, ENT_HTML5); verwendet wird, der Output ist in beiden Fällen korrekt - auch wenn der CKE deaktiviert wird,und dadurch die Âçcèñtë usw. nicht in Entities umgewandelt werden.
Also für die 1.4.2 commit reverten?
Wir Benötigen: Cents, Euros... jetzt spenden!
Online
Wäre ich dafür. Html Entities sind ja extra dafür da, dass man bei der Übertragung von der Codierung von Sonderzeichen unabhängig ist und es der Client in seinem Kontext rendern kann.
Offline
Ich hätte bei der Nachverarbeitung von wysiwyg Inhalten eher die gegenteilige Funktion erwartet, nämlich htmlentities.
Aber die war ja auch unter 1.4.0 und früher an der Stelle nicht vorhanden (und nicht nötig)
Offline
Ich hab's mal in den development-Branch commited
Wir Benötigen: Cents, Euros... jetzt spenden!
Online
...ändere ich die letzte Zeile der view.php von
[== PHP ==] echo html_entity_decode($content, ENT_HTML5);zu einem simplen
[== PHP ==] echo $content;dann sieht's auch im Frontend richtig aus. Die Änderung hat commit b10bd11 eingebracht.
Moin. Hatte das selbe Problem, auch Strato. Konnte es damit lösen...
![]()
Offline
cybernet333
Vielen Dank
kann ich bestätigen, hat auch mir soeben geholfen das mit der view.php.
Bekam schon Schweißperlen auf die Stirn. ;-)
Danke
Offline
wird in 1.4.2 korrigiert sein
Wir Benötigen: Cents, Euros... jetzt spenden!
Online