CKEditor 3.3.1 / pgrfilemanager

Hallo zusammen,
nachdem der FCK Editor nicht mehr weiter entwickelt wird, habe ich mir den Nachfolger CK Editor (3.3.1) angesehen und ein entsprechendes Modul erstellt.
Problem ist, dass der Filemanager jetzt nicht mehr unter GPL steht, so dass ich nach einer Alternative gesucht habe.
Hier habe ich den freien pgrfilemanager als Plugin eingefügt. Nachteil ist, dass er nicht die gleiche Struktur für den Dateiupload (out/fck_[picture|file|flash|media]/) benutzt sondern von [B]einem[/B] Verzeichnis ausgeht. Um zum alten FCK kompatibel zu bleiben, müsste man entweder
[ul]
[li]/out/ als (Datei-)Root - Verzeichnis setzen (keine gute Idee),
[/li][/ul]
[ul]
[li]mit (Soft-)Links auf die alten Folder arbeiten oder
[/li][/ul]
[ul]
[li]das Modul ändern (beste Alternative, mal sehen …)
[/li][/ul]

Ich habe bisher nur unter Linux (Linux / Firefox) getestet und hier scheint es problemlos zu funktionieren.
Wäre nett wenn jemand das Modul unter einem anderen System / Browser testen könnte und mir Rückmeldung gibt. Dann würde ich das Modul entsprechend überarbeiten und auf Exchange zur Verfügung stellen.

Die aktuelle Version des Moduls kann [B]hier[/B] heruntergeladen werden.

Schönen Gruß
Helmut

Hallo Helmut,

Du kannst das Modul gern als Projekt anlegen
http://projects.oxidforge.org

und dann entsprechend Leute einladen, die beim Entwickeln im eigenen SVN mithelfen.

Gruß

Hallo Marco,

[QUOTE=Marco Steinhaeuser;35602]Hallo Helmut,
Du kannst das Modul gern als Projekt anlegen
http://projects.oxidforge.org
und dann entsprechend Leute einladen, die beim Entwickeln im eigenen SVN mithelfen.
Gruß[/QUOTE]
Danke für die Rückmeldung - werde ich machen.
Bin gerade ziemlich dicht und kurz vor Urlaub :wink: deshalb weiß ich noch ob ich es vorher noch schaffe, zumal ich noch ein paar Änderungen machen wollte.
Werde hier Bescheid geben, wenn ich das Projekt angelegt habe.
Gruß
Helmut

[QUOTE=h.rieth;35824]Hallo Marco,

Danke für die Rückmeldung - werde ich machen.
Bin gerade ziemlich dicht und kurz vor Urlaub :wink: deshalb weiß ich noch ob ich es vorher noch schaffe, zumal ich noch ein paar Änderungen machen wollte.
Werde hier Bescheid geben, wenn ich das Projekt angelegt habe.
Gruß
Helmut[/QUOTE]

kurz und knapp: wird das projekt noch verfolgt und wenn ja für welche versionen (ck und oxid) ?

Hallo Volker,
kurz und knapp: von mir nicht da ich aktuell voll ausgelastet bin. Es darf sich aber jeder gerne bedienen und weiter basteln … :wink:
Gruss
Helmut

Moin,

ich finde, ich könnte auch an dieser Stelle nochmal kurz auf mein neues Modul aufmerksam machen, welches den CKEditor in Verbindung mit dem KCFinder nahezu reibungslos ins OXID-Backend integriert. Siehe dazu auch diesen Thread: http://www.oxid-esales.com/forum/showthread.php?t=13096
Oder die Modulbeschreibung: http://www.oxid-esales.com/en/exchange/extensions/wendnet-ckeditor-incl-kcfinder-oxid

Gruß Sascha

Hallo zusammen,
hm, so ein Zufall. Aufgrund eines Redesigns für einen Kunden habe ich letzte Woche nochmal den Editor bearbeitet:
[ul]
[li]CKEditor Version 3.6.2[/li][li]FCKeditor 2.6.6[/li][/ul]

[ul]
[li]kein Quickupload[/li][li]Speichern über Formular-Button (aber ohne Check des Formular-Buttons)[/li][li]Bild / Medienpfade bleiben gleich[/li][li][B]Umschaltung zu Plaintext[/B] (muss dann da gespeichert werden. Keine Textsynchronisation beim Zurück-/Umschalten!)[/li][/ul]

Es ging dem Kunden vor allem um Letzteres. Läuft auf einem Debian Server, nicht unter Windows Server getestet.

Kann hier runtergeladen werden.

Gruss
Helmut

Moin Helmut,

prima, da wandeln wir ja quasi doch noch auf denselben Pfaden… :wink:
Habe dein Modul auch kurz mal getestet, weil ich nicht verstanden habe, was du damit sagen wolltest:

    CKEditor Version 3.6.2
    FCKeditor 2.6.6

Beides geht ja schlecht, also entweder oder? Scheinbar hast du den CKE mit dem Bildbrowser des FCKs verheiratet, richtig? Das klappt aber bei mir nicht:

The requested URL /admin/ckeditor/filemanager/browser/default/browser.html was not found on this server.

Die Frage ist aber vor allem warum du es damit versuchst? Das Teil war doch immer wirklich grottenschlecht! Ich kann echt nur die Verbindung mit dem KCFinder empfehlen, das sind Welten, von der Bedienung (Ajax) bis zur Funktionalität (löschen, kopieren, umbennen, usw.)!

Weiterhin:

kein Quickupload

wieso, ist doch praktisch (wenn korrekt konfiguriert)!?

Speichern über Formular-Button (aber ohne Check des Formular-Buttons)

Kapiere ich nicht ganz, der Formular-Check kann durchaus wichtig sein, z.b. bei Artikeln, wo man ja nicht aus Versehen welche ohne Titel anlegen möchte.

Umschaltung zu Plaintext (muss dann da gespeichert werden. Keine Textsynchronisation beim Zurück-/Umschalten!)

Auch hier erschließt sich mir der Sinn nicht wirklich. Wo wäre denn der Vorteil gegenüber dem normalen Source-Mode? Außerdem scheint es in deinem Modul nicht gut zu funktionieren, z.b. bei Kategorien überlappt sich dann der Text komisch und das Textfeld wird dann viel zu klein. :wink:

Der letzte Punkt ist aber ein ganz [B]wesentlicher[/B]:
Standardmäßig sperrt der CKE nämlich das Speichern im Source-Mode, was ich anfangs ungewohnt und somit blöd fand. Später habe ich es dann verstanden: Wenn man nämlich im Source-Mode speichert, wird der Inhalt vorher eben NICHT mehr durch den HTML-Dataprocessor gejagt, sondern unverändert gespeichert. Das bedeutet aber, dass jeder Fehler, den ich dort beabsichtigt oder unbeabsichtigt einbaue, später gandenlos im Frontend angezeigt wird. Also bin ich den anderen Weg gegangen, und lasse ALLE submit-Buttons komplett sperren, wenn man im Source-Mode ist. Das ist der einzig konsequente Weg, um die HTML-Bereinung komplett CKE zu überlassen (dafür ist er ja da!), und genau die habe ich an einigen Stellen auch noch optimiert.

Wenn man nicht zufrieden ist mit dem CKE-Output, dann muss man dessen Interna optimieren, und wenn das auch nicht reicht, ist es evtl. einfach der falsche Editor für einen. So sehe ich es jedenfalls… :wink:

Hallo Mitmacher,

FCKeditor 2.6.6:
Beides geht ja schlecht, also entweder oder? Scheinbar hast du den CKE mit dem Bildbrowser des FCKs verheiratet, richtig?

Klar, sollte natürlich Filebrowser des FCKeditor 2.6.6 heissen.

Das klappt aber bei mir nicht:

The requested URL /admin/ckeditor/filemanager/browser/default/browser.html was not found on this server.

Hast Du mal nachgesehen warum? Die Datei sollte eigentlich am richtigen Ort sein, zumindest bei einer Standardinstallation.

Die Frage ist aber vor allem warum du es damit versuchst? Das Teil war doch immer wirklich grottenschlecht! Ich kann echt nur die Verbindung mit dem KCFinder empfehlen, das sind Welten, von der Bedienung (Ajax) bis zur Funktionalität (löschen, kopieren, umbennen, usw.)!

Ist mir klar. Ging um eine schnelle Lösung für den Kunden und dafür ist der ok, bzw. zumindest besser als der alte.

Weiterhin:

kein Quickupload

wieso, ist doch praktisch (wenn korrekt konfiguriert)!?

War für den Kunden nicht interessant, wäre aber keine grosse Sache die Skripte und Feldnamen anzupassen.

Speichern über Formular-Button (aber ohne Check des Formular-Buttons)

Kapiere ich nicht ganz, der Formular-Check kann durchaus wichtig sein, z.b. bei Artikeln, wo man ja nicht aus Versehen welche ohne Titel anlegen möchte.

War im ersten Schritt ebenfalls für den Kunden noch nicht von Interesse. Kommt im nächsten Step.

Umschaltung zu Plaintext (muss dann da gespeichert werden. Keine Textsynchronisation beim Zurück-/Umschalten!)

Auch hier erschließt sich mir der Sinn nicht wirklich. Wo wäre denn der Vorteil gegenüber dem normalen Source-Mode? Außerdem scheint es in deinem Modul nicht gut zu funktionieren, z.b. bei Kategorien überlappt sich dann der Text komisch und das Textfeld wird dann viel zu klein. :wink:

Der letzte Punkt ist aber ein ganz wesentlicher:
Standardmäßig sperrt der CKE nämlich das Speichern im Source-Mode, was ich anfangs ungewohnt und somit blöd fand. Später habe ich es dann verstanden: Wenn man nämlich im Source-Mode speichert, wird der Inhalt vorher eben NICHT mehr durch den HTML-Dataprocessor gejagt, sondern unverändert gespeichert. Das bedeutet aber, dass jeder Fehler, den ich dort beabsichtigt oder unbeabsichtigt einbaue, später gandenlos im Frontend angezeigt wird. Also bin ich den anderen Weg gegangen, und lasse ALLE submit-Buttons komplett sperren, wenn man im Source-Mode ist. Das ist der einzig konsequente Weg, um die HTML-Bereinung komplett CKE zu überlassen (dafür ist er ja da!), und genau die habe ich an einigen Stellen auch noch optimiert.

Wenn man nicht zufrieden ist mit dem CKE-Output, dann muss man dessen Interna optimieren, und wenn das auch nicht reicht, ist es evtl. einfach der falsche Editor für einen. So sehe ich es jedenfalls… :wink:

Soweit ich sehe, ersetzt der Editor wenn man im Sourcecode Modus speichert alle Sonderzeichen und umgibt den Code mit einem p Tag.
Und genau das soll hier verhindert werden, nämlich dann, wenn man z.B. die Plaintext - Mailtexte editieren möchte. Hier darf der Text eben gerade nicht durch den Dataprozessor. Nur manche Programmierer scheinen sich keinen Plain-Mailtext mehr anzusehen und wundern sich, wenn sich Kunden oder deren Kunden über komische Mails beschweren … so sehe ich das :wink:
Gruss
Helmut

Hey,

Klar, sollte natürlich Filebrowser des FCKeditor 2.6.6 heissen.

okido :slight_smile:

Hast Du mal nachgesehen warum? Die Datei sollte eigentlich am richtigen Ort sein, zumindest bei einer Standardinstallation.

Hat mich ja auch gewundert, da die Datei schon dort war. Aber eben habe ich es geschnallt, es lag an meinem Test-Setup mit SSL-Proxy, wo dann eine andere Docroot zum Tragen kommt. Ist ein Thema für sich und findet sich bereits in meinem Modul-Thread. Kann man dir also nicht unbedingt anlasten, obwohl dies mein Modul z.b. bereits berücksichtigt.

Soweit ich sehe, ersetzt der Editor wenn man im Sourcecode Modus speichert alle Sonderzeichen und umgibt den Code mit einem p Tag.
Und genau das soll hier verhindert werden, nämlich dann, wenn man z.B. die Plaintext - Mailtexte editieren möchte. Hier darf der Text eben gerade nicht durch den Dataprozessor. Nur manche Programmierer scheinen sich keinen Plain-Mailtext mehr anzusehen und wundern sich, wenn sich Kunden oder deren Kunden über komische Mails beschweren … so sehe ich das

Sei beruhigt, mir ist sowas schon recht wichtig und genau deswegen fahre ich den CKE für OXID im <br>-Modus (statt <p>) und sage per config:

config.entities = false;

Das klappt dann schon ganz gut, wenn auch nicht immer perfekt… :wink:
Aber auch Newsletter sind wiederum ein Thema für sich und überhaupt, man kann und muss wohl festhalten, dass es einfach derart viele Arten gibt, CKE zu konfigurieren, dass es niemals eine Lösung für alle geben wird. Man kann als Programmierer nur versuchen, den Kunden eine gewisse Marschrichtung vorzugeben.

Ich finde es z.b. mehr als sinnvoll, im Editor keine Schriften und Farben frei wählen zu können, sondern alles einheitlich für den jeweiligen Shop zu gestalten und CKE anzupassen (contents.css + styles.js). Aber auch dazu wird es andere Meinungen geben.
Wie auch immer, es gibt, wie so oft, mehrere Wege nach Rom, und es muss jeder selbst entscheiden, welchen er nimmt. hugh :wink:

Hallo,

Hat mich ja auch gewundert, da die Datei schon dort war. Aber eben habe ich es geschnallt, es lag an meinem Test-Setup mit SSL-Proxy, wo dann eine andere Docroot zum Tragen kommt. Ist ein Thema für sich und findet sich bereits in meinem Modul-Thread. Kann man dir also nicht unbedingt anlasten, obwohl dies mein Modul z.b. bereits berücksichtigt.

Das Teil ist ja noch nicht fertig sondern sollte auf die schnelle ein paar Probleme beheben (besonders die Plaintext Mails). Aber für Standardinstallationen sollte es funktionieren, bzw. wie in der README angegeben kann man natürlich die Pfade ändern.

Vielleicht schaue ich mir ja auch noch mal den den KCFinder an. Leider erinnere ich mich nicht mehr, warum ich den bei der früheren Version verworfen hatte …

Ich finde es z.b. mehr als sinnvoll, im Editor keine Schriften und Farben frei wählen zu können, sondern alles einheitlich für den jeweiligen Shop zu gestalten und CKE anzupassen (contents.css + styles.js).

Da stimme ich dir auf jeden Fall zu. Auch wenn das bei manchen Kunden größere Überzeugungsarbeit ist … :wink:

Schönen Gruss
Helmut

[QUOTE=h.rieth;80274]
Soweit ich sehe, ersetzt der Editor wenn man im Sourcecode Modus speichert alle Sonderzeichen und umgibt den Code mit einem p Tag.
[B]Und genau das soll hier verhindert werden[/B], nämlich dann, wenn man z.B. die Plaintext - Mailtexte editieren möchte. Hier darf der Text eben gerade nicht durch den Dataprozessor. Nur manche Programmierer scheinen sich keinen Plain-Mailtext mehr anzusehen und wundern sich, wenn sich Kunden oder deren Kunden über komische Mails beschweren … so sehe ich das ;)[/QUOTE]
Plaintext-Texte sind natürlich der absolute Spezialfall; im Normalfall ist es völlig ok, Texte durch Absatztags zu gliedern. Für diesen Spezialfall kann man ja Opera benutzen und Javascript ausschalten…
BTW Meiner Meinung nach interessiert sich kein Mensch mehr heutzutage für die Plaintext-Mailtexte, da jeder Emailclient html-Mails anzeigen kann. Der outlookbedienende ONU weiss gar nicht, dass so etwas überhaupt existiert. Diese Funktionalität in Oxid ist eigentlich überflüssig geworden, oder gibt es dafür tatsächlich noch Bedarf?

Da musste ich doch ONU tatsächlich bei Google nachschlagen… Immer diese Fremdwörter… :smiley:

BTW Meiner Meinung nach interessiert sich kein Mensch mehr heutzutage für die Plaintext-Mailtexte, da jeder Emailclient html-Mails anzeigen kann. Der outlookbedienende ONU weiss gar nicht, dass so etwas überhaupt existiert. Diese Funktionalität in OXID ist eigentlich überflüssig geworden, oder gibt es dafür tatsächlich noch Bedarf?

Menschen vielleicht (hier würde ich mich international gesehen nicht aus dem Fenster hängen wollen) nicht, aber Firmen zumindest teilweise. Die IT von zwei meiner größeren Kunden verlangt auf jeden Fall immer einen entsprechenden sauberen Plaintext. Insofern: kommt drauf an.

Gruss
Helmut

Also, ich persönlich bin da auch eher oldschool-orientiert, und lese standardmäßig meine Mails alle erstmal “plain” (mit Thunderbird). Bei Bedarf (selten) schaue ich dann mal ins HTML (allow html temp addon), aber natürlich ohne externe Bilder. Und ich freue mich über jede korrekt formatierte Mail und bin belustigt über ü-Ansammlungen. Ist nicht ganz state-of-the-art, I kow, aber funktioniert seit Ewigkeiten völlig ausreichend, und ich weiß, ich bin nicht alleine… :smiley:

btw: ONU = Optical Network Unit? hm.

Moin zusammen,

stimmt nur zum Teil… ONU-Erklärungen gibtshier:smiley:

[QUOTE=Mitmacher;80290]ONU = Optical Network Unit? hm.[/QUOTE]

ONU = Otto Normal User

ach - der DAU?

[QUOTE=h.rieth;80284]Die IT von zwei meiner größeren Kunden verlangt auf jeden Fall immer einen entsprechenden sauberen Plaintext. Insofern: kommt drauf an.[/QUOTE]
Interessant. D.h. wenn also etwas ohne Plaintext ankommt, wird es automatisch als Spam klassifiziert? Da könnte ja mal glatt ein neuer Auftrag auf diese Weise verschwinden…

[QUOTE=Hebsacker;80319]ach - der DAU?[/QUOTE]

Nein, auf gar keinen Fall. DAU ist ja immer der dümmste User. ONU möchte einfach nur seinen Rechner möglichst zweckmäßig bedienen. Auch wenn ich mich nicht gerade als ONU titulieren möchte, bin ich im Fall der html-Mails mittlerweile einer geworden. Früher haben sie mich noch extrem gestört, heute interessiert es mich nicht mehr die Bohne.