CKEditor für WebsiteBaker - Bitte testen!

[Waldschwein]

Hallo!

Der CKEditor ist der Nachfolger des schon seit Version 2.7 in WebsiteBaker integrierten WYSIWYG-Editors (FCKEditor).

Warum einen neuen Editor?

Der FCKEditor ist etwas in die Jahre gekommen - über kurz oder lange wird es wohl keine Updates mehr geben.
Zudem ist er nicht mehr nach heutigem Standard.
Der CKEditor ist: Barrierefrei, schneller als viele Editoren, hat ein völlig neues Pluginsystem (dadurch stark anpassbar), viele Features, aber trotzdem einfach.
Also geradezu ideal für websitebaker.

Was kann das Modul?
Alles, was der FCKEditor auch kann.
Im Ordner _wbinstallation/modules/ckeditor/wb-config sind alle Anpassungen enthalten!

wb_fckconfig.js -> wb_ckconfig.js
Dort sind die meisten Einstellungen enthalten. Einige weitere sind in der include.php - v.a. aus dem Grund, weil man hier die Möglichkeiten von PHP nutzen möchte, was mit JavaScript nur umständlich funktioniert. Dies ist nicht anders als in FCKEditor.

wb_fckeditorarea.cs s -> editor.css
Die Standarddatei, die das Aussehen des Textfelds ermöglicht. Ist im Standardtemplate oder im Template der gerade bearbeiten Seite eine editor.css enthalten wird automatisch die vom Template geladen (kann auch in einem Unterordner css enthalten sein).

wb_fckstyles.xml -> editor.styles.js
Die Standarddatei, die eine Auswahl von Styles in einem Dropdown ermöglicht - wie im FCKEditor. Allerdings ist die Datei nun eine JavaScript Datei, anstatt eine XML.
Unter FCKEditor hat man in der fckstyles.xml ein Styleobjekt nach folgendem Schema erstellt:
<Style name="Big" element="big" />
Nun geht es in der .js folgendermaßen:
{ name : 'Big', element : 'big' },
Die editor.styles.js wird - wie die editor.css - automatisch vom Template geladen, sofern vorhanden (kann auch in einem Unterordner js enthalten sein).

wb_fcktemplates.xml -> editor.templates.js
Die Datei, die eine Auswahl von Templates (standardmäßig ein Button links oben neben Quelltext, sowohl FCK als auch im CK Editor) ermöglicht. Auch diese Datei ist nun eine JavaScript anstatt einer XML.
Da insgesamt diese Möglichkeit kaum genutzt wird verzichte ich hier auf eine Templateauswahl und eine genauere Beschreibung.
Alle Dateien in wb_config sind natürlich ausführlich kommentiert.

Herunterladen kann man sich die jeweils neueste Version hier:
AMASP: http://www.websitebakers.com/pages/admin/admin-tools/ckeditor.php
Git: http://github.com/Tenschert/ckeditor/downloads

Bitte: Testen, testen, testen - da nun CKEditor Modul den Status "Release Candidate (RC)" hat, auch auf Live-Seiten - allerdings auf eigene Gefahr. Auch auf Sicherheitslücken im Filebrowser & Uploader, bitte ebenso WBDroplet und WBLink testen!

Gruß Michael

[maverik]

moin

für / ab welcher  wb version soll das teil funktionieren? für die 1305 kann ich mit dem screen dienen. wie sie sehen, sehen sie nichts 

fehlermeldung keine, steht auf all 

os ubuntu 10.04
firefox 3.6.3 und opera 10.10

[Stefek]

Hier noch ein bisschen Ermutigung

Bei mir sieht alles super aus.
Wollte zwar erst morgen testen, aber dieses Baby kann ich kaum erwarten.

Am meisten Spaß macht es, wenn man mehrere Wysiwyg Sections hintereinander erstellt auf einer Seite und dann die Ladezeit mit der von FCK oder Tiny vergleicht 

Freu mich auf die Beta und sage: Danke für die Mühen.

Stefek

[Hans>NULL]

------------

[ruebenwurzel]

Hallo Michael,

hab voller Erwartung die neue Version (0.20) des ckeditor getestet und nachdem lokal alles wunderbar lief den auch mal auf meinen Server hochgeladen. Tja und da ist dann nix mehr zu sehen bzw. es sieht genau so aus wie bei Maverik.

Nachdem ich dann in der wb_config.js die Plugins WBDroplets und WBLink auskommentiert habe läuft alles.

Mein Fehlerreport meckert an, dass folgende Seiten nicht gefunden werden (bei aktivierten plugins):
/modules/ckeditor/ckeditor/plugins/WBDroplets/plugin.js?t=A39E
/modules/ckeditor/ckeditor/plugins/WBLink/plugin.js?t=A39E

Vielleicht hilft es weiter

Schönen Tag noch

Matthias

[maverik]

Nachdem ich dann in der wb_config.js die Plugins WBDroplets und WBLink auskommentiert habe läuft alles.

es geht um die wb_ckconfig.js

jo kann ich bestätigen, WBDroplets, WBLink raus geschmissen und der editor zeigt sich.

[Stefek]

Kann ich jetzt auch so bestätigen.

Kommentiert man es aus, läuft es dann aber sogar unter WB 2.7

Stefek

[Waldschwein]

Hallo!

Ok, ich gucke mal nach, wo das Problem ist.
CKEditor selbst läuft überall - es braucht ja kein PHP. 
Wenn es nach mir ginge, gibt es keine zusätzlichen Plugins wie CodeHighlighter, Flashplayer usw. - die machen nur Ärger und sind nur für sehr wenige Leute interessant, die sowieso "ihr" Modul haben, auf das sie schwören. Kann ja jeder einbauen. Nur habe ich das nicht alleine zu entscheiden.

Ah, mir kommt ein Gedanke: Wahrscheinlich unterscheidet XAMPP bei Ordnern nicht nach Groß-und Kleinschreibung, "echte Server" aber schon.
Weil /modules/ckeditor/ckeditor/plugins/WBDroplets/plugin.js gibt es nicht, es wäre
/modules/ckeditor/ckeditor/plugins/wbdroplets/plugin.js
Dann kann ich den Fehler gleich ausmerzen und gucke mal selber nach.

Jep, die Ladezeiten sind wirklich sehr gering. Damit ist auch das von einigen in 2.8.1 als "Bug" betitelte Abschnittsweise laden überflüssig.

Gruß Michael

[Stefek]

Jep, die Ladezeiten sind wirklich sehr gering. Damit ist auch das von einigen in 2.8.1 als "Bug" betitelte Abschnittsweise laden überflüssig.

Also das war auch kein userfreundliches Feature.
Ich finde, die Sections einer Page sollten alle auf einmal sichtbar sein, was jetzt sogar schnell gehen wird.

Gruß,
Stefek

[Waldschwein]

Hallo!

Bitte den neuesten Hotfix Version 0.2.1 http://github.com/Tenschert/ckeditor/downloads
ausprobieren! Damit sollte der CKEditor nun auch auf "echten" Servern laufen... Hoffe ich.

Gruß Michael

Edit: Leider gibt es nach wie vor Fehlermeldungen wie

Fehler: uncaught exception: [Exception... "Could not convert JavaScript argument"  nsresult: "0x80570009 (NS_ERROR_XPC_BAD_CO NVERT_JS)"  location: "JS frame :: http://www.thewbinstallation.xyz/admin/pages/modify.php?page_id=xyz :: <TOP_LEVEL> :: line xyz"  data: no]

Der Fehler ist hier

Code:

<script type="text/javascript">
if(window.attachEvent) window.attachEvent('onload',workingcopy_visibility(document.wysiwyg99, 'wysiwyg99'));
else window.addEventListener('DOMContentLoaded',workingcopy_visibility(document.wysiwyg99, 'wysiwyg99'),false);
</script>

Auf die Schnelle weiß ich allerdings nicht wirklich, wo das zu finden ist... Firefox und IE8 monieren den Fehler.

[ruebenwurzel]

Hallo,

habe 0.21 getestet. Ja, die plugins werden jetzt geladen, allerdings ist das wbdroplet plugin noch ohne Funktion. Will sagen, wenn man den button für wbdroplets auswählt passiert nix.

wblink zeigt zumindestens das Fenster mit den verfügbaren Seiten. Allerdings stimmt die Sortierung der vorgeschlagenen Seiten nicht. Scheint so, dass die Sortierung sich nach der page_id richtet und nicht nach dem Platz an dem die Seite liegt. Auch der eigentliche Vorgang des Verlinkens funktioniert noch nicht.

Das plugin uicolor versagt auch den Dienst. Sowohl lokal als auch auf dem Server. Für was ist das plugin eigentlich?

Ansonsten kann ich nur sagen, super, super Arbeit bis jetzt. Daumen hoch.

Gruß
Matthias

P.S.
getestet auf "echtem" Server

[Stefek]

Zum Testen komme ich grade nicht,

im Anhang aber ein "milder Beitrag" von mir: das WBinternLink Icon (3 zur Auswahl).

Gruß,
Stefek

(bitte nach dem Download unbedingt zurück ins *.GIF Format umbenennen)

[BlackBird]

Ah, mir kommt ein Gedanke: Wahrscheinlich unterscheidet XAMPP bei Ordnern nicht nach Groß-und Kleinschreibung, "echte Server" aber schon.

Das liegt nicht an XAMPP, sondern am Betriebssystem. So langsam sollte es sich doch wirklich rumgesprochen haben, daß Linux und UNIX case sensitive sind, Windows dagegen nicht. Es gibt auch "echte Server" auf Windows-Basis, die nicht case sensitive sind. Sie sind dann immer noch "echte Server".

[aldus]

Hm ... lokal läuft es hier ... MAMP 1.8.3

Aber ich tippe mal auch auf Groß- und Kleinschreibung. Alle ck-module haben __klein__ geschriebene Namen,
Bezeichungen, Unterordner. Warum sollte da die beiden WB-Module eine Ausnahme machen, gerade bei
den Bezeichnungen, aus denen sich anscheinend der __richtige__ Pfad zur Modul-Definition(-en) ergibt,
bzw. generiert wird?

Wegn dem WB-Link Modul hier noch mal eine Studie ... zumindest wird nun auch [wblinkxx] zurück gegeben ...
einen validen Anker gibt aber die Strategie so noch nicht her ... da wirst Du wohl um das generieren
eines Psydoelementes in der Api nicht herumkommen.

Auf jeden Fall würde ich abstand von dem ganzen I-Frame gehuchele nehmen ... da dann die __Ergebnisse__
bis zu ck ins DOM durch zu schleifen geht mit Sicherheit schief ... was geht ist, halt
die Definitionen nicht(!) auf eine .js Datei zu linken sonder auf eine PHP Datei die eben JS zurück gibt.
Macht auch das ganze WB-Abgefrage leichter ...

Zu der JS-Fehlermeldung - sieht mir nicht nach ck-editor aus, hab zumindest den Code-Schnipsel nicht
im ck-Baum gefunden .... tippe da ehr auf JQuery? Kann mich aber auch irren ..

Edit @Mattias: benenne mal die Modul-Odner in "WBDroplet" und "WBLink" um (erste drei Buchstaben __groß__),
ich denke, das dann zumindest die buttons funktionieren werden ...

Gruß
Aldus

[Waldschwein]

Hallo!

Danke Stefek - ich habe mir einmal ein Icon genommen, aber sieht man ja, evtl. passt ein anderes von den dreien besser (das erste hab ich mal genommen).

Zu den Modulen: Hmm... Also UIColor ist dafür gedacht, dass es eigentlich die Farbe von CKEditor anpasst. Im Grunde macht das Sinn, weil immer wieder Leute sagen, dass sie mit unterschiedlichen WB-Installationen arbeiten - aber man kann das auch wieder rausnehmen. Ist aber normalerweise im CKEditor drinnen. Die Farbe wird trotzdem in der config.js angegeben. Eigentlich macht UIColor nur Sinn, wenn der Wert in einem Cookie gespeichert wird - ich habe das einmal versucht einzubauen, aber evtl. rühren da ein paar Fehler her
.CKEditor läuft mit jQuery, bzw. bindet das irgendwie mit ein wenn es vorhanden ist.

WB-Link Modul: Also das jetzige vom FCKEditor macht so wie es ist keinen Sinn. Alleine durch den Aufruf vom Backend-Theme ist das so mit heißer Nadel gestrickt, dass ich lieber kein Modul nehme als das.
Danke für das Modul soweit - aber da muss wohl noch einiges nachgeholt werden, weil es keine Links generiert...
Hmm. Ich frage mich aber, warum die nicht aufgerufen werden... Ziemliches herumgestricke mit der Groß- und Kleinschreibung.

Gruß Michael

[ruebenwurzel]

@aldus

Edit @Mattias: benenne mal die Modul-Odner in "WBDroplet" und "WBLink" um (erste drei Buchstaben __groß__),
ich denke, das dann zumindest die buttons funktionieren werden ...

Hab mich vielleicht missverständlich ausgedrückt. Die buttons (und ich denke damit eigentlich auch die plugins) werden geladen, das ist nicht das Problem. Sie sind nur ohne bzw. haben nur eine eingeschränkte Funktion.

Teste jetzt mal das oben angehängtes wblink von aldus.
Edit:Testergebnis: Links werden in der richtigen Reihenfolge angezeigt. Der WB link wird eingefügt, aber anstatt dass das markierte Wort zu verlinken wird wird es durch [wblinkXX] ersetzt. Aber immerhin wieder einen Schritt weiter.

Gruß
Matthias

[Waldschwein]

Hallo!

Nein, es ist ein Unterschied, ob die Buttons geladen werden oder das ganze Plugin. Die Buttons werden in einer "Vordatei" definiert, die dann wiederum das eigentliche Plugin aufruft. Daher kann das umbenennen schon ein Grund sein, aber ich verlege dann mal meine Umgebung weg von XAMPP auf einen Server.

Gruß Michael

[Waldschwein]

Hallo!

Leider gibt's immer noch das Problem mit den WB-Plugins... Habe viel rumprobiert, aber bleibe natürlich dran. Habe das Problem aber auch auf einem All-Inkl Server.
Die neueste Version http://github.com/Tenschert/ckeditor/downloads hat eine (völlig) neue include.php, die nun ganz ohne Datenbankabfragen auskommt, aber die gleichen Features hat - danke Luisehahne (der das gemacht hat)!

Gruß Michael

[Stefek]

Hallo,

ich finde es schade, dass die Datei
http://github.com/Tenschert/ckeditor/blob/master/include.php
auf die Konstante DEFAULT_TEMPLATE, statt TEMPLATE_DIR verweist.

Dadurch wird immer die editor.css und editor.styles.js geladen, die sich im Standard Template befindet.
Es kann aber durchaus sein, dass man verschiedene Templates verwendet, die auch wirklich ganz anderes Aussehen haben (Hintergründe, Schriften etc.).

Geht dann zwar leider nur mit einer Datenbankabfrage, aber die erfordert kaum Zeit.

Ich weiß zwar, dass man sich nach der folgenden Aussage hier zwar ducken sollte, aber ich würde es sogar begrüßen, wenn man abhängig von der Blocknummer / page_content() nach Bedarf unterschiedliche css/js ins Template schieben könnte.

Etwa so dann:
 editor.css und editor.styles.js  ^(Standard)
 editor_2.css und editor.styles_2.js ^{(block[2] / page_content(2); )}
 editor_3.css und editor.styles_3.js ^{(block[3] / page_content(3); )}
usw.

Ich weiß, dass ist nichts für Jedermann.
Wahrscheinlich auch zu viel Coden für so ein Feature?


Manchmal kommt es nämlich vor, dass der seitliche (oder jeder) Block völlig anders aussieht als der Hauptblock und da sitzt man mit dem Burschen, der die Eingaben machen soll und versucht ihm zu erklären, dass Contentpflege eine einfache Sache ist 

Ich meine, immerhin gibt WB die eine gute MöglichkeitBlöcke zu verwalten. Für eine einfachere Eingabe, könnte man eine Abhilfe schaffen.

Hat irgendjemand diesen Post nicht verstanden?
(Will nur sichegehen, dass ich mich verständlich ausgedrückt habe.)

Gruß,
Stefek

[Waldschwein]

Hallo!

@Stefek: Du, das müsste Luisehahne oder DarkViper beantworten, ich würde da sowieso nichts richtiges sagen...

Das Problem ist erkannt mit WBDroplets & WBLink Plugin: Es liegt an der Dateiendung. Wenn man die wbdroplets.php in eine wbdroplets.js umbenennt läuft alles fehlerfrei - bis, dass eben der .php Teil nicht ausgeführt wird (und man jetzt in einer .js Datei nicht unbedingt Datenbankabfragen durchführen sollte...)
Also muss man wohl die .php extra auslagern - anders ist das wohl leider nicht möglich.

Gruß Michael

Edit: Hmm, das scheint wohl ein Problem zu sein. Da müsste jemand ran, der PHP und JavaScript zusammenbringen kann. Wenn es hart auf hart kommt müsste man wohl oder übel die PHP über einen XML-Parser aufrufen... Als Notlösung.
Edit #2: Doch der iFrame... http://bestsites.ro/ckeditor-plugins/ Wenn es nicht anders geht, ist das wohl die einzig sinnvolle Alternative. Also die PHP als iFrame einbinden, mit extra HTML. Aber nicht mehr die .htt.

[Luisehahne]

Hi,

es wird mit der include.php die ich Michael zum Testen geschickt habe genauso verfahren, wie Stefek das anregt. Ist das Template in der Seiteneinstellung Standard, wird das DEFAULT genommen, ansonsten das Template was dort eingetragen ist. Musst natürlich nur dafür sorgen das dort auch die css und js vorhanden sind.

Dietmar

P.S.
Wir nutzen einfach mehr die bereits vorhandenen Schnittstellen von WB. Warum das Rad 2 mal erfinden.

[Stefek]

Danke für die Klarstellung, Dietmar.

Hättest Du auch einen Ansatz für die weiter unten in meinem letzten Post angeregte Idee?

Gruß,
Stefek

[Luisehahne]

Hi,

verate mir mal die Nummer der Antwort.Oder meintest du das mit den Blöcken ?

Wenn es das ist, zu aufwendig

Dietmar

[Stefek]

meintest du das mit den Blöcken ?

Ja, genau, das mit den Blöcken.

Ich finde es sehr sinnvoll - kann mir aber vorstellen, dass der Durchschnittsuser, der nicht mal weiß, wie man ein eigenes Template für WB erstellen kann, mit sowas nichts anfangen kann.
Aber dieses Feature ist auch an sich eher für fortgeschrittenere Webdesigner gedacht (das Ganze mit editor.css/.js).

Wenn jetzt gesagt wird: "nee, das wollen wir nicht", dann würde ich mich über einen Lösungsansatz trotzdem freuen, weil ich oft unterschiedliche Blöcke in Templates verwende.

Wäre aber auf jeden Fall ein gutes Feature.
Auch wenn es nicht von jedem verwendet wird - auch James Bond nutzt nicht jede Geheimwaffe, die Mr. Q für ihn entwickelt. 

Gruß,
Stefek

[Waldschwein]

@Blöcke:
Das wäre ein ziemlich großes Ding, das zu verändern denke ich. Letztendlich sollte man in kleinen Schritten dahin kommen, dass das alles flexibler wird - aber wenn man jetzt alles umschmeißt, nur wegen so einem - in Relation zu vielem anderen, was man braucht aber selten sieht - "kleinen" Feature wie der Templates finde ich ist es etwas zu viel des Guten. Wenn, dann auch hier: Entweder ganz oder gar nicht.  Ganz ist sehr umfangreich, gar nicht - naja, halt so wie jetzt.
Aber das hier auszudiskutieren ist Unfug, das ist ein ganz anderes Thema. Dann noch eher: Wie binde ich den CKEditor ins News-Frontendfeld ein (jaja, der sollte im Frontend angezeigt werden, wäre gut, wenn das mal jemand nachprüfen könnte).

Gruß Michael