TinyMCE4 für Version 1.7

[manu]

Hallo Gemeinde
Neben der Tatsache, dass der TinyMCE4 standardmässig mit der Version 1.7 ausgeliefert wird, hier noch einige Infos zum wiewowas des TinyMCE:
Die Infos zu den Download- und Sourcefiles ist immer noch wie hier.

• Ich werde mich erdreisten, bei den aktuellen Versionen die config.php ohne Versionsänderung wieder zu integrieren. Damit wäre die Frage gelöst, weshalb kein Config Menü erscheint und bei den Updates werden wir wieder stöhnen, weshalb die config.php wieder überschrieben wurde. IMHO sollte beim Vorhandensein von defaultconfig.php (auch ohne config.php) das Config Menü erscheinen, aber das ist eine andere Geschichte.
• Die Frage/Diskussion, ob die CDN oder die Download Version der Standard ist, sollte in einem separaten Thread abgehandelt werden.
• Die Frage/Diskussion, ob nur die zwei Standardsprachen oder wie bisher rund ein Dutzend Sprachen angeboten werden sollen, sollte in einem separaten Thread abgehandelt werden.
• Bei den zwei obigen Punkten sollte vorab die Frage geklärt werden, ob wir nach wie vor auf schlank stehen (TinyMCE4 ~500KB, langs ~170KB, FA Plugin ~800KB).

Konkrete Fehler/feature requests werden auf dem Github Account prompt behandelt.
Beste Grüsse
manu

[cmb]

Neben der Tatsache, dass der TinyMCE4 standardmässig mit der Version 1.7 ausgeliefert wird, hier noch einige Infos zum wiewowas des TinyMCE:
[…]

Danke!

Unklar ist mir aber leider immer noch, ob nun manu37/tinymce4 oder cmsimple-xh/cmsimple-xh/plugins/tinymce4 die aktuellste Version enthalten. Mir scheint, in beiden Repos wurden unterschiedliche Commits vorgenommen.

Damit wäre die Frage gelöst, weshalb kein Config Menü erscheint und bei den Updates werden wir wieder stöhnen, weshalb die config.php wieder überschrieben wurde.

Letzteres muss ja nicht sein; die Update-Pakete für CMSimple_XH enthalten schon seit langem keine config.php und Sprachdateien mehr, sondern nur defaultconfig.php und default.php. Und das kann auch für individuelle Plugins entsprechend gehandhabt werden.

Die Frage/Diskussion, ob die CDN oder die Download Version der Standard ist, sollte in einem separaten Thread abgehandelt werden.

Kann von mir aus gerne neu diskutiert werden, aber eigentlich hatten wir darüber schon abgestimmt und von mir aus kann's auch gerne dabei bleiben.

Die Frage/Diskussion, ob nur die zwei Standardsprachen oder wie bisher rund ein Dutzend Sprachen angeboten werden sollen, sollte in einem separaten Thread abgehandelt werden.

Dazu gibt es bereits https://github.com/manu37/tinymce4/issues/13; eine Diskussion im Forum ist aber vielleicht zusätzlich sinnvoll. Jedenfalls denke ich, dass das in der CMSimple_XH Standarddistribution alle Plugins gleich halten sollten, und seit langer Zeit ist es so, dass eben nur en und de ausgeliefert werden. Wie individuelle Plugins das handhaben, ist letztlich die Entscheidung des oder der Entwickler.

Bei den zwei obigen Punkten sollte vorab die Frage geklärt werden, ob wir nach wie vor auf schlank stehen (TinyMCE4 ~500KB, langs ~170KB, FA Plugin ~800KB).

Ein bisschen stört es mich auch, dass XH 1.7 doch recht aufgebläht daher kommt. Daher auch meine Bemerkung im Release-Announcement von XH 1.7.0beta1:

An diejenigen, die Bedenken wegen der Download-/Installationsgröße haben: der Standard-Download enthält eine Menge Zeug, das nicht unbedingt benötigt wird. Beispielsweise können alle Templates entfernt, und durch ein eigenes ersetzt werden, und Ihr könnt auch alle Plugins entfernen. Auf diese Weise kann eine minimale Installation immer noch weniger als 1 MB (entpackt) benötigen.

Will sagen: derzeit ist höchstens der Download des ZIP ein Problem, aber ich denke, das ist auch bei einer langsamen Internetverbindung kein wirkliches Problem, da man das ZIP ja nur einmal herunter laden, und eben nicht alle Komponenten auf den eigenen Server hochladen muss.

Eine Alternative wäre vielleicht etwas in der Art des Packagers.

Aber mal ehrlich: macht es heutzutage noch viel Sinn ein CMS zu bewerben, weil es einen winzigen Footprint hat?

[manu]

Neben der Tatsache, dass der TinyMCE4 standardmässig mit der Version 1.7 ausgeliefert wird, hier noch einige Infos zum wiewowas des TinyMCE:
[…]

Danke!

Unklar ist mir aber leider immer noch, ob nun manu37/tinymce4 oder cmsimple-xh/cmsimple-xh/plugins/tinymce4 die aktuellste Version enthalten. Mir scheint, in beiden Repos wurden unterschiedliche Commits vorgenommen.

Damit wäre die Frage gelöst, weshalb kein Config Menü erscheint und bei den Updates werden wir wieder stöhnen, weshalb die config.php wieder überschrieben wurde.

Letzteres muss ja nicht sein; die Update-Pakete für CMSimple_XH enthalten schon seit langem keine config.php und Sprachdateien mehr, sondern nur defaultconfig.php und default.php. Und das kann auch für individuelle Plugins entsprechend gehandhabt werden.

Ich glaube, die Plugin Anbieter sind noch selten, die eine fullversion und update Version anbieten. Wenn Du mir mal zeigst, wie ich von GitHub nur die geänderten Dateien selektieren kann, dann wäre es eine Überlegung wert.

Die Frage/Diskussion, ob die CDN oder die Download Version der Standard ist, sollte in einem separaten Thread abgehandelt werden.

Kann von mir aus gerne neu diskutiert werden, aber eigentlich hatten wir darüber schon abgestimmt und von mir aus kann's auch gerne dabei bleiben.

So wie ich die Abstimmung verstehe wurde für die CDN Version entschieden. Im code ist aber immer noch die TinyMCE Library drin und in required_classes.php auf "full version" gestellt.

Bei den zwei obigen Punkten sollte vorab die Frage geklärt werden, ob wir nach wie vor auf schlank stehen (TinyMCE4 ~500KB, langs ~170KB, FA Plugin ~800KB).

Ein bisschen stört es mich auch, dass XH 1.7 doch recht aufgebläht daher kommt. Daher auch meine Bemerkung im Release-Announcement von XH 1.7.0beta1:

An diejenigen, die Bedenken wegen der Download-/Installationsgröße haben: der Standard-Download enthält eine Menge Zeug, das nicht unbedingt benötigt wird. Beispielsweise können alle Templates entfernt, und durch ein eigenes ersetzt werden, und Ihr könnt auch alle Plugins entfernen. Auf diese Weise kann eine minimale Installation immer noch weniger als 1 MB (entpackt) benötigen.

Will sagen: derzeit ist höchstens der Download des ZIP ein Problem, aber ich denke, das ist auch bei einer langsamen Internetverbindung kein wirkliches Problem, da man das ZIP ja nur einmal herunter laden, und eben nicht alle Komponenten auf den eigenen Server hochladen muss
......

All diese implementierten Libraries müssen gewartet und auf dem neuesten Stand gehalten werden. Diese Mühe (und auch Angriffsfläche) finde ich unnötig. Beim tiny gibt es alle 2 Monate mindestens 1 Update...

Aber mal ehrlich: macht es heutzutage noch viel Sinn ein CMS zu bewerben, weil es einen winzigen Footprint hat?

Mir ist der footprint auch nicht erstes Gebot. Aber wenn ich praktisch bei jedem Aufruf ins Backend wieder eine Komponente upzudaten habe, finde ich das eher mühsam. Bei mir gehts noch, aber der simple User und Userin (und das sind bei mir die Mehrheit) sind überfordert ein Update selbständig zu machen. Wenn wir auch dieser Schiene fahren wollen, sollten wir uns bald einmal Gedanken über einen Modul Manager machen (womit die ganze chose wieder umfangreicher wird ).

[cmb]

Ich glaube, die Plugin Anbieter sind noch selten, die eine fullversion und update Version anbieten. Wenn Du mir mal zeigst, wie ich von GitHub nur die geänderten Dateien selektieren kann, dann wäre es eine Überlegung wert.

Ich habe das bis vor einer ganzen Weile mit einem kleinen Shell-Script erledigt, bin aber schon bei einigen Plugins auf entsprechende Phing-Targets umgestiegen (CMSimple_XH übrigens auch). Zunächst wird das `build` Target mit Versionsnummer aufgerufen, das ein fertiges Zip erstellt, und danach bei Bedarf das `build-patch` Target mit Versionsnummer und dem Pfad eines vorherigen Zips, das das Update Zip erstellt. Ich finde, der Aufwand diese Phing-Targets (oder entsprechend andere Build-Scripte) zu erstellen, zahlt sich schnell aus (zumal sie für jedes Plugin fast identisch sein können) – und, nota bene: ich entwickle komplett in einem Git-Clone, und teste die erstellten Zips schon seit langem nicht mehr; sprich, kein doppelter Testaufwand. Klar bleibt das Risiko, dass beim Build was schief geht, und ich ein nicht funktionierendes Plugin ausliefere, aber bisher kam das wohl noch nicht vor.

So wie ich die Abstimmung verstehe wurde für die CDN Version entschieden. Im code ist aber immer noch die TinyMCE Library drin und in required_classes.php auf "full version" gestellt.

Na ja, das Ticket hat auch das Label "to be implemented", und ich hatte dir das zugewiesen.

Aber wenn ich praktisch bei jedem Aufruf ins Backend wieder eine Komponente upzudaten habe, finde ich das eher mühsam. Bei mir gehts noch, aber der simple User und Userin (und das sind bei mir die Mehrheit) sind überfordert ein Update selbständig zu machen.

Da stimme ich zu. So gesehen habe ich auch nichts gegen CDN, aber zum Beispiel bei FontAwesome müsste ich dennoch eine bestimmte Version ziehen (lassen), da sonst die Editor-Plugins u.U. plötzlich nicht mehr mitspielen. Sprich, wenn eine neue FontAwesome Version veröffentlicht wird, dann müssen auch die Editor-Plugins Updates erfahren, siehe https://github.com/cmb69/fa_xh/blob/1.0 ... PDATING.md und https://github.com/cmb69/fa_xh/blob/1.0 ... PDATING.md. Beim Pagemanager_XH 3 könnte ich jstree wohl per CDN nutzen, obwohl ich nicht sicher bin, wie sauber dort SemVer umgesetzt wird; bei den vorigen Versionen war das aber sowieso nicht möglich, weil es keine jstree Updates mehr gab, und ich selbst patchen musste.

[…], sollten wir uns bald einmal Gedanken über einen Modul Manager machen (womit die ganze chose wieder umfangreicher wird ).

Oh, ja, einfach wird das sicher nicht, aber langfristig kommen wir da sowieso nicht drumherum – in welcher Form auch immer.