Guten Tag,
In der OXID6-CE ist der “DDOE WYSIWYG Editor” mit dabei. Ist dieser Editor die Basis für das OXID6-PE Visual-CMS-Moduls? Ich habe bisher alle Projekte mit der CE umgesetzt und kenne die genauen PE-Abhängigkeiten der verwendeten Module nicht.
Ich möchte gern nah am OXID6-Core und seinen Basis-Modulen bleiben und präferiere daher auch den “DDOE WYSIWYG Editor”.
Mich treiben aber zwei Fehler um:
https://bugs.oxid-esales.com/view.php?id=6779
https://bugs.oxid-esales.com/view.php?id=6884
Der erste ist als schwer eingestuft aber noch nicht gefixt. Hier frage ich mich, ob das Problem nicht auch in der PE schon längst aufgefallen ist.
Der zweite Fehler ist als Feature eingestuft worden. Ich sehe es nach wie vor als Fehler an, da er die Erweiterung von OXID für den Fall das mehr als ein WYSIWYG-Editor im Backend gleichzeitig genutzt wird, unmöglich macht.
Ich frage deshalb, da ich in der OXID4-Version ein eigenes RTE-Modul auf Basis des CKEditor4 + ResponsiveFilemanager hatte und ich nun überlege, ob ich es auf OXID6 migriere und den dann anstelle des DDOE WYSIWYG Editor nutze.
Ich würde es aber nicht machen, wenn in der PE der DDOE WYSIWYG Editor zwingende Voraussetzung für das Visual CMS ist…
Versteht Ihr meine Zwickmühle?
Ich will meinen Kunden durch eine Eigenentwicklung nicht die Chance auf ein Wechsel von einer CE zu einer PE verbauen …
Um ehrlich zu sein: So richtig nicht 
Es gibt für #6779 einen Workaround von @hrieth im Bugtracker, für #6884 hast Du ja selbst vor ein paar Tagen einen Pull Request eingereicht, der sicher bald unter die Lupe genommen wird. Dabei ist es egal, ob es ein Bug oder ein Feature ist. Der “Issue” und der Fix werden sicher bald beäugt (sobald die Urlaubs-Saison vorüber ist).
DDOE ist ja quasi der vCMS und wird mit PE und EE gebundelt. Deshalb kann ich die Frage nicht wirklich verstehen…
ddoe wisywig = der neue summernote editor in der ce
visual cms = digidesk visual cms
@marco.steinhaeuser & @vanilla_thunder: Danke Euch.
Meine Frage kam daher, dass ich mir die OXID-eigenen Module immer als eine Art saubere OXID-Integrations-Referenz anschaue.
Ich war aber über die Art und Weise wie der “ddoe wisywig” in den Admin eingebunden und initialsiert wird (Ich meine hier vorallem den TPL und JS-Part) etwas überrascht (oder besser entäuscht).
In einem Visual-CMS-Webinar war die Rede von “einmal entschieden, dann kein zurück”. Das Gefühl habe ich -wenn ich mir nur den “ddoe wisywig” anschaue nicht. Daher war meine Vermutung, dass die eigentlichen Visual-CMS-Funktionen die zu der o.g. Aussage führten, irgendwie losgekoppelt vom “ddoe wisywig” sein müssten.
Ich wollte mir über die Konsequenzen aus den Aussagen und dem was ich sehe im klaren werden. Ein WISIWYG-Editor ist halt eine Backend-Kernkomponente.
Danke, Marat. Da lag ich falsch.
Hab mich erst einmal für das Refactoring meines RTE-Modules entschieden, bis es Besserung beim “ddoe wisywig” gibt.
FYI: RTE-Module mit CKEditor + FileManager bei packagist
Da ich jetzt das erste Mal Zugriff auf eine EE Edition habe, hier die Richtigstellung:
Der “WYSIWYG Editor + Mediathek” (ddoewysiwyg) ist in allen drei Versionen enthalten. Dazu onTop in der EE und PE dann das Modul “Visual CMS” (ddoevisualcms).
Das “Visual CMS” arbeitet mit zusätzlichen Smarty-Tags. Das erklärt auch, warum es nach einer Nutzung von “Visual CMS” kein Zurück mehr gibt, da die Smarty-Tags dann nicht mehr interpretiert werden können.
“Visual CMS” kann alle CMS-Texte anpassen, lässt aber Artikel-, Kategoriebeschreibungen etc.in Ruhe.
“Visual CMS” ist ein eigener Memü-Punkt und ersetzt den Menüpunkt “CMS-Seiten”.
“Visual CMS” setzt komplett auf den “WYSIWYG Editor + Mediathek” auf und integriert diesen Editor bei der Bearbeitung der Inhalte. Ein freies Konzept zur Nutzung alternativer Editoren, so wie es OXID selbst in seinem Core vorsieht, gibt es nicht.
2 Likes