WYSIWYG-Editor Probleme. Gibt es Lösungen.

[Amigo]

Hallo,
ich möchte hier einmal unsere Probleme mit dem WYSIWYG-Editor schildern. Möglicherweise hat ja jemand eine Lösung oder es ist eine in Aussicht.

Im Moment haben wir das Problem das wir Redakteuren praktisch keinen vernünftigen WYSIWYG -Editor zur Verfügung stellen können.

Wenn Prototype "aktiviert" ist funktioniert im IE die Auswahl des Schriftstiles nicht mehr (ok, dass ist bekannt). Dadurch können z.B. keine Überschriften mehr angelegt werden. Das ist schade da der IE8 sonst scheinbar alles korrekt auszeichnet (z.B. <strong>). Aber auch beim Editieren in einem neuen Fenster (inlineedit=false) macht der IE keinen Spass da es oft einige Gedenksekunden gibt bis der Text geladen wird. Außerdem läuft er halt nur auf Windows.

Am liebsten wäre uns aber ein Editor (also Browser) der auf allen wichtigen Plattformen zuhause ist. Also Firefox oder Chrom. Die Redakteure setzten die verschiedenen Betriebssysteme in der Praxis ja auch ein. Firefox hat bei inlineedit=true scheinbar auch ein Problem mit Prototype (kann man ja umgehen). Leider zeichnet er aber auch sonst das Meiste nicht korrekt aus (z.B. <span style="font-weight: bold;"> anstatt <strong>). Das ist nicht prakistauglich. Jeder Kunde fragt heute nach Suchmaschinenoptimierung. Da sind solche Dinge schon wichtig.

Bleibt noch Chrome. Manche Redakteure haben Paranoia und setzten diesen aus Prinzip nicht ein (für diese bleibt dann oft nur Firefox übrig). Bei Chrom (und auch Safari bzw. anderen Webkit Browsern) werden bei inlineedit=false die Absätze oft nicht richtig ausgezeichnet bzw. unnötiger Code eingefügt. Es ist schwer nachvollziehbar was wann wie genau passiert, aber oft kommt eben nix Gutes dabei raus. Speziell bei Copy und Paste von reinen Texten (also nicht direkt aus einer Textverarbeitung oder so) gibt es oft Probleme mit Absätzen. Ein Entwickler wird dies sicher in den Griff bekommen (auch wenn es keinen Spass macht), ein normaler Redakteur ist hier aber meist überfordert. Er will dies normalerweise auch gar nicht machen. Er will einfach nur seine Texte möglichst einfach in die Seite bringen.

Bei inlineedit=true kann man in Chrom keine Styles mehr auswählen (Prototype ist nicht aktiv), dafür gehen scheinbar aber andere Dinge etwas besser.

Hat jemand eine Praktikable Lösung für das Problem oder wie löst Ihr das Problem in der Praxis? Ignorieren?

Gruß, Amigo

[we:willRockYou]

Hola Amigo,

Gerade aktuell gibt es in der Bugbase wieder eine kleine Diskussion dazu: http://qa.webedition.org/tracker/view.php?id=4182 Wie dort zu lesen ist, ist es sehr aufwändig den WYSIWYG auszutausche. Damit würde ich in nächster Zeit nicht rechnen.

Wenn man auf sämtliche Features des WE-WYSIWYG verzichten kann, also keine Dateiselektoren für Dateien/Objekt/Bilder etc. braucht, kann man natürlich den richtigen WYSIWYG komplett deaktivieren (wysiwyg="false") und sich selbst etwas per JavaScript basteln. Die Editoren wie Tiny oder CK lassen sich ja auf beliebige textareas anwenden. Auch bei Objekten sollte das kein Problem sein, dort kann man JS-Code über eine Feldbeschreibung einschleusen. Nur ohne die erwähnten Features macht ein WYSIWYG für mich nicht viel Sinn. Da nehme ich lieber die Unzulänglichekiten des integrierten Editors in kauf.

In der Praxis ignorieren wir das Problem tatsächlich. Viele unserer Kunden lassen Ihre Seiten von uns pflegen. Andere Seiten wiederum sehen aus wie Sau, da stört es den Kunden jedoch auch nicht. Da wird dann auch Word direkt reinkopiert. Kann man den Leuten einfach nicht ausreden...

[Amigo]

Hallo Daniel,

bei uns pflegen die meisten Kunden die Website selbst (z.B. Marketingabteilung) und legen gleichzeitig Wert auf Qualität UND einfach Bedienung. Das ist echt ein Problem wenn man eher teure Websites anbietet. Da wird auf solche Sachen ehre geachtet. Bis auf ein paar Dinge sind wir mit dem Funktionsumfang von WE recht zufrieden. Die Entwickler bei und kennen es jetzt schon etliche Jahre und können daher im Prinzip alle Wünsche der Kunden lösen. Das mit dem WYSIWYG ist aber echt ein Problem. Auch wir wollen nicht auf die Funktionalität WE-Spezifischen Funktionen des Editors verzichten. Die Verlinkung mittels ID ist eine wirklich tolle Sache und wird grade von Kunden mit größeren Websites und vielen Redakteuren als Vorteil gesehen. Sonst gibt es sehr schnell tote Links und keiner war es:-) Von daher ist der WE-Editor natürlich sehr wichtig. Noch dazu haben wir eine Funktion die die von Redakteur eingebundene Bilder mit einet Zoom-Funktion versieht (wenn das Bild nicht verlinkt ist).

Jetzt muss ich mal überlegen was ich den Redakteuren für die Zukunft empfehle. Bei Windows kann man zumindest den IE 8 verwenden. Die Anderen sind "zum Glück" im Moment eher in der Minderheit:-)

Gruß, Amigo

[we:willRockYou]

Ein Vorschlag: Wenn es nur um die Semantik geht, <b> vs. <strong> etc. kann man das sehr leicht über reguläre Ausdrücke lösen.

Du kannst im Master-Template sowas in der Art machen:

Code: Alles auswählen

<?php
   ob_start();
?>
Hier kompletter Inhalt des Templates, sämtliche <we:tags /> etc.
<?php
   $content=ob_get_clean();
   if($GLOBALS['we_editmode'] != true) {
      echo preg_replace(
         array(
            '#<b([^a-z>]*)>#i',
            '#<i([^a-z>]*)>#i',
         ),
         array(
            '<strong$1>',
            '<em$1>',
         ),
         $content;
      );
   }
   else {
      echo $content;
   }
?>

So ungefähr, ungetestet. Muss man etwas mit rumspielen bis man alle möglichen Fälle erwischt hat.

[Amigo]

Das ist ein sehr guter Ansatz. Ich habe eben nämlich festgestellt das der IE8 auch bei inlineedit=true sehr langsam bei längeren Texten, bzw. mehreren textarea Feldern auf einer Seite, ist. Für Kunden ist dies nicht zumutbar. Wenn Dein Vorschlag gut funktioniert kann man Firefox einsetzen und hat erst mal eine gute Übergangslösung.

Danke, Andreas

[Toddler]

Siehe auch hier:
http://forum.webedition.org/viewtopic.php?f=41&t=13431