WBCE CMS – Way Better Content Editing.
You are not logged in.
Hier mal eine Vorschaltseite mit Ace Editor.
Die Änderung ist minimal (eine Datei im Anhang), aber das zu generalisieren sehe ich als nicht machbar an.
Schaut euch das einfach mal an.
Diese Datei in "Admin-Verzeichnis"/pages einfach ersetzen.
Last edited by mastermind (29.07.2021 09:21:05)
Offline
Hallo mm,
ich schaue es mir an, aber es kann sein, dass ich erst morgen dazu komme.
Schönen Gruß,
Christian
“Success is the progressive realization of a worthy ideal.” ― Earl Nightingale
Offline
Der Ace Editor ist ein Ersatz für EditArea. Er kann Syntax Highlighting, Syntax Check, Beatify, autom. einrücken, auskommentieren etc. für php, html, css, javascript und hat eine starke Community. Das Farbschema, Schriftgröße etc. kann individuell pro User und Funktion konfiguriert werden.
Habe mal 3 Funktionen geändert, bitte mal testen, ob es bei euch auch funktioniert oder etwas fehlt.
1. Droplets: die Datei "droplets.zip" entpacken und den Inhalt nach "modules" kopieren
2. Vorschaltseite: die Datei "vorschaltseite.zip" entpacken und den Inhalt nach "admin" kopieren. Wenn das Admin Verzeichnis per config geändert wurde, das entsprechende Verzeichnis verwenden.
3. CKeditor: die Datei "ckeditor.zip" entpacken und den Inhalt nach "modules" kopieren. Das ersetzt die Quellcode Bearbeitung.
Für alle 3 Funktionen ist das Modul "ace" Voraussetzung und muss vorher über die Admin Funktion installiert werden.
Bitte um Feedback, ob das bei euch funktioniert wie beschrieben.
Last edited by mastermind (25.08.2021 10:23:43)
Offline
florian
Hallo mastermind,
habe deine 3 Themen zu einem zusammengelegt.
die plugin.js des CKE ace Plugins hast du die gemacht oder gibt's die als fertiger?
Damit sich keiner Wundert, die durch mastermind geänderte Datei für das Intro manipuliert das Fraggy Theme und der Inhalt des Droplet Zips verpasst dem elFinder ein Drittanbieter Design im Material Look
Offline
@mastermind
Funktioniert. Coole Sache. Danke dafür!
Sorgen sind wie Nudeln: man macht sich meist zu viele.
Offline
Danke für das Feedback!
Hallo colinax,
das plugin,js für den CKE hab ich gemacht, gibt es nicht im Netz (habe schon einige Plugins für ckeditor gemacht, allerdings für Version 3).
Das Droplet Zip enthält leider auch die Änderungen für den elFinder, das war ein Versehen und sollte nicht im Zip enthalten sein.
Noch eine Frage an Florian: wird das irgendwann im Release enthalten sein, oder kann das jeder nach Bedarf benutzen?
Offline
Ich wäre schon dafür, das in den Core aufzunehmen, d.h. zumindest überall dort, wo noch jetzt noch EditArea zum Einsatz kommt, zukünftig ACE zu verwenden.
Ich würde es auch sinnvoll finden, standardmäßig das Material Theme für den elFinder auszuliefern, da die Icons dort besser erkennbar sind und sich das deutlich harmonischer in unsere BE-Themes einfügt.
Last edited by florian (26.08.2021 10:34:45)
Sorgen sind wie Nudeln: man macht sich meist zu viele.
Offline
Könnte natürlich auch bei der Umstellung von anderen Modulen helfen, wenn das gewünscht ist.
Da ich selbst diese Module nicht benutze, müsste mir dann allerdings jemand sagen, wie ich diese testen kann.
Offline
Hallo mastermind,
ich hab mir die Download aus #28 angesehen.
Was den elFinder angeht, den Code zur Anpassung der Höhe wurde ich gerne fix übernehmen , wenn du nichts dagegen hast.
Das CKE Ace Plugin hat noch offene Baustellen aber die sollten keine Probleme darstellen:
Mehrsprachig muss vorhanden sein, soll heißen mindestens EN und DE muss es können.
Das Plugin muss funktionieren, ohne dass dafür ein Würgaround im Lade Skript des CKE eingebaut werden muss
Damit weniger Verwirrung entsteht sollte das Plugin den Platz des alten Sourcearea einnehmen.
Wenn du dir die CKE Plugins ckawesome, wbdroplets und sourcearea ansiehst. sollten die obengenannten Punkte schnell erledigt sein
Beim Ace Ace Modul selbst muss auch noch angelegt werden
Ist das schwarze Design das default Design?
So wie aktuell die User Einstellungen gespeichert werden ist es nicht ideal, wenn die Seite viele User hat entsteht schnell Chaos im Modulordner, da muss was besseres wie z.b. eine DB Abfrage her oder man lagert das Ganze in den var bzw. temp Ordner aus (wie es z.B. errorlogger oder elFinder machen)
Läuft ACE eigentlich auch mit jQuery 3 und jquery müsste man auch auf den WBCE internen jQuery Pfad ändern
Die Dateien müssten dann auch so abgesichert werden dass diese nur innerhalb von WBCE und einer angemeldeten Session funktionieren
Lg
Offline
elFinder: ja, bitte Höhe übernehmen
CKE Ace Plugin:
- mehrsprachig: verstehe ich
- Würgaround: welche Zeile in welchem Verzeichnis genau meinst Du da?
- den Platz von sourcearea einnehmen: verstehe ich nicht, meinst Du damit kein autonomes eigenes Fenster?
Ace Modul:
- sag mir einfach, welches Design von den vielen soll das Default sein
- würde dann die Dateien im Verzeichnis "/var/modules/ace/" ablegen - gibt es dafür vordefinierte Konstanten?
- jquery 3 sollte kein Problem sein: gibt es für den Pfad eine vordefinierte Konstante?
- was meinst Du da zusätzlich ausser der index.php mit dem Inhalt "header("Location: ../index.php", true, 301);" oder "header('Location: ../../index.php');"
Du siehst: meine Erfahrungen mit WBCE sind im allgemeinen sehr gering.
LG
Offline
Mit Würgaround meine ich die Änderungen in der modules/ckeditor/ckeditor/ckeditor.php
Ich habe mal das CKE Plugin angepasst, folgendes wurde geändert (Zip ist im Anhang):
Modernere Icons
Multilang wurde implementiert (es wurden aber noch nicht alle Texte ersetzt)
Die CSS Anpassungen die in der ckeditor.php waren, wurden in eine Plugin eigene theme.css verschoben
Plugin nimmt jetzt in der CKE Toolbar den Platz des alten Source ein
Was das Ace Modul angeht, ist es möglich dass man die User eigenen Design entfernt und einfach sagt Design X ist global gültig?
Was Erfahrungen mit WBCE angeht, WBCE ist so gemacht dass es ziemlich viel erlaubt und der benötigte Einstiegslevel zu anderen CMS gering ist.
Wenn man weis wo man nachschauen kann bekommt man auch vieles.
Wenn man innerhalb eines Modules jQuery benötigt aber dass vorhandene jQuery nicht greift, kann man auf diese Datei verweisen: include/jquery/jquery-min.js (ob man den Pfad relativ oder per WB_URL angeben kann/muss hängt von der Stelle ab wo es ist).
Wenn dir bestimmte Variablen oder was auch immer nichts sagen, hilft oft eine Suche innerhalb des GitHub Repos weiter
Offline
Habe das CKE Plugin übernommen und wieder lauffähig gemacht und die fehlenden Übersetzungen eingebaut.
Die Möglichkeit, das Design zu ändern und die Schriftgröße zu wechseln möchte ich auf alle Fälle behalten, da das einige Anwender wollten.
Daher habe ich die eine geänderte Zeile in der modules/ckeditor/ckeditor/ckeditor.php behalten.
Die Änderungen für das Ace Modul habe ich übernommen und die Parameter werden jetzt im Verzeichnis /var/modules/ace/ gespeichert.
Ich würde jetzt noch die Übersetzungen einbauen. Was ist bei euch Standard, um Übersetzungen in Javascript Sourcecode einzubauen, gibt es da ein Beispiel, das ich nutzen könnte?
Vielen Dank für das Ändern und die Unterstützung!
Offline
Habe jetzt die Änderungen gemacht, auch die 2 Sprachen (DE, EN).
Beim Test erscheinen die englischen Texte nur im CKeditor, ansonsten bleibt die Konstante LANGUAGE (die ich abfrage) immer auf "DE" und ich konnte das nicht umstellen. Vielleicht könntet ihr das mal testen.
Das Verzeichnis "ace" in "modules" vor dem Kopieren der neuen Dateien bitte löschen.
Anbei noch ein Droplet zur Anzeige der in WBCE definierten Konstanten (zur Programmierung und Fehlersuche)
Last edited by mastermind (09.09.2021 11:57:03)
Offline
In WBCE gibt es mehrere Ebenen wo die Sprache definiert wird, im Backend ist das die DEFAULT_LANGUAGE in den Grundeinstellungen und User definierte Sprache innerhalb der $_SESSION['LANGUAGE'], Im Frontend kommt zusätzlich noch die Sprache der einzelnen Seiten dazu.
Last edited by colinax (10.09.2021 13:45:51)
Offline
Mehrere Fragen:
Wozu gibt es dann die Konstante LANGUAGE die über 300 Mal in WBCE abgefragt wird?
Kann ich das Backend in Englisch betreiben? Ich habe bei den Grundeinstellungen > Standardeinstellungen "English" als Sprache ausgewählt, das ändert gar nichts (Standardinstallation 1.5.0). Einzig die Login-Maske ist Englisch.
Es gibt bei mir keine Konstante SESSION_LANGUAGE, auch die Variable $user_language enthält "DE" - also welche Konstante / Variable sollte ich abfragen?
Offline
Die Sprachhandhabung ist leider bei WBCE aus historischen Gründen etwas merkwürdig gelöst.
Du kannst Backend und (als angemeldeter Nutzer) das Frontend in der von Dir gewählten Sprache (sofern diese installiert ist) anzeigen. Diese Einstellung nimmst Du bei "Meine Daten" vor.
Tipp: Installiere Dir das Admin-Tool "System Information", das zeigt Dir auf dem Reiter "WBCE Constants" alle definierten Konstanten und deren Werte an.
Sorgen sind wie Nudeln: man macht sich meist zu viele.
Offline
Die Sprachhandhabung ist leider bei WBCE aus historischen Gründen etwas merkwürdig gelöst.
Dass trifft es perfekt.
@mastermind
Damit du ungefähr versteht wie der Core die Sprache definiert, poste ich mal einen Code:
if (!defined("LANGUAGE")) {
// Get users language
if (isset($_GET['lang']) && preg_match('/^[A-Z]{2}$/', $_GET['lang'])) {
define('LANGUAGE', $_GET['lang']);
$_SESSION['LANGUAGE'] = LANGUAGE;
} else {
if (isset($_SESSION['LANGUAGE']) && $_SESSION['LANGUAGE'] != '') {
define('LANGUAGE', $_SESSION['LANGUAGE']);
} else {
define('LANGUAGE', DEFAULT_LANGUAGE);
}
}
}
Habe entsprechend #39 angepasst
Je nach Modul kann es vorkommen dass die Modulsprachdateien anders eingebunden sind, da es die Programmierung sonst nicht korrekt übernommen hätte.
Sofern unter php alles im Browser Tab bleibt, sollten alle Parameter überall funktionieren, in Verwendung von AJAX und JS oder PopUps kann es durchaus sein, dass die Sprachen nicht funktionieren da diese Techniken am anderen Ende der Leitung umgesetzt werden bzw. durch die Template Engine nicht sauber durch kommt.
z.B. Die elFinder Oberfläche die im CKEditor geöffnet wird richtet sich aus technischen Gründen nach der Browsersprache.
Offline
Ja, das mit den Sprachen funktioniert tatsächlich merkwürdig:
die Anmeldemaske wird englisch angezeigt, wenn ich bei "Grundeinstellungen" Englisch angebe
das Backend wird Englisch, wenn ich bei "Meine Daten" Englisch angebe
der CKEditor kümmert sich darum überhaupt nicht, er zeigt Englisch nur dann an, wenn in den Einstellungen des BROWSER Englisch angegeben wird
Das heißt: ein Anwender muss 3 Einstellungen ändern, wenn er WBCE komplett Englisch betreiben will. Das erfordert natürlich Aufwand und viel Kenntnisse für den Anwender.
Für das ace Modul muss ich die Variable $_SESSION['LANGUAGE'] abfragen, das funktioniert bei mir jetzt (Danke für die Korrektur colinax).
Vielleicht könnt ihr das auch mal ausprobieren.
Beim CKEditor Plugin nutze ich die Variable "CKEDITOR.currentInstance.lang", damit es so funktioniert wie bei den anderen Plugins.
Die Module Droplets und Vorschaltseite mussten auch geändert werden, da sich der Aufruf geändert hat, deswegen in den zips enthalten. Ace kann ganz normal als Modul installiert werden.
Last edited by mastermind (11.09.2021 10:25:26)
Offline
Ja, das mit den Sprachen funktioniert tatsächlich merkwürdig:
die Anmeldemaske wird englisch angezeigt, wenn ich bei "Grundeinstellungen" Englisch angebe
das Backend wird Englisch, wenn ich bei "Meine Daten" Englisch angebe
der CKEditor kümmert sich darum überhaupt nicht, er zeigt Englisch nur dann an, wenn in den Einstellungen des BROWSER Englisch angegeben wird
Das heißt: ein Anwender muss 3 Einstellungen ändern, wenn er WBCE komplett Englisch betreiben will. Das erfordert natürlich Aufwand und viel Kenntnisse für den Anwender.
Hallo mastermind,
deine Punkte betreffen diese Merkwürdigkeit gar nicht, da dies eher im Core vorzufinden ist aber der Reihe nach.
Dass sich die Anmeldemaske nach den Grundeinstellungen richtet ist legetim, zu diesem Zeitpunkt weis die Seite ja noch nicht wer Du bist.
Wenn ein neuer User erstellt wird, hat dieser auch die Sprache der Grundeinstellungen.
Was den CKE angeht diese Setting dass sich der Editor nach der User Sprache richtet, flog vor ein paar Jahren mal raus, aus welchem ich das machte weis ich nicht mehr aber das lässt sich wieder leicht ändern.
Füge dafür in der include.php Zeile 84 folgenden Code ein:
// Set user language
$ckeditor->config['language'] = strtolower(LANGUAGE); // Default $ckeditor->config['language'] = '';
// The language to be used if config.language is empty and it's not possible to localize the editor to the user language.
$ckeditor->config['defaultLanguage'] = strtolower(DEFAULT_LANGUAGE); // Default $ckeditor->config['defaultLanguage'] = 'en';
Edit: Diese Änderung ist in der nächsten CKE Version enthalten
Last edited by colinax (11.09.2021 17:18:14)
Offline
Habe jetzt die 2 Zeilen eingefügt, damit ist eine zusätzliche Umstellung der Sprache im Browser überflüssig.
Zusätzlich habe ich gleich noch eine Abfrage eingebaut, ob das Ace Modul installiert ist.
Last edited by mastermind (11.09.2021 14:25:28)
Offline
Besteht eine Wahrscheinlichkeit, dass der Ace-Editor mal für den CKeditor, die Droplets etc. in den Standard-Release aufgenommen wird?
Offline
Ich hatte das aus den Augen verloren, Asche auf mein Haupt.
Also, ich habe mir das jetzt mal angeschaut. So weit funktioniert das schon recht gut. Und ja, wir sollten EditArea in einer der nächsten Versionen durch ACE ablösen.
Was noch nicht klappt: Wenn bei Grundeinstellungen > WYSIWYG-Editor > "Keine" ausgewählt wird, kommt noch EditArea. Auch wenn Syntaxhighlighting in Code-Eingabefeldern von Modulen implementiert ist (z.B. bei Cookie Consent), wird EditArea geladen.
Ideal wäre, wenn es ginge, den EditArea-Backend-Include so zu "verbiegen", dass dieser nur noch als leere Hülle bzw. Wrapper für ACE dient, so dass gar keine weiteren Anpassungen an den jeweiligen Modulen erforderlich sind.
Im Interesse der Komplexitätsredultion würde ich darauf verzichten, den Nutzys 37 verschiedene Ace-Themes zur Auswahl zu stellen. Entweder gar keine Themeauswahl und dann das "Eclipse"-Theme, oder halt ein Dark- und ein Light Theme.
Last edited by florian (23.12.2021 10:37:35)
Sorgen sind wie Nudeln: man macht sich meist zu viele.
Offline
Hallo Florian,
super, dass Du dieses Thema noch mal aufgreifst, habe das jetzt auch bei 1.5.2 im Einsatz und sehr happy damit.
Wie das Ganze generalisiert werden kann - also eine Änderung an einer Stelle und alle EditArea Aufrufe werden automatisch zu ACE - wäre natürlich auch aus Wartungsgründen am besten. Dazu sehe ich mich allerdings nicht in der Lage, das professionell umzusetzen, dazu kenne ich WBCE zu wenig.
Vor allem beim CKEditor sehe ich da Probleme, war jetzt schon etwas aufwendig, dass vernünftig umzusetzen. Auch kenne ich die diversen Stellen und verschiedenen Module zu wenig um das zu testen (z.B. Cookie Consent), aber das ganze vielleicht zu unterstützen kann ich natürlich.
Was die Themes betrifft: es mach kaum einen Unterschied, wie viele Themes es gibt. Beim ersten Aufruf wird das gewählte Theme sowieso pro Nutzer und Modul gespeichert und wird dann immer angezeigt. Und das Thema Speicherplatz spielt keine Rolle, es wird ja kein Theme mit dem ACE Modul ausgeliefert.
Wenn Du da weiter etwas testen willst, kann ich Dir die neuesten Module und Änderungen liefern.
Offline
Wie das Ganze generalisiert werden kann - also eine Änderung an einer Stelle und alle EditArea Aufrufe werden automatisch zu ACE ...
Dazu mal 'ne grobe erste Überlegung (nicht probiert - nicht länger rein vertieft):
in /include/editarea/ gibt es ja bereits die wb_wrapper_edit_area.php
könnte es da evtl. schon reichen die so zu "verbiegen", dass sie bei installiertem ACE diesen per include einbindet, ansonsten das Editarea-Geraffel ausführt?
... nein in Europa verwenden wir beim Programmieren nicht € statt $ ...
Online
Und das Thema Speicherplatz spielt keine Rolle, es wird ja kein Theme mit dem ACE Modul ausgeliefert.
Eine Frage hierzu: Lädt ACE die Themes dann aus externen Quellen nach? Das wäre allerdings nicht so schön.
Sorgen sind wie Nudeln: man macht sich meist zu viele.
Offline