Umfrage: Unter CMS/ms-1 regelmäßig genutzte Module und Plugins

Andynium · 03. April 2016 07:23

Klenkes schrieb:

Aber wäre es nicht logisch gewesen bei dieser Gelegenheit gleich zu implementieren, dass man das Profil beim ContentBlock in der Template mit angeben kann, damit jeder Block mit Tiny eine andere Konfiguration hätte.

Das Feature gefällt mir, und geht mir einfach nicht mehr aus dem Kopf.

Nach meinen Recherchen ist es schon möglich, verschiedene Instanzen (=TinyMCE mit verschiedenen Konfigurationen) zu starten.

Ist nur die Frage, wie man das am gescheitesten in CMSMS-1 inkludiert.

jeff1980 · 03. April 2016 09:55

cyberman schrieb:

jeff1980 schrieb:
ListIt2*
ListIt2XDefs
Hatten es zwar bereits an anderer Stelle besprochen, ist aber vllt untergegangen ... der Quasi-Nachfolger LISE (=ListIt Special Edition ) hat die Funktionalität von ListIt2XDefs bereits inkludiert .

Stimmt, hab ich auch vor kurzem gesehen und mich aufgrund dieses Threads mal bei meiner eigenen Seite getraut. Dachte immer, dass LISE nur für CMSms 2.x entwickelt wurde.
Die Umstellung bei einem einfachen Portfolio hat gut geklappt. Mehr Sorgen machen mir Seiten, bei denen der Formbuilder etwas in das Modul schreibt. Sollte ja grundsätzlich auch klappen, muss ich mir "nur" mal anschauen smile
Im Moment hapert es wieder am Faktor Zeit ... ständig diese Veränderungen ... wink

Andynium · 04. April 2016 19:39

jeff1980 schrieb:

Dachte immer, dass LISE nur für CMSms 2.x entwickelt wurde.

Nee, das hast du dir falsch gemerkt wink .

Das (nicht mehr vorhandene) Modul EasyList war als reines 2.x-Modul geplant, nachdem klar war, dass LI2 nicht weiter entwickelt wird.

LISE dagegen lief von Anfang an unter 1.x und 2.x ...

Dancer62 · 08. April 2016 09:38

Klasse Idee smile

Meine hauptsächlich genutzten Module sind :

AdvancedContent
Archiver
CGCalendar
CGExtensions
CGSimpleSmarty
Captcha
FAQ
FormBuilder
FrontEndUsers
Gallery
Glossary
ListIt2 (zukünftig voraussichtlich LISE)
Showtime
SiteMapMadeSimple
TinyMCE
ToolBox
Uploads
youtubeplayer

Sieht zwar immens viel aus, aber ich nutze die Module tatsächlich...

Andynium · 08. April 2016 13:21

Danke an alle für eure bisherigen Wortmeldungen!

Ist eine wirklich interessante Liste geworden - manches erwartet, manches überraschend. Und mit 1/20 der Forge-Listungen zudem deutlich übersichtlicher big_smile .

Ok, nächster Schritt:

Wie sollten denn nach eurer Meinung die Informationen strukturiert (und präsentiert) werden? Und vor allem - welche Informationen und Funktionalitäten sollten dort vorhanden sein?

Im Forge gibt es ja die Aufteilung Summary, Files, Bug Tracker, Feature Requests und Code. Jedoch sollte (zumindest nach meiner gegenwärtigen Vorstellung) unser Erweiterungs-Depot keine bloße Kopie dessen auf deutsch werden. Zudem können bestimmte Dinge nicht bzw. nur in eingeschränktem Umfang geleistet werden, wie z.Bsp. die Feature Requests und Bug Reports. Wobei andererseits Hinweise auf Bugs oder gewünschte Features und deren mögliche Lösungsmöglichkeiten durchaus interessant wären.

Und auch der Blick über den Tellerrand (Wordpress) mit Description, Installation, FAQ, Screenshots, Changelog, Stats, Support, Reviews und Developers gefällt mir zwar, ist aber auch deutlich zu komplex.

Description ist in der Regel schnell abgehandelt und könnte quasi als Einleitung stehen, zusammen mit dem Link auf den Download (wobei ich mir noch nicht sicher bin, ob das nur ein Deep Link werden soll oder wir das besser selber hosten - für den Fall, dass der Ursprungslink aus was für Gründen auch immer plötzlich "verschwindet"). Installation ist meist mit einem Mausklick erledigt und kaum erwähnenswert. Changelog, Stats und Developers wird eh nur zu selten gelesen. Hmm, und ob ein FAQ für jede Erweiterung Sinn macht, wage ich auch zu bezweifeln.

Ich tendiere daher zu maximal 4 Sektionen

- Wie wird die Erweiterung eingesetzt, sozusagen adäquat zur Modul-/Tag-Hilfe.
- mögliche Parameter (mit Beispiel-Output bzw. Screenshots)
- ein Foren-ähnlicher Supportbereich
- und allenfalls vllt Templates (?

Jetzt seid ihr wieder dran wink ...

Klenkes · 08. April 2016 13:34

Ich sage dazu nur 3 Worte:
Abhängigkeiten - Abhängigkeiten - Abhängigkeiten

Beitrag geändert von Klenkes (08. April 2016 14:02)

Andynium · 08. April 2016 13:47

Sorry, es ist Freitag - keine Ahnung, was du meinst.

NaN · 08. April 2016 13:55

Er meint bestimmt Abhängigkeiten wink
Also es sollte irgendwo vor dem Download zu sehen sein, was ein Modul zusätzlich noch so benötigt. (Andere Module, PHP-Version ...)

Dancer62 · 08. April 2016 14:05

NaN schrieb:

Er meint bestimmt Abhängigkeiten
Also es sollte irgendwo vor dem Download zu sehen sein, was ein Modul zusätzlich noch so benötigt. (Andere Module, PHP-Version ...)

Das "n" liegt auf der Tastatur ja auch unfairerweise direkt neben dem "b"... big_smile

Klenkes · 08. April 2016 14:06

Genau das meinte ich. Abhängigkeiten.
Anhängigkeiten??? (Die Stimmen in meinem Kopf befehlen mir manchmal Dinge zu schreiben...)

Das ist doch ein häufiges Problem, dass diese Version nicht zu jener passt, und Modul-Y 7 weitere voraussetzt, die aber nicht installiert werden können, weil die PHP Version nicht hoch oder niedrig genug ist.

Andynium · 08. April 2016 14:11

Pfff, abhängige Module machen Sinn cool . Auf jeden Fall ein Muss.

Bei den PHP-Versionen ist es allerdings schon bißle aufwendig, entweder jede Erweiterungen nach den verwendeten PHP-Befehlen zu durchforsten, und damit auf die erforderliche PHP-Version zu schließen oder aber jede der genannten Erweiterungen auf alle mehr oder weniger aktuelle PHP-Versionen komplett durchzutesten (denn es steht ja (leider) nirgendwo). Könnte da allenfalls hinschreiben "Getestet mit PHP 5.6.x".

Oder habt ihr da noch eine Idee für ein alternatives Testscenario?

Dancer62 · 08. April 2016 14:16

cyberman schrieb:

Ich tendiere daher zu maximal 4 Sektionen
- Wie wird die Erweiterung eingesetzt, sozusagen adäquat zur Modul-/Tag-Hilfe.
- mögliche Parameter (mit Beispiel-Output bzw. Screenshots)
- ein Foren-ähnlicher Supportbereich
- und allenfalls vllt Templates ?

Ich würde außerdem ein Changelog hinzufügen, zumal wenn es Änderungen am Modul gegeben hat, die u.U. eine Änderung am eigenen Template nach sich ziehen (z.B. geänderte / neue Funktionen). Habe ich kein Changelog, weiß ich auch nicht, warum sich das Modul plötzlich anders verhält als erwartet.
Ansonsten habe ich bei den meisten Modulen im Forge eine aussagekräftige Beschreibung der Fähigkeiten vermisst. Der kurze Satz "...vereinfacht die Eingabe des Users..." ist nicht wirklich hilfreich. Aber das könnte ja mit der ersten Strichaufzählung behoben werden.

Andynium · 08. April 2016 15:45

Dancer62 schrieb:

Ich würde außerdem ein Changelog hinzufügen, zumal wenn es Änderungen am Modul gegeben hat, die u.U. eine Änderung am eigenen Template nach sich ziehen (z.B. geänderte / neue Funktionen). Habe ich kein Changelog, weiß ich auch nicht, warum sich das Modul plötzlich anders verhält als erwartet.

Ist ein Argument.

Aber das Changelog kann man ja über die Modulübersicht in der Administration eigentlich ganz gut einsehen. Im Depot würde man da auch nur eine 1:1 Kopie davon sehen können, denn ich (oder wer immer sich bereit erklärt, diese Aufgabe zu übernehmen) weiß da ja auch nicht mehr. Zudem kommt es dann immer noch darauf an, ob der Autor der Erweiterung da etwas Gescheites reinschreibt. Wenn ich da an "some bug fixes" denke, die die Funktionalität komplett auf den Kopf stellt...

Aber ok, gibt dem ganzen einen professionelleren Anstrich.

Dancer62 schrieb:

Ansonsten habe ich bei den meisten Modulen im Forge eine aussagekräftige Beschreibung der Fähigkeiten vermisst. Der kurze Satz "...vereinfacht die Eingabe des Users..." ist nicht wirklich hilfreich. Aber das könnte ja mit der ersten Strichaufzählung behoben werden.

Ja, genau das war das Ansinnen big_smile .

Andynium · 12. April 2016 08:42

cyberman schrieb:

Wie sollten denn nach eurer Meinung die Informationen strukturiert (und präsentiert) werden? Und vor allem - welche Informationen und Funktionalitäten sollten dort vorhanden sein?

Weitere Gedanken / Ideen / Vorschläge?

nockenfell · 12. April 2016 09:28

Möglichst die gesamte Modul-History. Sprich

v0.1
v0.2
v0.3
etc...

Damit kann man je nach dem auch auf eine frühere Version aktualisieren. Bei älteren CMSMS Installationen kann man bei Updates nicht direkt auf die neuste Version aktualisieren. Zusätzlich wäre bei den einzelnen Versionen hilfreich, wenn die maximal / minimal getestete CMSMS Version erhalten bleibt. So sieht man, welche Version mit welcher CMSMS Version eingesetzt werden kann.

Andynium · 12. April 2016 11:51

nockenfell schrieb:

Möglichst die gesamte Modul-History

Bei einem Großteil der Module sicherlich kein Problem, nur bei CGExtension stellt sich da bei mir spontanes Unwohlsein ein tongue .

nockenfell schrieb:

Zusätzlich wäre bei den einzelnen Versionen hilfreich, wenn die maximal / minimal getestete CMSMS Version erhalten bleibt. So sieht man, welche Version mit welcher CMSMS Version eingesetzt werden kann.

Meinst du damit die Werte aus den Funktionen MinimumCMSVersion() und MaximumCMSVersion()?

Janl · 12. April 2016 12:13

Nur eine Frage.

Wer hat so viel Zeit dass Sie/Er alle Kombinationen von CMS-core + Modulen + PHP testen kann?

CMS Core von 1.9 bis 2.1.2 - 37 Versionen
PHP 5.3 bis 7(?) - minimal 6 Versionen
Modul FEU 1.21.13 bis 1.30.6 - 25 versionen

Ergibt minimal 37 * 6 * 25 = 5550 Kombinationen mit nur 1 Module.

Unmöglich meiner Meinung nach.

MfG
Jan

Andynium · 12. April 2016 12:18

Ganz meine Meinung, Jan. Werden ja schon jetzt nicht fertig mit unseren ToDos ... deswegen ja auch meine Frage:

cyberman schrieb:

Bei den PHP-Versionen ist es allerdings schon bißle aufwendig, entweder jede Erweiterungen nach den verwendeten PHP-Befehlen zu durchforsten, und damit auf die erforderliche PHP-Version zu schließen oder aber jede der genannten Erweiterungen auf alle mehr oder weniger aktuelle PHP-Versionen komplett durchzutesten (denn es steht ja (leider) nirgendwo). Könnte da allenfalls hinschreiben "Getestet mit PHP 5.6.x".
Oder habt ihr da noch eine Idee für ein alternatives Testscenario?

... oder irgend etwas anderes, was das ganze handhabbarer macht.

Andynium · 12. April 2016 12:35

Janl schrieb:

CMS Core von 1.9 bis 2.1.2 - 37 Versionen

Würde es da nicht so übertreiben wollen und auf den Smarty3-relevanten Part beschränken, also ab 1.11 und dann auch nur auf die primäre Serie, also 1.11 oder 1.12. Da wären es nur noch 2.

Janl schrieb:

PHP 5.3 bis 7(?) - minimal 6 Versionen

CMSMS-1 läuft (noch) nicht unter PHP 7, und PHP 5.3 ist tot. Wobei ich bei PHP 5.5/5.6 bislang noch keinen Unterschied für CMSMS habe erkennen bzw. feststellen können, so dass man das evtl zusammen fassen könnte. Wären wir auch hier bei 2.

Janl schrieb:

Modul FEU 1.21.13 bis 1.30.6 - 25 versionen

Die CG-Module spielen da IMHO eine Sonderrolle, würde ich genau so wie die CMSMS-Version handeln, also maximal 1.21 bis 1.30, und nur das, was für Smarty 3 relevant ist.

Oder wie ich Nockenfells Vorschlag verstanden hab - einfach die Angaben aus dem Modul nehmen (MinVersion, MaxVersion)

Janl schrieb:

Ergibt minimal 37 * 6 * 25 = 5550 Kombinationen mit nur 1 Module.

Ja ich, weiß - immer noch zu viele Möglichkeiten, zumal man ja die Funktionalitäten eh nicht so komplett durchtesten kann, wie rafinierte Webseiten-Bauer dies tun wink .

Janl · 12. April 2016 13:08

Vielleicht nicht testen aber nur zusammen bringen was alle Mitglieder hier an Installationen haben. Dann darf man erwarten dass diese Kombinationen getestet sind.

Noch einfacher wäre 1 Forumteil wo Fragen zur Versionenkombinationen gestellt werden können und wo erprobte Kombinationen als Thread gelistet sind.
Dann kostet es den Einzelnen kaum Zeit.

MfG
Jan

Andynium · 12. April 2016 13:16

Hmm, bei der großen Anzahl an möglichen Kombinationen wird es dann IMHO aber auch recht schnell unübersichtlich und schwer durchsuch- und findbar.

nockenfell · 12. April 2016 20:33

cyberman schrieb:

Meinst du damit die Werte aus den Funktionen MinimumCMSVersion() und MaximumCMSVersion()?

Jein. In einem anderen Post wurde geschrieben, dass zusätzliche Informationen wie "getestet mit PHP 5.6" oder so gewünscht sind. Diese sind natürlich auch bei älteren Versionen interessant. Das diese Infos nicht von Anfang an zur Verfügung stehen ist klar. Mit der Zeit gibt es aber auch hier eine History.

Andynium · 13. April 2016 09:18

Die Idee gefällt mir gut - dies zu implementieren und vor allem zu pflegen, ist dann schon mit einem deutlichen Mehraufwand verbunden, insbesondere, wenn es pro Modulversion gepflegt werden soll wink .

Andynium · 07. Januar 2017 13:12

cyberman schrieb:

Von daher hatten wir ja schon vor längerem in eigenes Depot für Erweiterungen geplant.

Wer dies gelesen hat

https://www.cmsmadesimple.de/forum/view … hp?id=4869

dem dürfte klar sein, dass sich mein Ansinnen auf Erweiterungen für CMSMS-1 bezieht.

Insoweit wäre prima, wenn ihr noch die letzten, unter CMSMS-1 erfolgreich genutzten Versionen der jeweiligen Module ergänzen könntet (soweit im Ursprungspost noch nicht ergänzt).

Metamorphose · 07. Januar 2017 15:46

Hallo zusammen

Hier meine Liste der Module die im Einsatz sind:

AceEditor 1.0
Archiver 0.2.6
CGBlog 1.13.2
CGExtensions 1.49.11
CGFeedMaker 1.0.20
CGFeedback 1.7.5
CGSimpleSmarty 1.9.1
CGSmartImage 1.20.5
Captcha 0.5.2
FileBackup 0.5
FormBrowser 0.4.2
FormBuilder 0.8.1.2
Gallery 2.0.3
JQueryTools 1.3.7
MysqlDump 1.3.1
Piwik 1.0.1
SEOTools2 1.2.1
btAdminer 4.2.5

Edit: Versionsnummern ergänzt

Beitrag geändert von Metamorphose (08. Januar 2017 16:51)

Forum für CMS/made simple

#26 03. April 2016 07:23

Re: Umfrage: Unter CMS/ms-1 regelmäßig genutzte Module und Plugins

#27 03. April 2016 09:55

Re: Umfrage: Unter CMS/ms-1 regelmäßig genutzte Module und Plugins

#28 04. April 2016 19:39

Re: Umfrage: Unter CMS/ms-1 regelmäßig genutzte Module und Plugins

#29 08. April 2016 09:38

Re: Umfrage: Unter CMS/ms-1 regelmäßig genutzte Module und Plugins

#30 08. April 2016 13:21

Re: Umfrage: Unter CMS/ms-1 regelmäßig genutzte Module und Plugins

#31 08. April 2016 13:34

Re: Umfrage: Unter CMS/ms-1 regelmäßig genutzte Module und Plugins

#32 08. April 2016 13:47

Re: Umfrage: Unter CMS/ms-1 regelmäßig genutzte Module und Plugins

#33 08. April 2016 13:55

Re: Umfrage: Unter CMS/ms-1 regelmäßig genutzte Module und Plugins

#34 08. April 2016 14:05

Re: Umfrage: Unter CMS/ms-1 regelmäßig genutzte Module und Plugins

#35 08. April 2016 14:06

Re: Umfrage: Unter CMS/ms-1 regelmäßig genutzte Module und Plugins

#36 08. April 2016 14:11

Re: Umfrage: Unter CMS/ms-1 regelmäßig genutzte Module und Plugins

#37 08. April 2016 14:16

Re: Umfrage: Unter CMS/ms-1 regelmäßig genutzte Module und Plugins

#38 08. April 2016 15:45

Re: Umfrage: Unter CMS/ms-1 regelmäßig genutzte Module und Plugins

#39 12. April 2016 08:42

Re: Umfrage: Unter CMS/ms-1 regelmäßig genutzte Module und Plugins

#40 12. April 2016 09:28

Re: Umfrage: Unter CMS/ms-1 regelmäßig genutzte Module und Plugins

#41 12. April 2016 11:51

Re: Umfrage: Unter CMS/ms-1 regelmäßig genutzte Module und Plugins

#42 12. April 2016 12:13

Re: Umfrage: Unter CMS/ms-1 regelmäßig genutzte Module und Plugins

#43 12. April 2016 12:18

Re: Umfrage: Unter CMS/ms-1 regelmäßig genutzte Module und Plugins

#44 12. April 2016 12:35

Re: Umfrage: Unter CMS/ms-1 regelmäßig genutzte Module und Plugins

#45 12. April 2016 13:08

Re: Umfrage: Unter CMS/ms-1 regelmäßig genutzte Module und Plugins

#46 12. April 2016 13:16

Re: Umfrage: Unter CMS/ms-1 regelmäßig genutzte Module und Plugins

#47 12. April 2016 20:33

Re: Umfrage: Unter CMS/ms-1 regelmäßig genutzte Module und Plugins

#48 13. April 2016 09:18

Re: Umfrage: Unter CMS/ms-1 regelmäßig genutzte Module und Plugins

#49 07. Januar 2017 13:12

Re: Umfrage: Unter CMS/ms-1 regelmäßig genutzte Module und Plugins

#50 07. Januar 2017 15:46

Re: Umfrage: Unter CMS/ms-1 regelmäßig genutzte Module und Plugins

Fußzeile des Forums