Ich arbeite an einem benutzerdefinierten CMS, in dem CKEditor (4.5.1) für die freundliche Erstellung von HTML-Inhalten integriert ist.
Eine der Funktionen, die wir liefern, ist die Möglichkeit, Teile der Seite auf bestimmte Benutzergruppen zu beschränken, und die sauberste Art, dies zu tun, ist, dass ich ein neues Tag erstelle und dieses zur Verfolgung von Inhalten verwende , z.B <restrict data-usertype="1,2,3">restricted content for user types 1, 2, 3 here</restrict> , die vom Backend entfernt werden.
Das Problem, das ich habe, ist, dass mein benutzerdefiniertes Tag implizit sowohl Block- als auch Inline-Tags unterstützt, und ich bin mir nicht sicher, wie ich das richtig einrichten soll.
Ich habe eine Vielzahl von Kombinationen von Dingen ausprobiert, die es entweder überhaupt nicht zulassen, dass Inhalte hinzugefügt werden, oder das Plug-in vollständig zu deaktivieren (weil es mit ACFs eigener Plausibilitätsprüfung in Konflikt gerät); Die Konfiguration, die ich jetzt habe, lässt mich den <restrict> -Block hinzufügen, lässt ihn im Dialog bearbeiten (auch durch Doppelklick), lässt mich aber keinen Inhalt verschachteln und wird CKEditor dazu bringen, konnte beim Zurückschalten in den Quellmodus keine Attribute von 'null' lesen.
Meine aktuelle Konfiguration dieses Plugins ist wie folgt:
%Vor% Ich denke, ich habe editables falsch eingestellt und wahrscheinlich die allgemein zulässigen Inhalte für dieses Tag, aber ich kann nicht sehen, wie ich ein solches Tag erstellen soll, und ich kann mir das nicht vorstellen Ein solches Phantom-Tag, das außerhalb des Browsers geparst wird, wäre ein neues Problem.
Vielen Dank im Voraus!
Ich habe tatsächlich eine alternative Antwort auf dieses Problem gefunden, meistens indem ich das Problem ein wenig neu definierte.
Zuerst habe ich festgestellt, dass das CMS fast immer den Inhalt einschränkt, es wird es eher in einem Blockkontext als in einem Inline-Kontext tun - ganze div-Abschnitte würden eher entfernt als Teile einer Zeile.
Als ich das erkannte, erkannte ich, dass es nicht wirklich ein Widget ist, das ich erstellen musste, sondern ein konventionelleres Plugin.
Ich habe dann angefangen, indem ich das insert-div-Plugin für CKEditor genommen und angefangen habe, es anzupassen. In der Init-Methode des Plugins gibt es die folgende Grundkonfiguration:
%Vor% Dies stellt die Anforderungen des Plugins weitgehend ein, aber ich arbeite mit einer vorinstallierten Kopie von CKEditor, und ich habe weder Zeit noch Lust, einen Prozess zum Neuerstellen / Wiederherstellen von CKEditor einzurichten - was ein Problem ist, weil $blockLimit wird nur beim Start verwendet und das Hinzufügen auf der Plugin-Ebene funktioniert nicht, da die einzige Zeit, zu der es ausgewertet wird, bereits ausgeführt wurde, bevor Plugins geladen werden. Um dem entgegenzuwirken, klont das Plugin die Schließung und Definition von CKEDITOR.dom.editorPath, nachdem das Plugin ausgeführt wurde, so dass es die DTD-Methoden korrekt neu bewertet.
Ansonsten änderte ich alle 'creatediv' / 'editdiv' / 'removediv' Verweise auf '* restricte' entsprechend, änderte die Stellen, die auf 'div' überprüft wurden, auf 'restricte' und ersetzte die Dialogdefinition durch die dialog brauche ich eigentlich, was sehr anwendungsfallspezifisch ist. Da es sich meistens um einen Copy / Paste-Job handelt, scheint es nicht sinnvoll zu sein, welchen Code ich bereitstellen kann, da die Bits, die nicht Kopieren / Einfügen sind, für das Produkt spezifisch sind.
Was dies komplexer gemacht hat, ist die Tatsache, dass ich das Styling auch dynamisch auf dem Element "restrict" verwalte, um ein ähnliches Aussehen wie das "Show Blocks" -Tag zu erreichen, wobei die Liste der Einschränkungen im Tag selbst durch% co_de dokumentiert ist %, die auf ein Attribut des restrict-Tags selbst verweist, cke-restrict-description, das bei jedem Aufruf des Dialogs aktualisiert wird, sowie jedes Mal, wenn der Editor in den WYSIWYG-Modus wechselt (einmal in instanceReady, einmal in editor.on). Modus ') wo editor.mode ==' wysiwyg ')
Tags und Links ckeditor ckeditor4.x