CKEditor Full package - Githubissues

s9y / Serendipity

A PHP blog software

https://s9y.org

BSD 3-Clause "New" or "Revised" License

207 stars 88 forks source link

CKEditor Full package #148

Closed garvinhicking closed 9 years ago

garvinhicking commented 10 years ago

Use ckeditor full package to allow easier user customization

garvinhicking commented 10 years ago

Allow to switch within htmlarea/ckeditor_custom_config.js

garvinhicking commented 10 years ago

Make sure it is properly coded in wysiwyg_init.tpl so that the file does not neet to be touched, and the user only edits htmlarea/ckeditor_custom_config.js

garvinhicking commented 10 years ago

Check how to provide other plugin hooks (mediaembed, linktrimmer et all) easily within the CKEditor.

onli commented 10 years ago

@garvinhicking @ophian I'm not actually sure how to switch the toolbar (or make it configurable) in ckeditor_custom_config.js. How to handle serendiptiy-plugins? What do users gain by being able to modify the toolbar there, instead of in https://github.com/s9y/Serendipity/blob/2.0/templates/2k11/admin/wysiwyg_init.tpl ?

PS: I will desassign me for now. I think with the inclusion of the full editor and the button-api in #147 this is enough. Correct me if wrong.

ophian commented 10 years ago

I am still not sure being friend with this composer stuff.... and will ever be.

If I get this right, it tells me that from now on, on install and or upgrade, a internal routine checks automatically for new updates of the ckeditor package to include it to htmlarea/ckeditor/ckeditor. Is that right? So this happens without a maintainer and just on time? How do you prevent including the samples directory and the build file being installed too. How do you prevent this bleeding edge version does not change anything essentiell to work with S9y? I also saw you doubled ckeditor_custom_config.js, ckeditor_custom_plugin.js and wysiwyg-style.css files into htmlarea/ckeditor/. Is that by accident or a need?

The other questions may be answered after this was cleared and I had a test with it.

onli commented 10 years ago

on install and or upgrade, a internal routine checks automatically for new updates of the ckeditor package to include it to htmlarea/ckeditor/ckeditor

Not automatically. A maintainer has to execute the htmlarea/composer.phar

How do you prevent including the samples directory and the build file being installed too.

Are they included right now? If yes, they have to be deleted afterwards. That needs to be wrapped in a script then.

How do you prevent this bleeding edge version does not change anything essentiell to work with S9y?

Not at all, apart from that it is not totally automatic. But, it is set to ckeditor 4 (correction: set to the latest stable correction2: no, i messed up there, should be set to that though), so that shouldn't happen too fast. And the whole idea is to not use old, unmaintained (and therefore probable insecure) software.

I also saw you doubled ckeditor_custom_config.js, ckeditor_custom_plugin.js and wysiwyg-style.css files into htmlarea/ckeditor/. Is that by accident or a need?

Accident. They should be stored in htmlarea/ckeditor/ only.

Please test it. If there are still composer-questions -> forum.

PS: @garvinhicking What we could do is to include a configuration-option to use the full ckeditor-toolbar by choice.

PPS: I might actually be wrong with it being not automatic, it could be set it is github-linked, if something like that exists? That is new to me, thanks for pointing that out. Might be that I didn't do what I wanted there, I'll have a look. But that shouldn't change anything with the serendipity-integration on the code side, so please have a look at that anyway

garvinhicking commented 10 years ago

Sidenote:

I think we should copy the contents of ckeditor_config_custom.js to ckeditor_config_default.js, and then in that file tell the users to make modifications in a ckeditor_config_custom.js file.

This way, when people upgrade serendipity their custom file will not get overwritten since it's not part of the distro. The PHP/JS code then need to check if that file exists and then either ust custom config or default config, or we simply first always load default JS, and then load the custom file on top of that?

yellowled commented 10 years ago

In a current 2.0 snapshot (dad4e4cfc9e0f7c8d81b6f2cbb43794aef5a432e), CKEditor is broken.

Failed to load resource: the server responded with a status of 404 (Not found) http://domain.tld/htmlarea/ckeditor/ckeditor/ckeditor.js
Uncaught ReferenceError: CKEDITOR is not defined serendipity_admin.php?serendipity[adminModule]=entries&serendipity[adminAction]=new:758

ophian commented 10 years ago

That is while there isn't any Ckeditor lib anymore. https://github.com/s9y/Serendipity/tree/2.0/htmlarea/ckeditor and one of the bad things we already have discussed using this composer. If it isn't there physically, a current Github snapshot will not suffice. Even if I don't agree with that doubled ckeditor directory, I am glad this issue shows up now. If onli would have left the previous path as is, nobody updating the beta with a current snapshot would have noticed. I remember we agreed, to always leave a current copy, so that github checkouts do work without having anyone to learn composer checkouts, and now it came in through the backdoor. :disappointed: assign @garvinhicking

garvinhicking commented 10 years ago

Let's just talk about this without agression please.

I'm sure this was not intentional by @onli and it can easily be changed to put ckeditor physically into the github again, as was intended.

onli commented 10 years ago

Yep, not intentional - I don't actually know how you can create such a link.

onli commented 10 years ago

Can this be closed?

garvinhicking commented 10 years ago

@ophian can you check if the unintentionall changes are properly adressed, and we can close this?

yellowled commented 10 years ago

Why is this still open?

onli commented 10 years ago

The requester of this change didn't confirm the result. Closing now.

ophian commented 10 years ago

I won't comment on this unnecessary kick ...

@ophian can you check if the unintentionall changes are properly adressed, and we can close this?

[x] Use ckeditor full package to allow easier user customization

[ ] If sticking to composer in future it needs a maintainer. I am out in this case. (*)

[x] Allow to switch toolbars within htmlarea/ckeditor_custom_config.js easily

[x] Make sure it is properly coded in wysiwyg_init.tpl, so that the file does not need to get touched, and the user only edits htmlarea/ckeditor_custom_config.js, or an even better independent file

[x] Integrate all these special additions and plugins, which were introduced to CKE for S9Y extending features

[x] Check how to provide other s9y plugin hooks (mediaembed, linktrimmer et all) easily within the CKEditor.

on my behalf the composer placement needs to be redone, since it doubles ckeditor directory, places unnecessary file and dirs and avoids me to maintain it, which is kind of sad.

I even had a suggestion for all this quite a long time now, but waited for a discussion on WEB-Talk. Every further commit until then is making it harder.

garvinhicking commented 10 years ago

This is IMO the most crucial thing left for a 2.0 release. What can we do to get our bearings straight in this matter, without resorting to "he said-she said" pointing? :-)

We need a way so that people can configure the core CKEDitor. They need a way to create an update-safe configuration somewhere (through a htmlarea/ckeditor_custom_config.js or whatever), which would be picked up by the core CKEditor so that the customized toolbars for users will be shown according to their preference.

Two more things are important for this:

External plugins need to be able to add themselves to the configuration somewhow
All this CKEditor instancing should ideally not be part of the template, but rather be done in serendipity_editor.js.tpl in the JS-only scope.

Did I forget something? Paging @ophian and @onli :)

onli commented 10 years ago

Ok @garvinhicking. I provided a in my eyes sane solution in https://github.com/s9y/Serendipity/commit/f7da64165d29dd393135593d0ae42e3568fa7c00. Please see the commit message there, but the gist is that we now have our own ckeditor-upgrade safe default config AND an s9y-upgrade safe userconfig that can overwrite everything, that using toolbarGroups solved the issue with the dynamic plugin generation (they can stay in wysiwyg_init.tpl) and the toolbar is still as small as I want her to be, but can be extended if the user really wants to.

I did not add anything in serendipity_editor.js.tpl, because I disagree with that - wysiwyg_init.tpl is an useful separation right now, and serendipity_editor.js.tplalready too big. But it sure would be possible to make that change if you really want to, somehow, we just would have to init the editor completely different. I really don't want to do this now.

In future versions we probably want to supply basic configuration options for the editor in our backend, and not by configuration of text files. But this is definitely out of 2.0 scope, and until then, I think the latest commit will work nicely (and is absolutely compatible with such a plan).

Please have a look, and I hope this can be closed soon :)

onli commented 10 years ago

@ophian, @garvinhicking ?

yellowled commented 9 years ago

Shouldn't we move this over to Stable or even Future? I know we're still waiting on an example from @ophian, but in general, CKE seems to be working fine in 2.0, so it shouldn't be a release blocker …?

onli commented 9 years ago

It can't be for stable. Either this now is the solution for 2.0, or it has to be changed for the RC, the possible changes would be too significant.

But of course, my wish is to have this closed or at least moved to future - if there are really issues with the current solution, of which I still saw nothing - and start 2.0 with the current solution.

ophian commented 9 years ago

I know we're still waiting on an example from @ophian, but in general, CKE seems to be working fine in 2.0, …

Basic wysiwyg conversions is not the issue we are talking about...

I don't think anyone waits for an example. Saying so implements, I was not offering solutions all the time. I have commited, talked and wrote serveral times about the issues I see, and which need some fixes and coverages at all, here and there. This needs the willingness to change certain structures like they are. Since this wasn't given, I gave up my inner responsibility for this at some point.

I mainly have three objects of concernment.

In very short: This are all kinds of ACF (Advanced Content Filter) issues in combination with special Serendipity needs. For examples (just a few): Media Insert Galleries markup, Media Library image placement markup, placeholders and excludes, etc.
The other issues preventing me to take care are: Composer and doubled directory, Composer and the included examples directory (which is accessible by outside, but I did not check possible security flaws), and the question, why to stick to composer structure, if no one takes really care obout it? If building certain structures you have to take care in my eyes!
The third section is about how to build toolbars. I think it is better to have them selectable for unadvanced users without the need to touch files by hand and use a custom config/plugin handmade individualization templatewise for the ones wanting to finetune their personal needs more than that.

All this and more is covered in a solution build by the advanced experiences I have made with the CKE Plugin over all the time. I can offer this all-in-one-solution-and-experience, or not.

You can test this by youself in 2.0 with the current structure of core CKE and the advanced possibilities of the CKE Plugin for these special needs, which shows what would be able with my offered solution.

~~+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++~~

Wie beim DEV-Talk besprochen, werde ich also noch einmal meine Punkte für den Core CKEDITOR auflisten. Wie gewünscht auf Deutsch.

Ich habe lange darüber nachgedacht, wie und ob ich der "Aufgabe/Zumutung" nachkommen kann oder sollte, zu erklären, was im Speziellen mit dieser von Malte durchzusetzenden Variante nicht möglich ist.

Ich habe anderthalb Jahre Erfahrung in der Konzeption von CKE unter S9y sammeln können.

Dies betrifft eben auch die Eigenheiten von Serendipity und seinen Plugins, siehe mediainsert galleries als Beispiel, bzw spezielles Serendipity (MediaLibrary) Markup und den CKEDITOR eigenen Advanced Content Filter, kurz ACF, zb bei MediaLibrary Einfügungen und den internen ACF Veränderungen des Markups bei übergroßen Bildern und den Auswirkungen im Frontend, etc.

All das hat zu bestimmten miteinander verzahnten Lösungen im Serendipity CKE Plugin geführt, die ich auch für den Core WYSIWYG Editor anbieten kann. Zwei derartige erste Versuche wurden vor längerer Zeit aber einfach zurückgesetzt, ohne umfassende Alternativen anzubieten.

Meine Schwierigkeiten mit der jetzigen Konfiguration liegen darin, dass diese eine bestimmte (subjektive) Grundkonfiguration festschreiben will, die ich von meiner Seite so nicht supporten will. Anders kann ich u.a. auch eine Äußerung wie: "...the toolbar is still as small as I want her to be,..." nicht deuten.

Dazu kommen - ich sage dazu einmal - „Kleinigkeiten“, die mich (zwar immer noch) stören, die aber einer Lösung nicht wirklich im Wege stünden, sollten sie aus mir nicht nachvollziehbaren Gründen dennoch so von allen so gewünscht sein. Allein Maltes subjektiver Wunsch erklärt mir noch keine Notwendigkeit! Dies sind das doppelte ckeditor/ Verzeichnis durch den für mich immer noch unsinnigen composer und die aufwendige inline Smarty Lösung über die wysiwyg_init.tpl, die vieles unnötigerweise zwei mal durch Smarty und PHP parsen lässt. Beides hätte wesentlich kompakter gestaltet werden können.

Was mir an dieser Sache insgesamt aufstößt, ist die merkwürdige Beharrung Maltes auf bestimmten (seiner) Vorgaben und die gleichzeitige Interesselosigkeit, anders kann ich es nicht deuten, die sich darin ausdrückt, dass das so angeblich super einfache composing nicht dazu geführt hat, das CKE in all den vielen Monaten seit dem ersten commit auch nur ein Mal gepflegt worden wäre. Was angesichts von security fixes und anderen wichtigen Verbesserungen aber durchaus nötig gewesen wäre.

Nun gut! […] Ich habe also eine derartige Lösung vorliegen, die im Großen und Ganzen diese Konfiguration beibehält, aber folgendes erweiternd ermöglicht:

Der User kann aus 3 per default angebotenen Toolbars (Basic/Standard/Full), einfach per "Eigene Einstellungen" wählen, ohne irgendeine Datei per Hand anfassen zu müssen. Gerade mit letzterem wären eine Menge User schlichtweg zufrieden, nehme ich an. Zusätzlich gibt es noch die Preset (also die default Full toolbar) als fallback und eine interne libeigene Fallback Toolbar, wenn Fehler auftreten. Natürlich sind nicht alle toolbar Möglichkeiten per default aktiviert, wie zb die form Elemente für textareas, die in unserem Umfeld unsinnig sind.

Für denjenigen, dem dies als Individualisierung noch nicht genügt, kann zusätzlich und updatesicher eine Template eigene config und plugin js als eigene Kopie geführt werden, in der die jeweilige CKEDITOR config mit all ihren zusätzlichen Einstellungen ganz individuell eingestellt werden kann und eigene Anpassungen für CKEDITOR-Plugins und interne Verbesserungen für das Verhältnis von S9y-Plugins und ACF vorgenommen werden können. In der Plugin,js werden zb die per default hinzugefügten CKE Serendipity Plugins zusammengeschraubt und eine paar weitere wichtige Korrekturen vorgenommen.

Die custom_ckeditor_config.js und custom_ckeditor_plugin.js lägen also unter templates/2k11/admin/custom/ oder meinTemplate/admin/custom/ (und das ohne das backend fallback zu stören). Unter „Eigene Einstellungen“ gäbe es ein Auswahlfeld für die preset Toolbars und in der wysiwyg_init müssten nur ein paar kleine Additions hinein, welche die js Arrays für die spätere Auswertung in der config bereitstellen. In der function_smarty kämen nur 3 neue Smarty-Variablen und die Erlaubnis für die /admin/custom/ Geschichte hinzu, so dass sich die custom und plugin js sogar auch nur einzeln individualisieren ließe.

Damit erlaubt man eine unter eigener Verantwortung erstellte individuelle Konfiguration, in den dafür vorgesehenen Dateien und nicht als Appendix zu einer bestehenden Config! Und dieser letzte Punkt ist wichtig! Meine Tests, die ich hier nicht mehr alle repetieren kann, haben genau zu dieser Lösung geführt, da schon kleinste Änderungen im Gefüge, vorher Mögliches, plötzlich unmöglich machten. Als Beispiel die Einbindung von weiteren CKEDITOR Plugins über die Custom "Build your own version" function auf der cke Webseite. Obwohl nur etwas anders eingebunden, hatte dies zB gravierende Auswirkungen auf die Art und Weise wie Toolbars in einer custom config gebildet werden können.

Kurzum, ich habe lange herumprobiert und würde das - wenn - dann nur komplett anbieten und einbauen, ohne dass das im Nachhinein wieder verändert, in Gänze oder Teilen wieder reverted wird. Das ist kein Statement gegen Veränderung oder Verbesserung, sondern nur gegen die Ignoranz detaillierterer Erfahrungen.

Wer sich genauer anschauen will was darin möglich ist, kann sich die letzte Version des CKE Plugins in 2.0 installieren und sich diverse testcases für diese Besonderheiten selber schreiben und dann mit einem current 2.0 build cke vergleichen.

Ich wünschte, wir könnten den bisherigen Plugin Usern anbieten, einen nahtlosen Übergang zu schaffen, ohne sagen zu müssen: "bleibe lieber beim Plugin", weil das core CKE nur eine Art von Grundkonfiguration vorsieht, die auf Serendipity Spezialitäten keine Rücksicht nimmt.

onli commented 9 years ago

Kurzum, ich habe lange herumprobiert und würde das - wenn - dann nur komplett anbieten und einbauen, ohne dass das im Nachhinein wieder verändert, in Gänze oder Teilen wieder reverted wird.

Ok, dann nein. Lass uns nicht drum streiten, aber auf der Grundlage will ich nicht.

Ich nehme aus deinem Post mit, dass man den

[ ] ACF konfigurieren oder deaktivieren muss (falls ich da die Probleme finde),
[x] dass CKeditor geupdatet werden muss (was per composer einfach ist),
[ ] und dass man für später über eine in s9y konfigurierbare toolbar nachdenken sollte (wovon ich nicht überzeugt bin).

Danke für die Rückmeldung.

I'll have a look at the first two points for the RC and then close here.

yellowled commented 9 years ago

If you guys are going to fight over anything, please be so kind to do that via email.

onli commented 9 years ago

Hey, I just wrote "Let's not fight". Neither here nor via mail!

ophian commented 9 years ago

Ok, dann nein. Lass uns nicht drum streiten, aber auf der Grundlage will ich nicht.

Genau damit maßt du dir aber ein Recht an, das du meines Erachtens nicht hast! Und entsprichst damit - auch in der bewußten Verkürzung des Verstandenen - genau einem der zentralen Punkte meiner bisherigen Kritik. Ich finde, wir sollten die EGOs da raus lassen und uns nur als Developer eines Miteinanders sehen: Die Entscheidung für die eine oder andere Weiche obliegt allein dem Hauptverantwortlichen, und das ist Garvin.

garvinhicking commented 9 years ago

Hey, nur kurz einklinken: Ich werde mir deinen ausführlichen Bericht in Ruhe durchlesen wollen und auch gerne Feedback dazu geben, aber: Ich sehe mich nicht als weichenstellender Despot, sondern möchte das grundsätzlich schon gerne als Teamentscheidung sehen. Einzelentscheidungen in die eine oder andere Richtung sind mir immer ein graus, und ich denke wir können das schon sinnvoll diskutieren.

Das kurze Überfliegen lässt mich vermuten, dass die hohe Konfigurierbarkeit aber wirklich eher von einem Plugin als vom Kern geleistet werden sollte im CKEditor, allein weil das abbilden der Konfigurationsmöglichkeiten in der zentralen Konfiguration aus meiner Sicht sehr viel Aufwand wäre und später nicht so leicht zu aktualisieren wie durch ein gekapseltes Plugin, dass solche Möglichkeiten schon bietet. Hier müssen wir wirklich abwägen, was später auch die Features von einem separaten Plugin sind.

Optimal aus meiner Sicht wäre z.b. dass das CKEditor-Plugin nur Konfigurationsfeatures und Updatemölighckieten des CKEditor-Cores mitbringt, und alle Variablen udn Konfigurationen im Core vornehmen könnte. Aber dazu mehr, wenn ich deinen Bericht ausführlich gelesen habe.

Wie auch immer, ich denke wir kriegen das schon gütlich gelöst, an so einer Sache sollten wir nicht scheitern. :-)

LG, Garvin

On 12.11.2014 17:34 , Ian wrote:

Ok, dann nein. Lass uns nicht drum streiten, aber auf der Grundlage
will ich nicht.
Genau damit maßt du dir aber ein Recht an, das du meines Erachtens nicht hast! Und entsprichst damit - auch in der bewußten Verkürzung des Verstandenen - genau einem der zentralen Punkte meiner bisherigen Kritik. Ich finde, wir sollten die EGOs da raus lassen und uns nur als Developer eines Miteinanders sehen: Die Entscheidung für die eine oder andere Weiche obliegt allein dem Hauptverantwortlichen, und das ist Garvin.

— Reply to this email directly or view it on GitHub https://github.com/s9y/Serendipity/issues/148#issuecomment-62747743.

garvinhicking commented 9 years ago

Hi!

Also ich habe mir das nun mal durchgelesen. Nach wie vor kann ich beide Seiten verstehen; Malte, der gerne eine "schnörkellose Idealversion" vom CKEDitor dem User im Kern geben will und Ian der den Usern gerne "alles" an die Hand geben möchte, mitsamt dedizierter Konfiguration und komplett eigener Anpassung.

Ich denke wir werden da für die Lösung im Kern einfach auf keinen Konsens kommen.

Daher wäre meine Empfehlung folgende:

Das CKEditor-Plugin bleibt bestehen und wird für die User beworben als "Power-User-Einstellmöglichkeit" vom CKEditor. Zudem kann das Plugin als "Spielwiese" für neue CKEditor-Features dienen, das man dann eigenständig auch leichter updaten kann.
Die CKEditor-Integration im Kern inkl. Compuser updatefähigkeit bleibt bestehen, die einfache Config-Anpassung ist die "Simpleton"-Möglichkeit für User, die Instanz zu konfigurieren. Mit dem doppelten Pfad müssen wir dann leben; ich fände es auch schöner wenn das nicht so wäre, aber mittelfristig möchte ich die Composer-Updatefähigkeit von unseren gebündelten Bibliotheken schon gerne nutzen können.
Ian maintained das CKEditor-Plugin, Malte und Garvin maintainen den CKEditor im Core. Dabei wäre es nett dass Du, Ian, uns evtl kurz Bescheid geben kannst wenn es ein relevantes CKEditor-Update gibt das man im Kern auch einspielen müsste (ich glaube da bist Du mehr am Puls als wir). Wir kümmern uns dann um das Update entweder via Composer oder normal per wget die neuen Dateien einzuspielen in den Core.

Können wir uns darauf alle einigen, oder gibt es in einem dieser drei Punkte dann starken Groll? Ich würde hier wirklich gerne einen Kompromiss finden, der keinem auf die Füße fällt und aber beide Bedürfnisse (auch für Benutzer!) abdeckt.

LG, Garvin

On 12.11.2014 11:06 , Ian wrote:

I know we're still waiting on an example from @ophian
<https://github.com/ophian>, but in general, CKE seems to be working
fine in 2.0, …
Basic wysiwyg conversions is not the issue we are talking about...

I don't think anyone waits for an example. Saying so implements, I was not offering solutions all the time. I have commited, talked and wrote serveral times about the issues I see, and which need some fixes and coverages at all, here and there. This needs the willingness to change certain structures like they are. Since this wasn't given, I gave up my inner responsibility for this at some point.
  I mainly have three objects of concernment.
1.
In very short:
This are all kinds of ACF (Advanced Content Filter) issues in
combination with special Serendipity needs.
For examples (just a few): Media Insert Galleries markup, Media
Library image placement markup, placeholders and excludes, etc.
2.
The other issues preventing me to take care are: Composer and
doubled directory, Composer and the included examples directory
(which is accessible by outside, but I did not check possible
security flaws), and the question, why to stick to composer
structure, if no one takes really care obout it? If building certain
structures you have to take care in my eyes!
3.
The third section is about how to build toolbars. I think it is
better to have them selectable for unadvanced users without the need
to touch files by hand and use a custom config/plugin handmade
individualization templatewise for the ones wanting to finetune
their personal needs more than that.
All this and more is covered in a solution build by the advanced experiences I have made with the CKE Plugin over all the time. I can offer this all-in-one-solution-and-experience, or not.

You can test this by youself in 2.0 with the current structure of core CKE and the advanced possibilities of the CKE Plugin for these special needs, which shows what would be able with my offered solution.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Wie beim DEV-Talk besprochen, werde ich also noch einmal meine Punkte für den Core CKEDITOR auflisten. Wie gewünscht auf Deutsch.

Ich habe lange darüber nachgedacht, wie und ob ich der "Aufgabe/Zumutung" nachkommen kann oder sollte, zu erklären, was im Speziellen mit dieser von Malte durchzusetzenden Variante nicht möglich ist.

Ich habe anderthalb Jahre Erfahrung in der Konzeption von CKE unter S9y sammeln können.

Dies betrifft eben auch die Eigenheiten von Serendipity und seinen Plugins, siehe mediainsert galleries als Beispiel, bzw spezielles Serendipity (MediaLibrary) Markup und den CKEDITOR eigenen Advanced Content Filter, kurz ACF, zb bei MediaLibrary Einfügungen und den internen ACF Veränderungen des Markups bei übergroßen Bildern und den Auswirkungen im Frontend, etc.

All das hat zu bestimmten miteinander verzahnten Lösungen im Serendipity CKE Plugin geführt, die ich auch für den Core WYSIWYG Editor anbieten kann. Zwei derartige erste Versuche wurden vor längerer Zeit aber einfach zurückgesetzt, ohne umfassende Alternativen anzubieten.

Meine Schwierigkeiten mit der jetzigen Konfiguration liegen darin, dass diese eine bestimmte (subjektive) Grundkonfiguration festschreiben will, die ich von meiner Seite so nicht supporten will. Anders kann ich u.a. auch eine Äußerung wie: "/...the toolbar is still as small as I want her to be,.../" nicht deuten.

Dazu kommen - ich sage dazu einmal - „Kleinigkeiten“, die mich (zwar immer noch) stören, die aber einer Lösung nicht wirklich im Wege stünden, sollten sie aus mir nicht nachvollziehbaren Gründen dennoch so von allen so gewünscht sein. Allein Maltes subjektiver Wunsch erklärt mir noch keine Notwendigkeit! Dies sind das doppelte ckeditor/ Verzeichnis durch den für mich immer noch unsinnigen composer und die aufwendige inline Smarty Lösung über die wysiwyg_init.tpl, die vieles unnötigerweise zwei mal durch Smarty und PHP parsen lässt. Beides hätte wesentlich kompakter gestaltet werden können.

Was mir an dieser Sache insgesamt aufstößt, ist die merkwürdige Beharrung Maltes auf bestimmten (seiner) Vorgaben und die gleichzeitige Interesselosigkeit, anders kann ich es nicht deuten, die sich darin ausdrückt, dass das so angeblich super einfache composing nicht dazu geführt hat, das CKE in all den vielen Monaten seit dem ersten commit auch nur ein Mal gepflegt worden wäre. Was angesichts von security fixes und anderen wichtigen Verbesserungen aber durchaus nötig gewesen wäre.

Nun gut! […] Ich habe also eine derartige Lösung vorliegen, die im Großen und Ganzen diese Konfiguration beibehält, aber folgendes erweiternd ermöglicht:

Der User kann aus 3 per default angebotenen Toolbars (Basic/Standard/Full), einfach per "/Eigene Einstellungen/" wählen, ohne irgendeine Datei per Hand anfassen zu müssen. Gerade mit letzterem wären eine Menge User schlichtweg zufrieden, nehme ich an. Zusätzlich gibt es noch die Preset (also die default Full toolbar) als fallback und eine interne libeigene Fallback Toolbar, wenn Fehler auftreten. Natürlich sind nicht alle toolbar Möglichkeiten per default aktiviert, wie zb die form Elemente für textareas, die in unserem Umfeld unsinnig sind.

Für denjenigen, dem dies als Individualisierung noch nicht genügt, kann zusätzlich und updatesicher eine Template eigene config und plugin js als eigene Kopie geführt werden, in der die jeweilige CKEDITOR config mit all ihren zusätzlichen Einstellungen ganz individuell eingestellt werden kann und eigene Anpassungen für CKEDITOR-Plugins und interne Verbesserungen für das Verhältnis von S9y-Plugins und ACF vorgenommen werden können. In der Plugin,js werden zb die per default hinzugefügten CKE Serendipity Plugins zusammengeschraubt und eine paar weitere wichtige Korrekturen vorgenommen.

Die custom_ckeditor_config.js und custom_ckeditor_plugin.js lägen also unter |templates/2k11/admin/custom/| oder |meinTemplate/admin/custom/| (und das ohne das backend fallback zu stören). Unter „/Eigene Einstellungen/“ gäbe es ein Auswahlfeld für die preset Toolbars und in der wysiwyg_init müssten nur ein paar kleine Additions hinein, welche die js Arrays für die spätere Auswertung in der config bereitstellen. In der function_smarty kämen nur 3 neue Smarty-Variablen und die Erlaubnis für die |/admin/custom/| Geschichte hinzu, so dass sich die custom und plugin js sogar auch nur einzeln individualisieren ließe.

Damit erlaubt man eine unter eigener Verantwortung erstellte individuelle Konfiguration, in den dafür vorgesehenen Dateien und nicht als Appendix zu einer bestehenden Config! Und dieser letzte Punkt ist wichtig! Meine Tests, die ich hier nicht mehr alle repetieren kann, haben genau zu dieser Lösung geführt, da schon kleinste Änderungen im Gefüge, vorher Mögliches, plötzlich unmöglich machten. Als Beispiel die Einbindung von weiteren CKEDITOR Plugins über die Custom "/Build your own version/" function auf der cke Webseite. Obwohl nur etwas anders eingebunden, hatte dies zB gravierende Auswirkungen auf die Art und Weise wie Toolbars in einer custom config gebildet werden können.

Kurzum, ich habe lange herumprobiert und würde das - wenn - dann nur komplett anbieten und einbauen, ohne dass das im Nachhinein wieder verändert, in Gänze oder Teilen wieder reverted wird. Das ist kein Statement gegen Veränderung oder Verbesserung, sondern nur gegen die Ignoranz detaillierterer Erfahrungen.

Wer sich genauer anschauen will was darin möglich ist, kann sich die letzte Version des CKE Plugins in 2.0 installieren und sich diverse testcases für diese Besonderheiten selber schreiben und dann mit einem current 2.0 build cke vergleichen.

Ich wünschte, wir könnten den bisherigen Plugin Usern anbieten, einen nahtlosen Übergang zu schaffen, ohne sagen zu müssen: "/bleibe lieber beim Plugin/", weil das core CKE nur eine Art von Grundkonfiguration vorsieht, die auf Serendipity Spezialitäten keine Rücksicht nimmt.

— Reply to this email directly or view it on GitHub https://github.com/s9y/Serendipity/issues/148#issuecomment-62695617.

ophian commented 9 years ago

sondern möchte das grundsätzlich schon gerne als Teamentscheidung sehen. Einzelentscheidungen in die eine oder andere Richtung sind mir immer ein graus

Das sehe ich absolut genau so und gerade das fehlte mir bisher daran! Aber ich sehe auch, dass sich das in diesem Kapitel wohl nicht mehr ändern wird.

Das kurze Überfliegen lässt mich vermuten, dass die hohe Konfigurierbarkeit aber wirklich eher von einem Plugin als vom Kern geleistet werden sollte im CKEditor, allein weil das abbilden der Konfigurationsmöglichkeiten in der zentralen Konfiguration aus meiner Sicht sehr viel Aufwand wäre

Nö. Gar nicht! Deshalb schrieb ich: In der function_smarty kämen nur ein paar Smarty-Variablen und die Erlaubnis für die /admin/custom/ Geschichte hinzu[, so dass sich die custom config und plugin js files sogar nur einzeln individualisieren ließen]. Fast alles andere sitzt im custom cke javascript (wie jetzt auch schon) und ist das, was die eigentliche Konfiguration zwischen S9y und CKE beschreibt, mitsamt den nötigen tweaks und eingebundenen Plugins. Der core code für die Toolbar Auswahl und die templateseitige Datei Individualisierung per custom javascript ist da ganz schlicht und einfach.

Nach wie vor kann ich beide Seiten verstehen; Malte, der gerne eine "schnörkellose Idealversion" vom CKEDitor dem User im Kern geben will und Ian der den Usern gerne "alles" an die Hand geben möchte, mitsamt dedizierter Konfiguration und komplett eigener Anpassung.

Nee, auch das sehe ich ganz anders. Wir wollen doch Serendipity mit CKE möglich machen und nicht umgekehrt. Also muss man das Gute am CKE-Editor beibehalten (zb den ACF Filter!) und dennoch so viel als möglich den S9y Möglichkeiten Vorrang vor den CKE Einschränkungen einräumen. Darum gehts! Eine plain CKE copy als "schnörkelose Idealversion" zu verkaufen, geht da meines Erachtens fehl.

Warum sollten wir beispielweise die Serendipity image floats eingebunden haben, wenn diese nur ein vorgaukelndes wysiwyg-mode Abbild ermöglichten, nicht aber mit dem nötigen und korrekten Serendipity Markup abgespeichert würden, und auf das sich letztendlich die Templates verlassen? Um all solche Dinge geht es. Diese müssen, wenn man darauf Rücksicht nimmt das Serendipity das WAS bestimmt, eingearbeitet und verzahnt werden. Damit hat man dann ein custom cke-plugin und cke-config Arrangement das versucht beide Welten zu verbinden. All das beruht ja gerade auf den Erfahrungen mit unserem s9ycke Plugin. Mit der Zeit und durch Forum Requests musste das Zusammenspiel zwischen beiden immer weiter verfeinert werden. Und es ist nicht auszuschließen, dass da in Zukunft noch weitere Dinge auftauchen werden, auf die Rücksicht genommen werden muss. Alles sehr nutzerorientiert und keineswegs eine Spielwiese! (Extra Sachen wie das zusätzliche per config zuschaltbare Code Plugin sind für die Core Version ja gar nicht geplant und wären per default auch unsinnig, schon allein wegen des Aufwands.) So ein WYSIWYG Editor sitzt ja nun mal gerade an der Nahtstelle zwischen spezifischem Markup Wünschen des Frameworks und den Anforderungen und spezifischen Behandlungen des Markups eines solchen Editors selbst, der speichernden Datenbank und der templateseitigen Ausgabe. Wir haben uns ja bewußt für einen modernen Editor entschieden, der nicht einfach nur ein simpler "Übersetzer" ist.

Wie ich bereits schrieb, sind der composer und die unnötige Aufblähung von wysiwyg_init.tpl nur störende Kleinigkeiten und Designentscheidungen. Mein Angebot bezog sich also rein auf andere Änderungen, außer minimalen Anpassungen. Und das ganze nur als "Paketangebot", weil ich nur damit ein reibungsloses Zusammenspiel zwischen den Komponenten aus Erfahrung "garantieren" kann. Gemeinsame - sprich Teamseitige - Verbesserungen ohne Beschneidung wären absolut möglich und in meinem Sinne gewesen, da man dann bestimmt eher von gemeinsamen Erfahrungswerten ausgegangen wäre.

Insofern, ist deine "Empfehlung" eher eine Enttäuschung. Aber sie ist - solltest du das nicht noch überdenken - eine "Entscheidung" und ich bin erwachsen genug, sie als solche "und vielleicht später sogar noch mit Humor" zu nehmen. Irgend jemand [ :smile: ] hat mal in etwa gesagt: "Das ist doch nur Software, kein Grund für persönliche Eitelkeiten!".

garvinhicking commented 9 years ago

Hey,

verstehe ich dich richtig, die Änderungen die jetzt am Core nötig wären damit die von dir empfohlenen admin/custom/ Sachen funktionieren können sind gar nicht so aufwändig und könnten implementiert werden?

Wenn ja, dann hätte ich dich wohl falsch verstanden und würde dich bitten dafür einfach mal ein diff vorzubereiten damit wir es uns angucken können. Eine Blanko-Vollmacht dazu daran nichts zu ändern ("Kurzum, ich habe lange herumprobiert und würde das - wenn - dann nur komplett anbieten und einbauen, ohne dass das im Nachhinein wieder verändert, in Gänze oder Teilen wieder reverted wird.") sehe ich auch als unrealistisch an, aber ich denke so "friss oder stirb"-mäßig meintest du es gar nicht.

Wenn diese Änderungen aber nochmal einen kompletten Umbau des Kerns erfordern würden und die aktuellen custom_*.js-Anpassungen von Malte komplett verwerfen würden, dann würde ich bei meiner Meinung bleiben gerne Core und Plugin-CKEDitor parallel zu betreiben.

Denn ich bin fachlich nicht in er Lage die beiden Möglichkeiten jetzt zu bewerten. Aus pragmatischer Sicht sollten wir die 2.0 dann nämlich so releasen in diesem Punkt wie es jetzt ist: Es gibt ein Plugin das coole Sachen macht und es gibt ein core-CKEditor der funktioniert und bei dem man die Toolbar konfigurieren kann. Die Alternative wäre ja dann nur einen Core zu haben, der das zwar tut was das Plugin kann, aber potentiell Sachen kaputt macht die sich Malte ausgedacht hat. Das hat aus meiner Sicht dann mehr Nachteile als die alternativlösung die ich heute morgen vorgeschlagen hatte.

Damit wollte ich Dich sicher nicht Enttäuschen, aber wie du womöglich merkst, fehlt mir einfach das Verständnis für diese CKEDitor-Anpassungen. Ist einfach nicht mein Fach- und Interessensgebiet. Wenn es hier um eine Plugin-API oder Template-API oder so ginge, könnte ich da sicher kompetenter entscheiden.

LG, Garvin

On 13.11.14 14:47, Ian wrote:

sondern möchte das grundsätzlich schon gerne als Teamentscheidung
sehen. Einzelentscheidungen in die eine oder andere Richtung sind
mir immer ein graus
Das sehe ich absolut genau so und gerade das fehlte mir bisher daran! Aber ich sehe auch, dass sich das in diesem Kapitel wohl nicht mehr ändern wird.
Das kurze Überfliegen lässt mich vermuten, dass die hohe
Konfigurierbarkeit aber wirklich eher von einem Plugin als vom Kern
geleistet werden sollte im CKEditor, allein weil das abbilden der
Konfigurationsmöglichkeiten in der zentralen Konfiguration aus
meiner Sicht sehr viel Aufwand wäre
Nö. Gar nicht! Deshalb schrieb ich: In der function_smarty kämen nur ein paar Smarty-Variablen und die Erlaubnis für die /admin/custom/ Geschichte hinzu[, so dass sich die custom config und plugin js files sogar nur einzeln individualisieren ließen]. Fast alles andere sitzt im custom cke javascript (wie jetzt auch schon) und ist das, was die eigentliche Konfiguration zwischen S9y und CKE beschreibt, mitsamt den nötigen tweaks und eingebundenen Plugins. Der core code für die Toolbar Auswahl und die templateseitige Datei Individualisierung per custom javascript ist da ganz schlicht und einfach.
Nach wie vor kann ich beide Seiten verstehen; Malte, der gerne eine
"schnörkellose Idealversion" vom CKEDitor dem User im Kern geben
will und Ian der den Usern gerne "alles" an die Hand geben möchte,
mitsamt dedizierter Konfiguration und komplett eigener Anpassung.
Nee, auch das sehe ich ganz anders. Wir wollen doch Serendipity mit CKE möglich machen und nicht umgekehrt. Also muss man das Gute am CKE-Editor beibehalten (zb den ACF Filter!) und dennoch so viel als möglich den S9y Möglichkeiten Vorrang vor den CKE Einschränkungen einräumen. Darum gehts! Eine plain CKE copy als "schnörkelose Idealversion" zu verkaufen, geht da meines Erachtens fehl.

Warum sollten wir beispielweise die Serendipity image floats eingebunden haben, wenn diese nur ein vorgaukelndes wysiwyg-mode Abbild ermöglichten, nicht aber mit dem nötigen und korrekten Serendipity Markup abgespeichert würden, und auf das sich letztendlich die Templates verlassen? Um all solche Dinge geht es. Diese müssen, wenn man darauf Rücksicht nimmt das Serendipity das WAS bestimmt, eingearbeitet und verzahnt werden. Damit hat man dann ein custom cke-plugin und cke-config Arrangement das versucht beide Welten zu verbinden. All das beruht ja gerade auf den Erfahrungen mit unserem s9ycke Plugin. Mit der Zeit und durch Forum Requests musste das Zusammenspiel zwischen beiden immer weiter verfeinert werden. Und es ist nicht auszuschließen, dass da in Zukunft noch weitere Dinge auftauchen werden, auf die Rücksicht genommen werden muss. Alles sehr nutzerorientiert und keineswegs eine Spielwiese! (Extra Sachen wie das zusätzliche per config zuschaltbare Code Plugin sind für die Core Version ja gar nicht geplant und wären per default auch unsinnig, schon allein wegen des Aufwands.) So ein WYSIWYG Editor sitzt ja nun mal gerade an der Nahtstelle zwischen spezifischem Markup Wünschen des Frameworks und den Anforderungen und spezifischen Behandlungen des Markups eines solchen Editors selbst, der speichernden Datenbank und der templateseitigen Ausgabe. Wir haben uns ja bewußt für einen modernen Editor entschieden, der nicht einfach nur ein simpler "Übersetzer" ist.

Wie ich bereits schrieb, sind der composer und die unnötige Aufblähung von wysiwyg_init.tpl nur störende Kleinigkeiten und Designentscheidungen. Mein Angebot bezog sich also rein auf andere Änderungen, außer minimalen Anpassungen. Und das ganze nur als "Paketangebot", weil ich nur damit ein reibungsloses Zusammenspiel zwischen den Komponenten aus Erfahrung "garantieren" kann. Gemeinsame - sprich Teamseitige - Verbesserungen ohne Beschneidung wären absolut möglich und in meinem Sinne gewesen, da man dann bestimmt eher von gemeinsamen Erfahrungswerten ausgegangen wäre.

Insofern, ist deine "Empfehlung" eher eine Enttäuschung. Aber sie ist - solltest du das nicht noch überdenken - eine "Entscheidung" und ich bin erwachsen genug, sie als solche "und vielleicht später sogar noch mit Humor" zu nehmen. Irgend jemand [ :smile: ] hat mal in etwa gesagt: /"Das ist doch nur Software, kein Grund für persönliche Eitelkeiten!"/.

— Reply to this email directly or view it on GitHub https://github.com/s9y/Serendipity/issues/148#issuecomment-62892035.

yellowled commented 9 years ago

Ich würde mir wünschen, dass wir alle das viel pragmatischer sehen. Mir sind hier – von allen Seiten – viel zu viele Zwischen- und Untertöne im Spiel, die genau das Gegenteil tun.
Es ist ein bisschen unfair, @garvinhicking hier die Rolle als „schlichtendem Entscheider“ zuzuschreiben, zumal er meinem Verständnis nach immer betont, dass er diese Rolle nicht unbedingt einnehmen will.
Niemand von uns kennt meines Wissens diesen Editor, seine Innereien und wie er im Kern funktioniert, so gut wie @ophian. Niemand von uns hat so viel Erfahrungswerte damit. Allein deshalb sollte er meines Erachtens die „richtige“ Vorgehensweise vorgeben.
Punkt 3 darf widerum nicht bedeuten, dass es keine Diskussion um Aspekte des Editors geben darf, die andere Bereiche des Backends betrifft (Beispiel: Editor-Toolbar im Umfeld des responsiven Backends). Der Editor ist halt keine Standalone-Komponente, sondern muss sich ins Backend integrieren.

onli commented 9 years ago

Ok, dann schreib ich doch nochmal

Niemand von uns kennt meines Wissens diesen Editor, seine Innereien und wie er im Kern funktioniert, so gut wie @ophian. Niemand von uns hat so viel Erfahrungswerte damit. Allein deshalb sollte er meines Erachtens die „richtige“ Vorgehensweise vorgeben.

Dann bin ich raus.

Mal im Ernst: Ich habe keine Lust auf diesen Streit. Ich habe jetzt mehrfach mehrmonatige Zeiträume gegeben, konkrete Probleme aufzuzeigen. Jetzt, nachdem genau diese konkrete Beschreibung im Devtalk wieder gefordert und scheinbar auch bejaht wurde, kommt wieder nur bla.

Ich will konkrete Probleme sehen und konkrete Lösungsvorschläge, und kein "Ihr habt ckeditor nicht geupdatet, eure Lösung ist scheiße". Konkrete Vorschläge nehme ich auch immer noch gerne an.

Was ich nicht akzeptiere ist "ich will composer nicht lernen" und "Ich will eine Blankovollmacht, alles umzustellen". Denn das, was vorher von einer etwaigen Lösung gezeigt wurde, taugte genau gar nichts.

Ich habe zwei Möglichkeiten, das jetzige Gelaber zu deuten:

Nichts konkretes kommt, weil weder etwaige Probleme noch konkrete Lösungen im bestehenden Framework verstanden wurden
Ian ist beleidigt und will deshalb nicht mit mir spielen.

Auf beides habe ich keine Lust. Deshalb bleib ich dabei: Ich schaue mir wie oben geschrieben das an, was ich aus dem Post mitnehmen konnten (ACF, CKeditor updaten, samples rauschmeißen). Danach ist mein (meint: mein Teil des) 2.0 RC fertig. Und hierzu schreib ich nichts mehr.

Edit: Close des issues war ein missklick, ich mach hier zu wenn die verbliebenen konkreten Probleme gelöst sind.

ophian commented 9 years ago

verstehe ich dich richtig, die Änderungen die jetzt am Core nötig wären damit die von dir empfohlenen admin/custom/ Sachen funktionieren können sind gar nicht so aufwändig und könnten implementiert werden?

Nochmals Ja! (Ich habe für diese Version auch nie etwas anderes behauptet.)

Wenn diese Änderungen aber nochmal einen kompletten Umbau des Kerns erfordern würden und die aktuellen custom_*.js-Anpassungen von Malte komplett verwerfen würden, dann würde ich bei meiner Meinung bleiben gerne Core und Plugin-CKEDitor parallel zu betreiben.

Um letzteres, die Parallelität, geht es gar nicht. Die würden wir wahrscheinlich sowieso haben (wollen). (Und das klappt nach meinen letzten Änderungen auch gut.) Es geht im Kern doch darum, die notwendigen Errungenschaften für die S9y-CKE Verzahnung aus dem CKE Plugin auch im Core CKE zu haben. Und das Stand jetzt.

Wie gesagt, die coremäßigen Änderungen wären ziemlich minimal. Kleine Änderungen in der function_smarty.inc für die richtige Zuweisung der /admin/custom/*.js Dateien, das kleine toolbar array im config_personal.inc und minimale Änderungen in der wysiwyg_init.tpl um die plugin.js einzubinden und den Toolbarnamen bis in die config,js durchzuschleifen. Zu den beiden ersten kann ich gerne einen Diff machen.

Die "aktuellen custom.js-Anpassungen" von Malte sind genau zwei Dinge:

eine eigene Toolbar (Group) nach seinem Geschmack und
die potentielle Einbindung einer userconfig.js als Appendix.

Ja, daran biss er sich (für mich unverständlich) fest und Ja, das würde sich verändern! Wir hätten andere Toolbars (diejenigen, die über "Eigene Einstellungen" eingestellt würden) und wir würden keine ../userconfig.js einbinden, weil das ganze file selber templateseitig als updatesichere JS Config verändert werden könnte. (Und da kann Malte seine Toolbar wieder einbauen.) IMHO kein schlechter Tausch!

Alles andere stammt von mir aus einer älteren, früheren Version und würde in den beiden custom js Dateien mit dem Commit ziemlich erweitert werden. Für ein ganzes Beipieldiff sicherlich zu viel.

Meine Erfahrungen mit Malte aus früheren Versuchen in diesem Kapitel, der das wie man oben sieht als "sein 2.0" ansieht, haben mich gelehrt, einfach etwas vorsichtiger mit bereitwilligen diffs zu sein, da ich dann oft von vorne anfangen musste. Das würde ich mir gern ersparen. Allein deswegen kam das zustande, was ich als "Paket getesteten Zusammenspiels zwischen den Komponenten" und du eventuell als "friss oder stirb"-mäßig verstanden hast.

Es ist ein bisschen unfair Garvin hier die Rolle als „schlichtendem Entscheider“ zuzuschreiben, zumal er meinem Verständnis nach immer betont, dass er diese Rolle nicht unbedingt einnehmen will.

Verstehe ich gut und will das eigentlich auch gar nicht forcieren. Ich fühlte mich nur etwas allein gelassen, da Malte fröhlich vor sich hin committet und aus Mangel an anderen Interessenten bisher ziemlich einsam darüber entschied. Und wie man oben hört, immer noch genau so weiter entscheiden will. ... Das ist nicht mein Verständnis von Gemeinsam!

Ich habe zwei Möglichkeiten, das jetzige Gelaber zu deuten:

Ich muss sagen, es fällt mir einfach schwer dir aufgrund dieser Tonlage darauf sachlich antworten zu wollen! Aber eines vielleicht doch: Fang doch schonmal damit an die lib upzudaten und das samples zu entfernen. (Bitte!)

onli commented 9 years ago

Aber eines vielleicht doch: Fang doch schonmal damit an die lib upzudaten und das samples zu entfernen. (Bitte!)

Done, kein Problem.

Würdest du noch bitte die Probleme mit ACF genauer beschreiben? Insert eines Bildes per ML-Popupdialog funktioniert hier, samt Kommentar und Klasse, ich sehe kein verlorenes Markup. Bei der Gallerie (worauf bezieht sich das, image selector plus?) funktioniert es nicht?

garvinhicking commented 9 years ago

Hi!

Ok super, dann bereite doch bitte das diff mal vor und ich kann mir das in Ruhe anschauen und daraufhin evtl zumindest etwas konkreter sehen worum es geht. Danke!

LG, Garvin

On 13.11.2014, at 18:16, Ian notifications@github.com wrote:

verstehe ich dich richtig, die Änderungen die jetzt am Core nötig wären damit die von dir empfohlenen admin/custom/ Sachen funktionieren können sind gar nicht so aufwändig und könnten implementiert werden?

Nochmals Ja! (Ich habe für diese Version auch nie etwas anderes behauptet.)

Wenn diese Änderungen aber nochmal einen kompletten Umbau des Kerns erfordern würden und die aktuellen custom_*.js-Anpassungen von Malte komplett verwerfen würden, dann würde ich bei meiner Meinung bleiben gerne Core und Plugin-CKEDitor parallel zu betreiben.

Um letzteres, die Parallelität, geht es gar nicht. Die würden wir wahrscheinlich sowieso haben (wollen). (Und das klappt nach meinen letzten Änderungen auch gut.) Es geht im Kern doch darum, die notwendigen Errungenschaften für die S9y-CKE Verzahnung aus dem CKE Plugin auch im Core CKE zu haben. Und das Stand jetzt.

Wie gesagt, die coremäßigen Änderungen wären ziemlich minimal. Kleine Änderungen in der function_smarty.inc für die richtige Zuweisung der /admin/custom/*.js Dateien, das kleine toolbar array im config_personal.inc und minimale Änderungen in der wysiwyg_init.tpl um die plugin.js einzubinden und den Toolbarnamen bis in die config,js durchzuschleifen. Zu den beiden ersten kann ich gerne einen Diff machen.

Die "aktuellen custom.js-Anpassungen" von Malte sind genau zwei Dinge:

eine eigene Toolbar (Group) nach seinem Geschmack und die potentielle Einbindung einer userconfig.js als Appendix. Ja, daran biss er sich (für mich unverständlich) fest und Ja, das würde sich verändern! Wir hätten andere Toolbars (diejenigen, die über "Eigene Einstellungen" eingestellt würden) und wir würden keine ../userconfig.js einbinden, weil das ganze file selber templateseitig als updatesichere JS Config verändert werden könnte. (Und da kann Malte seine Toolbar wieder einbauen.) IMHO kein schlechter Tausch!

Alles andere stammt von mir aus einer älteren, früheren Version und würde in den beiden custom js Dateien mit dem Commit ziemlich erweitert werden. Für ein ganzes Beipieldiff sicherlich zu viel.

Meine Erfahrungen mit Malte aus früheren Versuchen in diesem Kapitel, der das wie man oben sieht als "sein 2.0" ansieht, haben mich gelehrt, einfach etwas vorsichtiger mit bereitwilligen diffs zu sein, da ich dann oft von vorne anfangen musste. Das würde ich mir gern ersparen. Allein deswegen kam das zustande, was ich als "Paket getesteten Zusammenspiels zwischen den Komponenten" und du eventuell als "friss oder stirb"-mäßig verstanden hast.

Es ist ein bisschen unfair Garvin hier die Rolle als „schlichtendem Entscheider“ zuzuschreiben, zumal er meinem Verständnis nach immer betont, dass er diese Rolle nicht unbedingt einnehmen will.

Verstehe ich gut und will das eigentlich auch gar nicht forcieren. Ich fühlte mich nur etwas allein gelassen, da Malte fröhlich vor sich hin committet und aus Mangel an anderen Interessenten bisher ziemlich einsam darüber entschied. Und wie man oben hört, immer noch genau so weiter entscheiden will. ... Das ist nicht mein Verständnis von Gemeinsam!

Ich habe zwei Möglichkeiten, das jetzige Gelaber zu deuten:

Ich muss sagen, es fällt mir einfach schwer dir aufgrund dieser Tonlage darauf sachlich antworten zu wollen! Aber eines vielleicht doch: Fang doch schonmal damit an die lib upzudaten und das samples zu entfernen. (Bitte!)

— Reply to this email directly or view it on GitHub.

ophian commented 9 years ago

Ok super, dann bereite doch bitte das diff mal vor und ich kann mir das in Ruhe anschauen und daraufhin evtl zumindest etwas konkreter sehen worum es geht. Danke!

https://gist.github.com/ophian/02f7b71bde9a895403bf

Wie gesagt, der Rest sind zwei lang vars, der minor change in der init und natürlich der ganze Kram für die custom_config.js und custom_plugin.js.

garvinhicking commented 9 years ago

Hi!

Und wie würde "der Rest" aussehen? Das würde ich auch gerne mal sehen was für Änderungen da notwendig wären?

Der Patch den Du da vorschlägst sehe ich ja erstmal unkritisch, das würde ja auch nichts "brechen".

LG, Garvin

On 14.11.14 10:59, Ian wrote:

Ok super, dann bereite doch bitte das diff mal vor und ich kann mir
das in Ruhe anschauen und daraufhin evtl zumindest etwas konkreter
sehen worum es geht. Danke!
https://gist.github.com/ophian/02f7b71bde9a895403bf

Wie gesagt, der Rest sind zwei lang vars, der minor change in der init und natürlich der ganze Kram für die custom_config.js und custom_plugin.js.

— Reply to this email directly or view it on GitHub https://github.com/s9y/Serendipity/issues/148#issuecomment-63035401.

ophian commented 9 years ago

Sag ich doch! Das einzige was es "bricht" ist die 'Onli Toolbar' und die 'Art und Weise' wie die "Power User" eine eigene custom config bearbeiten können. Ansonsten - wenn man nicht das schon als Vorteil sehen will - nur Vorteile, da der Serendipity User sich zB einfach eine eigene Toolbar auswählen kann, ohne irgendetwas anders bedienen zu müssen als Serendipity. Und, weil damit die besprochenen Ausnahmen, Erfahrungen und Verzahnungen in das JS handling hineinkommen. PM

ophian commented 9 years ago

Und wie würde "der Rest" aussehen? Das würde ich auch gerne mal sehen was für Änderungen da notwendig wären?

https://gist.github.com/ophian/db4dc458c51ddfa4b79c und die custom config.js etwas angepasster fast analog zu https://github.com/s9y/additional_plugins/blob/master/serendipity_event_ckeditor/cke_config.js

Sonst nur noch js protection sources für die Verzahnung.

garvinhicking commented 9 years ago

Hey Leute,

Folge Dinge stehen also zur Diskussion:

Custom Config in template/ statt in htmlarea/ Verzeichnis
Konfigurations-Variable, um zwischen verschiedenen vordefinierten Toolbars zu wechseln
Anpassung der Toolbar-Presets
Zuweisung einer s9y-Toolbargruppe für Plugins
Weitere ACF-Ausnahmen

Dazu nun die Kommentare/Feedback:

Ursprünglich hatten wir versucht diese Custom Config aus dem Template rauszulassen, weil es für User eher umständlich wäre nur für so eine Datei ein Template anzupassen. Vor allem, weil Toolbars eigentlich eher unabhängig von Templates sind. Daher schien "htmlarea" der bessere Ort.

Ich denke, das es mit dem aktuellen Entwurf tatsächlich Vorteile gibt, das im Template-Verzeichnis zu lagern. So können Templateautoren ihre eigenen Toolbars bündeln, in denen sie eigene Snippets und für das Template angebasste Buttons (nicht im Sinne von Grafiken, sondern Funktionalitäten) mitliefern können. Und man kann zwischen Templates wechseln, und dadurch auch die angepasste Toolbar verändern.

Eine Vorteil, die Config in htmlarea/ liegen zu lassen sehe ich nur darin, dass diese Methode bereits implementiert ist und geändert werden müsste; konzeptionelle Vorteile hiervon sehe ich aber nicht mehr. Malte schrieb dass es über die config.inc.php Template-API schon geht, aber das würde ja dann umso mehr dafür sprechen es im Template ausserhalb von htmlarea/ abzulegen, damit man erst recht nicht noch ein neues Verzeichnis zur Anpassung dafür "aufmacht".

2/3. Malte hat viel Zeit investiert und dabei Matthias WYSWIWYG-Editorvorgaben versucht zu befolgen um sich auf eine sinnvolle Toolbar-Vorgabe zu einigen, die den Blogautoren nicht zu viel "Spielerei" anbietet und damit Blogpostings verschandeln lässt. Als Default-Toolbar sollte daher die Toolbarkonfiguration gewählt werden, die auch den jetzigen Standard darstellt denke ich (ohne mich damit genau auseinandergesetzt zu haben). Weitere Presets wären optional und könnten dann eine erweiterte Konfiguration nutzen, bestenfalls mit einem Hinweis dass derartige Nutzung gerade im Zusammenspiel mit weiteren Markupplugins oder auch CSS des Templates nicht immer sinnvoll sein könnten. "Your mileage may vary", sozusagen.

Da dies der größte "Weichenstellungspunkt" ist, noch einmal mein persönliches Mission Statement: Ich denke dass Serendipity schon immer für größtmögliche Flexibilität und Anpassbarkeit stand und stehen sollte, und mein Credo ist, den Benutzer nicht zu bevormunden. Potentiell "kuriose" Aktionen oder sehr selten eingesetzte Features sollten immer umsetzbar sein, aber dann auch gerne bewusst als Sonderoption oder Plugin aktivierbar.

Ich fände es daher nicht verwerflich, so eine Flexibilität zu bieten, selbst wenn man sich sein Blog damit verschandelt. Ich würde ungerne von meinen eigenen Verhaltensmustern auf die Nutzer an sich schließen wollen. Man sieht zwar an Apple dass eine solche Vorgabe höchsten kommerziellen Erfolg mit sich bringen kann (wenn man denn ein gutes Händchen für den Allgemeingeschmack hat), aber meine Vorstellung von Serendipity als Software ist das nicht.

Diese Lösung für User leicht in der UI einzubinden (es ist ja nur ein Dropdown) im Gegensatz zum "Programmieren" einer ganz eigenen JS-Datei das für vielel abschreckend ist, finde ich it ein klarer Vorteil für die User.

4/5. Sicher sinnvolle Anpassungen, die man übernehmen sollte.

Die nun noch im Raum stehenden Anpassungen sind potentiell natürlich zum jetzigen Zeitpunkt für einen RC relativ schwerwiegend, auch wenn sie nur einen Teilbereich betreffen. Da Serendipity 2.0 ja insgesamt im Templatebereich einige Erweiterungen mit sich bringt, denke ich, dass wir uns hier die Zeit im Sinne der User nehmen müssen und diesen Punkt jetzt VOR dem Release klären, und nicht als späteres Feature einbauen. Sonst nutzen die User schon die alten Custom-Config-Möglichkeiten, die in Zukunft dann schon wieder obsolet wären. Auch würde durch die Toolbarkonfiguration der Einbau des in 2.0 neuen CKEditors aus meiner Sicht tatsächlich "runder" machen. Nachträglich erst Presets zu ermöglichen könnte uns da schon in die Quere kommen, zumal wir beim RC wirklich jetzt in der Lage sind einen guten ersten Eindruck zu machen, auch mit einem solchen Feature das den CKEditor als eines der neuen Primärfeatures betrifft.

Wir haben ja jetzt unsere ursprüngliche Sommer-Timeline überschritten, gerade jetzt überhastig zu werden und eine Diskussion abzubrechen oder Dinge im Raum stehen zu lassen fände ich schade.

Es ist natürlich weiterhin eine Option, diese Features in dem CKEditor-Plugin zu bündeln. Eine wie ich finde nicht total zumutbare Alternative für User, um zu dem Feature zu kommen. Aber es bringt natürlich einiges an Redundanz mit sich, und jetzt wo wir denselben Editor ja im Core auch bundeln würden sich Benutzer schon eher wundern, warum sie für eine Konfigurationsanpassung ohne weiteren "Featuregewinn" auf ein komplettes Plugin umsteigen sollten.

Da diese Customizing-Dinge ja nun auch im Plugin auch teilweise bereits erprobt sind, würde ich die Gefahr jetzt eher gering einstufen, dass wir uns die gesamte CKEditor-Einbindung im Kern zerhacken. Aber hier bin ich nur Zuschauer, da kenne ich mich Codemäßig letztlich nicht aus und würde meinen fragenden Blick in die Runde werfen.

Ich würde mich sehr interessieren, was ihr anderen (Matthias, Mattsches, evtl auch andere Mitlesende User?) zu dem zentralen Punkt sagen, "Convention Over Configuration" oder lieber "Configuration Over Convention"?

Zum Abschluss noch ein paar Fragen/Anmerkungen zu Ians Vorschlag:

Es muss gewährleistet sein, dass ein User seine Toolbar anpassen kann ohne dass er eine zum s9y Release gehörende Datei ändert; sprich, es darf keine templates/2k11/admin/custom/ckeditor_custom_plugin.js oder so geben die mitgeliefert wird, sondern höchstens eine ckeditor_plugin.js oder so die dann nicht mit zum Template gehört. Denn sonst werden User verleitet, die 2k11-Datei manuell zu bearbeiten; und man sollte den Usern nicht zumuten extra ein eigenes Template zu erstellen nur um so eine Datei mitzuliefern. Hier müsste man ggf. also den ganzen JS-Dateinamen per PHP an Smarty weiterreichen und checken "gibt es eine ckeditor_custom_plugin.js, dann nutze die, und sonst lade die Vorlagedatei ckeditor_plugin.js". Innerhalb dieser Datei sollte nochmal eindrücklich die Warnung stehen nicht genau jene Datei anzupassen sondern eine Kopie zu machen und als ckeditor_custom_plugin.js zu speichern.
Es muss gewährleistet sein, dass der User nicht nur zwischen vordefinierten Toolbars wählen kann sondern seine ganz eigenen zusammenstellen kann. Wenn man sie in einem eigenen Templateverzeichnis ablegen kann, sehe ich das als Vorteil, da man dann ein einzelnes Verzeichnis mit customizing hat, und nicht in mehreren Verzeichnissen. Ein eigenständiges Verzeichnis wie "admin/custom" finde ich jedoch potentiell schon zu sehr verschachtelt, ich würde so etwas eher direkt in "admin/" hineinlegen wollen.
In https://gist.github.com/ophian/db4dc458c51ddfa4b79c wurde vermutlich versehentlich das {$use_autosave} entfernt, darauf bitte achten das nicht zu ändern.
Wenn wir uns wirklich für solche Preset-Custom-Dateien entscheiden, sollte es ein eigenes Preset "Custom (if existing)" geben in der Konfiguration $serendipity['wysiwygToolbar'], damit der User dies gezielt aktivieren muss. Sonst gäbe es ja den Fall dass man ein Backendtemplate einsetz wo eine custom config mitgeliefert ist, man aber ja eigentlich lieber die s9y-Defaulttoolbar nutzen möchte ohne vom Template die Toolbar zu löschen. So hat der User dann die Chance, die Toolbar vom Template bewusst nicht zu nutzen.

LG, Garvin

yellowled commented 9 years ago

Der größte Teil dieser Diskussion ist mir persönlich herzlich egal. Ich benutze keinen WYSIWYG-Editor, ich habe auch keine aktiven Projekte, in denen ich einen benutzen oder unterstützen müsste. Mir geht es lediglich darum, dass wir im Kern einen anständigen WYSIWYG-Editor haben, der uns langfristig weniger Bauchweh als Xinha macht und sich anständig ins Backend integriert. Den technischen Rest müsst Ihr irgendwie lösen. :)

Dennoch ein paar kurze Anmerkungen:

So können Templateautoren ihre eigenen Toolbars bündeln

Ich wage die Prognose, dass kaum ein Template-Autor dafür Verwendung haben wird. Falls das also in irgendeiner Form ein Overhead sein sollte, ist es vermutlich ein mehr oder weniger sinnfreier.

mein Credo ist, den Benutzer nicht zu bevormunden

Wenn man es als Bevormundung ansieht, Dinge abzuklemmen, die nicht sinnvoll sind, auch wenn man sie technisch gesehen machen kann, dann kann man die angepasste Toolbar wohl als Bevormundung sehen. Es geht bei der „voreingestellten“ Toolbar aber ausdrücklich nicht darum, Benutzer zu bevormunden, sondern darum, den WYSIWYG-Editor sinnvoll zu konfigurieren, was leider nur sehr weniger WYSIWYG-Editoren „ab Werk“ tun.

Letztlich ist mir aber auch das komplett egal – wenn Ihr mehrheitlich der Meinung seid, man müsse Nutzern eine Kitchen Aid in die Hand geben, wo es ein scharfes Küchenmesser auch täte, dann macht das meinetwegen so. Der einzige Einwand, den ich weiterhin nennen muss: je mehr Toolbar dieser Editor bietet, desto schwer wird es sein, ihn vernünftig im responsiven Backend zu nutzen. (Verschont mich bitte mit dem „Schreibt doch eh keiner auf Smartphones Blogposts“-Argument.)

garvinhicking commented 9 years ago

Der Overhead läge nur darin die CustomConfig ins Template-Verzeichnis zu kopieren; für den potentiellen Gewinn den das hat IMO eigentlich kein Overhead. Die CustomConfig wird ja eh nur reingeladen wenn sie vorhanden ist. Das gilt auch für Deinen zweiten Punkt: Wir definieren ja durchaus eine sinvolle "ab Werk"-Konfiguration mit dem Standard-Preset. Die Leute dann die vollständigen Features vom CKEditor nutzen zu lassen, per einfachem Regler, vor allem wenn der dazu notwendige Implementationsaufwand ja eigentlich schon von Ian betrieben würde, wäre wenn man das nicht nutzt schon eine Art Bevormundung.Wenn wir also bewusst so eine Möglichkeit zurückhalten obwohl sie implementiert ist und dadurch auch ein eigenständiges Plugin für den User unnötig machen würde, dann wäre das ja schon eine Art Bevormundung.

Wenn die User also so eine schwere Toolbar wählen, dann werden sie auch ein Gerät nutzen müssen, dass die Toolbar supportet.

Ian ist ja letztlich auch ein Nutzer und fordert es, das muss man ihm auch zugestehen. Umgekehrt tut man keinem Nutzer weh dem man nur sagen müsste "nutz es halt nicht, wenn Du es nicht brauchst"...?

yellowled commented 9 years ago

Wie gesagt: Ich halte diese „Bevormundung“ für eine sinnvolle Voreinstellung zum Wohle des Nutzers und habe den Erfahrungswert, dass „nutze nur, was Du brauchst“ im Kontext WYSIWYG-Editoren nicht funktioniert. Könnte daran liegen, dass es mir als Theme-Autor weh tut, wenn Blogautoren in der Lage sind, Inhalte in funktionierenden Themes durch Aktionen im WYSIWYG-Editor zu entstellen.

Wenn der Konsens abgesehen vor mir ist, dass die Freiheit des Nutzers wichtiger ist, dann bitte.

ophian commented 9 years ago

Zum Abschluss noch ein paar Fragen/Anmerkungen zu Ians Vorschlag:

Ich will nur mal schnell ein paar Korrekturen zu diesen Fragen/Anmerkungen einbringen:

Zu 1.) "User werden verleitet..." Ähem! :smile: Wir haben unsere gesamtes backend in 2k11/admin/ liegen. Warum auf einmal soll das plötzlich für die cke configs eine Gefahr sein, wenn jemand darin rumfummelt, wenn es das nicht auch schon vorher mit all den anderen Files war? Deshalb muss für einen "Power User", der wirklich eigene Einstellungen treffen will, zumutbar sein, dies in seinem eigenen Template zu machen. Für die CKE configs wäre dies ja außerdem auch noch unabhängig vom restlichen backend template möglich. Das wird ja in dem lang constant proposel auch kommuniziert.

Zu 2.) "Es muss gewährleistet sein, dass der User .... seine ganz eigenen zusammenstellen kann" Dies kann er ganz einfach, indem er er die gewählte Toolbar (zb Full) in der js config Datei auf seine Bedürfnisse abändert. (U.a. deshalb ist auch die Reihenfolge wichtig. Erst die vordefinierten Toolbars mit Namen (Basic/Standard/Full/Preset) und dann die Fallbacks für CKEDITOR selbst und auch für Serendipity mit der Toolbar Group.)

Zu 3.) "autosave wurde entfernt" Das stimmt nicht! Ich habe nur einen besseren Platz dafür gefunden, siehe https://gist.github.com/ophian/db4dc458c51ddfa4b79c#file-the-rest-L69

Zu 4.) Das Problem verstehe ich nicht. Wir würden zb einfach die default Toolbar als default festlegen. Das ein Template Autor überhaupt auf die Idee käme eigene Dateien in sein admin zu legen, wäre dasselbe "Problem" wie bei 1.). In meinen Augen keines, was nicht ohnehin besteht! Man muss das Ganze ja auch nicht unnötig kompliziert reden... und die Kirche im Dorf lassen. :)

Wenn man es als Bevormundung ansieht, Dinge abzuklemmen, die nicht sinnvoll sind, auch wenn man sie technisch gesehen machen kann, dann kann man die angepasste Toolbar wohl als Bevormundung sehen. Es geht bei der „voreingestellten“ Toolbar aber ausdrücklich nicht darum, Benutzer zu bevormunden, sondern darum, den WYSIWYG-Editor sinnvoll zu konfigurieren, was leider nur sehr weniger WYSIWYG-Editoren „ab Werk“ tun.

Finde ich im Grunde auch. Und ist nichts anderes als das, was ich auch vorhabe. Maltes und meine Toolbars unterscheiden sich da höchstens in Kleinigkeiten, Anordnungen und persönlichen Ansichten. Er möchte da wohl mehr wegnehmen als ich. Aber, ich habe damals mit YL ja auch schon ein abgesprochene Toolbar Anordnung für das CKE Plugin ausgehandelt. Diese würde ich tatsächlich gerne weiterpflegen, schon allein aus Gewöhnungsgründen für Umsteiger. Aber ein absolutes Muss ist das nicht! Jeder hätte ja dann tatsächlich die Möglichkeit nach seinem eigenen Geschmäckle vorzugehen, so er dies wirklich will! Nur als ein krasses Beispiel: die ellenlange forms group ist wirklich nicht sinnvoll für unseren Blog, Wer das tatsächlich haben und aktivieren will, muss den "Power User" Pfad beschreiten.

ophian commented 9 years ago

Ach und eines noch: Die Frage/Aufgabe warum sie verschieden heißen soll(t)en, verstehe ich auch nicht. Sie heißen ja ckeditor_custom_config.js und ckeditor_custom_plugin.js, weil sie eine ckeditor custom config und plugin sind. Sie überschreiben die normale config.js von CKE und heißen deshalb custom. Das hat nichts mit custom im Sinne von Serendipity zu tun! Deshalb können sie in 2k11 und anderen Templates auch den gleichen Namen und Ort tragen. Das admin/custom/ dir habe ich nur gewählt, wel man damit deutlich machen kann, dass dies auch unabhängig von einem eigenen backend gehalten werden kann, aber durchaus in seiner Auswirkung ein backend file ist. (Edit: Sonst hätten sie ja auch in admin/js gekonnt!) Ich wüde im Vergleich zu dem Vorschlag es einfach nur in /admin zu legen, eher empfehlen, es so wie von mir vorgeschlagen zu lassen.

ophian commented 9 years ago

Ian ist ja letztlich auch ein Nutzer und fordert es, das muss man ihm auch zugestehen.

Um das mal klarzustellen. Ich bin kein richtiger Nutzer, weil ich fast nie dazu komme überhaupt ein einfacher Blog Nutzer zu sein und vom Hause aus auch eher ein PLAIN Editor User war. Ich sehe das eher aus der DEV Perspektive und überlege immer, was einem normalen Nutzer eventuell wichtig ist, bzw mir, wenn ich ein solcher wäre. Aber CKE kann was und ist schnell und zuverlässig, wenn man ihn bedienen kann. Tatsächlich aber nutze ich den CKE hauptsächlich zum Testen! ;-)

garvinhicking commented 9 years ago

Hi!

Zu 1.) /"User werden verleitet..."/

Lass uns bitte jetzt keine Nebenkriegsschauplätze aufmachen. Das Verleiten bezog sich klar auf das Einfügen einer UI-Option für Toolbarumstellungen, und das verleitet User dazu so etwas dann auch einzusetzen. Im Gegensatz zu einer komplizierten JS-Dateien mit der man eigene Toolbars freischalten würde.

Zu 4.) Das Problem verstehe ich nicht. Wir würden zb einfach die default Toolbar als default festlegen. Das ein Template Autor überhaupt auf die Idee käme eigene Dateien in sein admin zu legen, wäre dasselbe "Problem" wie bei 1.). In meinen Augen keines, was nicht ohnehin besteht! Man muss das Ganze ja auch nicht unnötig kompliziert reden... und die Kirche im Dorf lassen. :)

Also für mich ist das ein realtistisches Problem: Template-Autoren packen eine Custom-Config in ihr Template für Super-Sonderfeatures. Wenn ein Blogredakteur aber damit überfordert ist, muss es ihm möglich sein über die s9y Persönlichen Einstellungen eine normale Toolbar einzusetllen die den s9y default darstelle, so dass nichts vom Template da drüber geladen wird.

Wie man das konkret erreicht ist mir egal, da bin ich für Vorschläge/Implementierungen offen. Es wäre aber doof wenn das Custom-Config des Templates immer geladen wird. Das sollte nur dann passieren wenn der User als Preset "Custom Config" gewählt hat.

Die Frage/Aufgabe warum sie verschieden heißen soll(t)en, verstehe ich auch nicht. Sie heißen ja |ckeditor_custom_config.js| und |ckeditor_custom_plugin.js|, weil sie eine ckeditor custom config und plugin sind. Sie überschreiben die normale config.js von CKE und heißen deshalb custom. Ich wüde im Vergleich zu dem Vorschlag es einfach nur in |/admin| zu legen, eher empfehlen, es so wie von mir vorgeschlagen zu lassen.

Bitte lass es uns einfach in /admin packen, ich möchte kein weiteres Verzeichnis wo nur diese beiden Dateien liegen.

Ansonsten ging es mir darum, dass es KEINE ckeditor_custom_plugin.js und ckeditor_custom_config.js direkt in /admin geben soll, diese Dateien sollten ckeditor_custom_plugin.example.js und ckeditor_custom_config.example.js am besten heißen. Die Dateien, die der User später ja selber in ein Verzeichnis legen soll dürfen NICHT genau so heißen, weil dann die User ja eine bestehende Datei überschreiben würden und das gäbe Upgrade probleme. Die Custom-Dateien dürfen einfach auf keinen Fall so heißen, wie später die User-Dateien heißen sollen.

Alternativ könnte man die Dateien auch ckeditor_plugin.js und ckeditor_config.js nennen, und in denen die Default-Config ablegen, und darin verweisen dass es für Anpassungen ckeditor_CUSTOM_config/plugin.js geben soll.

Oder verstehe ich das falsch und eine ckeditor_custom_plugin.js würden wir gar nicht erst mitliefern weil die Konfiguration schon in anderen Dateien standardmäßig vom s9y Core kommt, und solche Dateien wirklich NUR für eine Anpassung nötig wären?

(Das mit dem Autosave-Patch habe ich jetzt erst gesehen; geht klar, sorry.)

Zusammenfassend hätte ich also gerne:

[x] Deinen Patch einspielen für Toolbar-Presets bei persönlichen Einstellungen, weitere ACF-Filter, zuweisungen der s9y-Toolbargruppe für Plugins, Custom config files
[x] Das aktuelle Toolbar-Layout ist der Default-Preset (oder verstehe ich das falsch, und an der aktuellen gibt es Kritik? Dann bitte gerne mal konkret nennen worin sich diese problematisch zeigt und wo was fehlt oder zu viel wäre)
[x] Custom Config-Files landen in templates/2k11/admin/
[x] Custom Config-Files haben einen eigenständigen Namen, so dass unsere mitglieferten Dateien nicht überschrieben werden müssen
[x] Der User kann "irgendwie" festlegen dass eine Template-CustomConfig nicht sein default Toolbar preset überschreibt

D'accord?

ophian commented 9 years ago

Irgendwie habe ich einen dicken Balken vor Augen. Ich kann deine Besorgnis einfach nicht verstehen, die das Ganze so (unnötig) kompliziert machen muss und habe deshalb immer noch den Verdacht, dass wir uns eventuell missverstehen.

Nochmal in Kürze:

Die Dateien - wie man sie auch immer nennen mag - sind customized config Dateien, welche nur die default config Dateien des CKE Systems selbst überschreiben.
Sie liegen für cke zugänglich (irgendwo) in templates/2k11/admin.
Mein Vorschlag war in admin/custom dir, damit man sie, falls wirklich nötig (und das werden nur User im Promille Bereich sein), leicht in sein eigenes Template kopieren kann. Sonst hätten die Dateien ja auch in admin/js gekonnt! Je komplizierter das also gedacht, desto komplizierter die Fallbackkette für die smarty.inc, um zwischen der default config und den den user configs zu unterscheiden. Man muss also nicht das ganze Backend kopieren oder ein eigenes schreiben und aktivieren, um tatsächlich nur diese beiden Dateien zu beinflussen. Für mich eher ein Feature. Dadurch sicherlich potentiell etwas etwas einfacher, aber -siehe unten- sicherlich doch eher nur eine "Promillemöglichkeit".

Meine Frage lautet also. Was nun macht diese Dateien jetzt potentiell anders und gefährlicher für einen "mutwilligen" Template Autor, als zB die serendipity_editor.js.tpl oder auch alle anderen Dateien die in /admin liegen, dass es also absolut nötig wäre diesen simple approach von Ort/Name zu verkomplizieren?

Lass uns bitte jetzt keine Nebenkriegsschauplätze aufmachen. Das Verleiten bezog sich klar auf das Einfügen einer UI-Option für Toolbarumstellungen, und das verleitet User dazu so etwas dann auch einzusetzen. Im Gegensatz zu einer komplizierten JS-Dateien mit der man eigene Toolbars freischalten würde.

Das war kein Nebenkriegschauplatz, sondern bezog sich auf das Argument von Ort/Namen der persönlichen js Dateien, nicht der persönlich gewählten Toolbar. Wenn ich dich hier nun richtig verstehe, meinst du ja explizit die select box (NAMEN) unter "Eigene Einstellungen", mit der man Basic, Standard, Full oder Preset Toolbars für das Serendipity Backend wählen kann. Natürlich, das soll ja auch dazu "verleiten" sich eine persönliche Toolbar auszuwählen und das einfach per KLICK ohne irgendeine Datei anzufassen. Das ist ja die Ursache meiner Bemühungen, das dies einfach möglich ist. Mancher benötigt nur eine simple WYSIWYG Toolbar (eher ein 1-Zeiler), ein anderer ist mit einer Standard Toolbar zufrieden (eher ein 2-Zeiler) und wieder einer möchte die Full Toolbar (eher ein 3-Zeiler) haben. Alle drei sind geregelte Toolbars, also von uns beeinflusst! Die wählbare Preset ist diejenige, welche die Autoren von CKE als Full vorgeben. Diese Toolbars bestehen alle aus angeordneten Button-Gruppen. (Um sich das live anzuschauen, bitte einmal kurz das CKE Plugin aktivieren.) Die Frage der Anordnung dieser Gruppen ist eine gesonderte, hier nur soviel, dass ich überzeugt bin, dass die CKE Autoren sich bestimmt einiges dazu gedacht haben in ihren Presets. Welche wir nun als Default Toolbar vorgeben, bevor einer über "Eigene Einstellungen" seine persönliche Auswahl trifft, sollten wir überlegen. Ich persönlich wäre für die Standard Toolbar.

Wir reden also bei den gedachten "Power Usern" nur von solchen, die zusätzlich zu all dem noch in einer JS Datei herumarbeiten wollen, um ganz bestimmte, sehr persönliche Einstellungen zu treffen. Diesen Fall sehe ich eher für keinen Template Autor kommen, außer für den Fall, in dem dieser auch weitere Daten des Backends anfassen würde. Wenn dies also so wäre, bekommt ein "ahnungsloser" User also tatsächlich eine eventuell vom gewählten Template beinflusste Toolbar, bzw cke custom config. Für diesen "fast nicht vorkommenden" Fall extra Ausnahmebehandlungen zu schrieben, die immer auch für alle 99.99% anderen User gelten müssen, ist IMHO unnötig. Aber vielleicht eben auch nur ein tatsächliches Missverständnis meinerseits, dass diese "Gefahr" vielleicht doch größer ist, als ich denke. (Letzendlich ist es aber doch das, was mit dem 2.0 Entwurf generell auch impliziert wurde, dass ein Termplate Autor das Backend beinflussen kann, sollte er sich tatsächlich diese Mühe machen.) Ich verstehe das mein oben genanntes Feature nun tatsächlich diese "Möglichkeit" schafft, aber sie ist so dermaßen rar, dass ich die Mühe kaum Wert fände, sie abzufangen.

ophian commented 9 years ago

Das aktuelle Toolbar-Layout ist der Default-Preset (oder verstehe ich das falsch, und an der aktuellen gibt es Kritik? Dann bitte gerne mal konkret nennen worin sich diese problematisch zeigt und wo was fehlt oder zu viel wäre)

Default Preset von was? Zwischen der aktuellen von onli gestalteten Toolbar und meinen Varianten gibt es "persönliche Vorlieben". Er nimmt etwas mehr weg als ich und ordnet die Gruppen anders an. Für beides müsste man natürlich eine Einigung finden. Und das kann man, wenn man vernünftig miteinander redet. Es ist wahrscheinlich eher schwer eine total allgemeingültige Variante zu finden. Sicher ist, das sie bestimmten Kriterien entsprechen muss. Ich neige dazu, außer in Kleinigkeiten, den CKE Devs da erst mal ein sehr gut überlegtes Grundkonzept zu unterstellen. Durch das viele Testen haben sich aber bestimmte Anordnungs Kriterien für mich als Rechtshänder ergeben. Wäre der Editor für alle Nutzer neu, wäre es sicherlich auch kein Problem, eine Toolbar-Anordnungs-Variante zu implementieren, die dem entspricht was onli vorhat. Meine Besorgnisse sind da dreierlei.

Die Plugin Toolbar-Anordnungs-Varianten sind seit anderthalb Jahren anders und deshalb müssen sich Nutzer eventuell umgewöhnen. Das wäre auch nicht schlimm, wenn es wirklich gute und nicht nur persönliche Argumente dafür gibt.
Es muss eine solche Freiheit für erlaubte Toolbar-Gruppen geben, die in ihrer Verkettung einerseits möglichst wenig das responsive Design stört und anderseits nicht mehr Nutzer als nötig dazu verleitet, Toolbar-Gruppen per persönlicher Config in einer eigenen Datei wieder freizuschalten oder herumzugruppieren. (Die bestmögliche fluidable Verkettung erreicht man überhaupt besser über die stückweise Verkleinerung von Toolbar Gruppen, als über andere Anordnungen der Gruppen untereinander.)
Alle Serendipity Buttons sind bunt, im Gegensatz zu den CKE Buttons. Und sie lagen, seit wir JS-Editoren haben, in der 'others' Button-Gruppe. Das gilt auch für den MediaLibrary Button. Ich würde das gerne so lassen, während onli gerne den ML Button in die Nähe des Image-Widget Buttons von CKE verlegen würde, wenn ich das richtig verstehe. Auch das ist mit meiner Variante möglich, aber nicht angelegt. Allgemein würde ich um solche Kleinigkeiten auch nicht allzuviel Gewese drum machen.

garvinhicking commented 9 years ago

Hi!

Lass uns nicht weiter über den Speicherort sprechen. Die Dateien kommen in /templates/2k11/admin/ckeditor_custom_config.js und /tempaltes/2k11/admin/ckeditor_custom_plugin.js. Ende der Diskussion dazu.

Nun zu dem Problem der Benennung.

Ich verstehe es so, dass wir für das Serendipity-Bundle ja Dateien brauchen in denen unsere Toolbar-Presets etc. festgelegt werden.

Ich verstehe Dich dazu so, dass Du dies festlegst in:

/templates/2k11/admin/ckeditor_custom_config.js /templates/2k11/admin/ckeditor_custom_plugin.js

Das würde heißen, dass wir diese Dateien dann mit Serendipity ausliefern müssten, und wenn jemand diese Dateien dann ändern will hat er nur zwei Möglichkeiten:

Er erstellt ein komplett eigenes Template und packt dort diese Dateien rein. Ist Schwachfug, machen wir nicht, also keine Option.
Er überschreibt die Dateien /templates/2k11/admin/ckeditor_custom_config.js und /templates/2k11/admin/ckeditor_custom_plugin.js mit eigenem Inhalt. Dann aber ist beim nächsten Update von Serendipity die Datei überschrieben, der User verliert seine Presets, ist also keine Option.

Daher schlug ich im Verlauf der Diskussion folgende Möglichkeiten vor:

Wir benennen die Dateien die von Serendipity mitkommen so: /templates/2k11/admin/ckeditor_config.js /templates/2k11/admin/ckeditor_plugin.js um. Diese Dateien müssen auch dann vom Serendipity-Kern gezogen werden, wenn jemand z.b. das "bulletproof" Template hat!

Dann werden vom User solche Dateien nicht überschrieben, sondern jemand legt einfach:

/templates/2k11/admin/ckeditor_custom_config.js /templates/2k11/admin/ckeditor_custom_plugin.js

an, und Serendipity erkennt automatisch dass es diese beiden Dateien dann nutzen soll (sofern die Toolbar-Preset Option sagt "Ja, ich möchte die custom Dateien nutzen und nicht die integrierten Presets").

Eine alte im Raum stehende Variante wäre, dass wir diese internen Presets allesamt in:

/htmlarea/htmlarea/ckeditor_config.js /htmlarea/htmlarea/ckeditor_plugin.js

abspeichern und von da aus ziehen, dann wird dem User auch klarer, dass er wenn er daran was anpassen will sie in

/templates/2k11/admin/ckeditor_custom_config.js /templates/2k11/admin/ckeditor_custom_plugin.js

speichert. Nachteil ist aber dass der User dann plötzlich Verzeichnisse wechseln muss, und auch ggf. gar nicht weiß welches Templateverzeichnis seinem aktiven entspricht.

Wenn ich dich hier nun richtig verstehe, meinst du ja explizit die select box (NAMEN) unter "Eigene Einstellungen", mit der man Basic, Standard, Full oder Preset Toolbars für das Serendipity Backend wählen kann. Natürlich, das soll ja auch dazu "verleiten" sich eine persönliche Toolbar auszuwählen und das einfach per KLICK ohne irgendeine Datei anzufassen. Das ist ja die Ursache meiner Bemühungen, das dies einfach möglich ist.

Korrekt, und es ist ein völlig valides Argument zu sagen, man sollte die User besser NICHT verleiten dazu ihre Toolbar anzupassen weil man damit jede Menge Crap anfangen kann. Das ist ein Argument was man stehen lassen kann, soll und MUSS. Man kann es nicht zerreden, es ist ein gültiges Argument. Aber im Sinne von Serendipity möchte ich das gerne mit meinem Argument kontern, dass ich dem User die Möglichkeit bieten möchte, weil unser System auf Wahlfreiheit basiert.

Welche wir nun als Default Toolbar vorgeben, bevor einer über "Eigene Einstellungen" seine persönliche Auswahl trifft, sollten wir überlegen. Ich persönlich wäre für die Standard Toolbar.

Soweit ich verstanden habe, gab es sinnvolle Diskussionen dazu wie die aktuelle Standard-Toolbar aussieht. Bitte nennt mir dann konkret die Unterschiede zur Standard-Toolbar, und wenn dort neue Buttons hinzukommen sollen oder welche entfallen, würde ich gerne die Argumente dafür/dagegen hören. Ansonsten möchte ich allein deshalb bei der aktuellen Toolbar bleiben, weil Sie auf Erfahrungswerten von onli und vermutlich auch Matthias basiert.

Ich möchte bewusst KEINE CKE Standardtoolbar, weil die ihre Toolbar auf CMS-Belange ausrichten, und wir bislang eine nutzen (so verstehe ich es) die auf den Kontext von Blogs/Serendipity/Markuppplugins optimiert ist.

Die Diskussion über "welche Buttons nehmen wir" würde ich sonst gerne auch separat auslagern, bitte antworte da erstmal nicht weiter drüber solange nicht die anderen Dinge verstanden/implementiert/angepasst - das ist erstmal Prio1, um diese Buttonsache können wir uns danach kümmern. Mir zerfasert das ganze hier schon zu stark.

VG, Garvin