CMSimple und Webstandards 7 - Plugins

[Gert]

Hallo Viol,
ich habe eine Xhtml-valide Version von gbook. Die Kontaktaufnahme mit dem Urheber verlief jedoch weniger glücklich. Der Urheber erlaubt eine Weiterbearbeitung seiner Plugins ohne seine Genehmigung ausdrücklich nicht. Ohne Einverständnis des Urhebers will ich jedoch das modifizierte Plugin nicht zum Download anbieten, das gehört sich nicht und ist auch rechtlich bedenklich. Deshalb habe ich meine Aktivitäten hinsichtlich gbook eingestellt. Es wird also von mir keine html- oder (X)html-valide Version von gbook geben.

Du musst Dich also an den Urheber (http://www.qualifire.de/cmsimple/?Willkommen) wenden, damit er sein Plugin entsprechend überarbeitet oder ein anderes Plugin nutzen, wenn Du auf valide Seiten Wert legst, z. B. uBlog.

Das Plugin uBlog habe ich mit dem Einverständnis des Urhebers modifiziert, es ist in einer html-validen und einer Xhtml-validen Version verfügbar: http://www.ge-webdesign.de/cmsimple/?Do ... ugin_uBlog .

Hier gibt es auch eine (X)html-valide Version von gallery als beta: http://www.ge-webdesign.de/cmsimple/?Do ... in_gallery , mit einigen neuen Funktionen wie e-mail-Benachrichtigung des Admin bei neuen Kommentaren, wahlweise Anordnung der Kommentare (aufsteigend oder absteigend) usw.

[Holger]

Leute, Leute,

wenn ich sehe was hier so los getreten wurde, mache ich mir langsam Sorgen wohin das noch alles führen wird.

Grottenschlecht ist gbook 314 Errors, 7 warning(s)
Gallery :8 Errors, 2 warning(s)
Faq: 18 Errors

Wie gehe ich denn nun am besten vor, um die Fehler auszumerzen?

@Viol:
Der beste Weg wäre die Fehler zu finden und Sie ordentlich dokumentiert dem Autor zur Verfügung zu stellen. Sofern der
Autor, wie im Fall von gbook, das Plugin noch weiter unterstützt.
So ähnlich ist das hier im Fall von Softlys kissGallery auch passiert.
Ich hoffe er wird die Änderungen einpflegen und eine neue Version 0.5 heraus bringen.

Es ist ja schön, gut und richtig das Markus die Erlaubnis im Falle seines uBlog gegeben hat, nur überlegt Euch bitte einmal in welchem Chaos
das enden soll:
Wir haben nun zwei uBlog - Plugins, aus unterschiedlichen Quellen und mit unterschiedlichem, wenn auch nun validem, Code.
Und noch viel schlimmer: Auch noch mit unterschiedlicher Funktionalität.

Vom Gallery-Plugin will ich gar nicht reden. Gerts Version ist dann eine weiter Variante mit gleichem Namen, basierend auf einem Entwicklungsstand mit allen Problemen der Version 0.9.
Aber vielleicht finden wir ja zusammen und bringen eine gemeinsame Version heraus. Das steht aber noch in den Sternen.

Wenn Markus die Erweiterungen von Gert nicht übernehmen möchte fände ich es besser wenn das neue Plugin einen anderen Namen bekäme
und sich getrennt vom Original weiter entwickeln würde. GE_uBlog klingt doch auch ganz anständig . Allerdings sollten dann auch alle
konkurierenden Variablennamen ausgetauscht werden.

Also meine klare Meinung dazu:
1. Das "offizielle" Plugin sollte in den Händen des Autors bleiben
2. Eigene Verbesserungen und Patches im Forum zur Verfügung stellen
3. Hoffen das der Autor sie übernimmt.

In der Vergangenheit wurden für aufgegebene Plugins, wie die von Svarrer, auch neue Autoren gefunden:
z.B. Calendar und Gallery. Aber auch ASForm, genizFAQ usw. Im Fall von Calendar stand ich vor kurzer Zeit genau vor dem gleichen Problem.
Eine Lösung hatte ich schon parat, trotzdem war es besser das Plugin weiter in der Hand von Tory, dem neuen Autor, zu lassen.

Denkt einmal darüber nach wie sich neue Anwender in so einem Durcheinander zurecht finden sollen.
Und dann können wir täglich fragen "woher hast Du es herunter geladen?". Ach ja, schon klar. Die Version von X hat einen Bug, der ist in Version von Z behoben, allerdings fehlt da das Feature von Y....
Vor der Vorstellung graut's mir jetzt schon. Ja und dann stellt euch einmal vor das ein Anfäger in ein und der selben Installation
Version X, Y und Z gleichzeitig installiert...

My five cent

Holger

[Gert]

Hallo Holger, immerhin sind Webstandards in CMSimple jetzt zum Thema geworden, ist doch schon mal was. Vielleicht schreckt ein vorübergehendes Chaos die Plugin-Entwickler auf und führt dann zu einer neuen Qualität.

Was uBlog betrifft habe ich Markus per mail auf dem laufenden gehalten, er weiss auch, dass er meine Version gerne übernehmen kann. Dann würde ich mein Download-Angebot sofort löschen und uBlog auf meiner WebSite in die Kategorie "externe Downloads" übernehmen, mit einem Link auf die Originalquelle. Es ist aber besser, wenn Markus noch bis Ende Dezember wartet, dann habe ich uBlog als (X)html-Version fertig (Version XH).

Ich sehe jedoch kein Problem in verschiedenen Versionen eines Plugins, solange die Datenstruktur nicht angefasst wird. Solange der Anwender meine Version installieren und seine alten Daten verwenden kann, wo liegt das Problem? Gallery ist da übrigens vorbildlich, da die Daten standardmässig ausserhalb des Plugin-Verzeichnisses abgelegt werden.

Zur Zusammenführung unserer gallery-Versionen habe ich wohl erst im Dezember Zeit, da ich Ende November noch eine Messe habe, die ich als Einzelkämpfer vorbereiten und durchziehen muss. So ist meine Zeit zwischen Urlaub und Messe wohl ausgefüllt .

[Holger]

Ich sehe jedoch kein Problem in verschiedenen Versionen eines Plugins, solange die Datenstruktur nicht angefasst wird

Du natürlich nicht. Du kennst Dich ja auch aus im Durcheinander der verschiedenen, gleichnamigen Plugins.

Denkt einmal darüber nach wie sich neue Anwender in so einem Durcheinander zurecht finden sollen.
Und dann können wir täglich fragen "woher hast Du es herunter geladen?". Ach ja, schon klar. Die Version von X hat einen Bug, der ist in Version von Z behoben, allerdings fehlt da das Feature von Y....
Vor der Vorstellung graut's mir jetzt schon. Ja und dann stellt euch einmal vor das ein Anfäger in ein und der selben Installation
Version X, Y und Z gleichzeitig installiert...

Gruß

Holger

[Gert]

Hallo Holger, mit dem Pluginloader war es doch genauso: Hier eine Version, da eine Modifikation ...

Ich glaube, dass da meine Vorgehensweise zum richtigen Ergebnis geführt hat. Beitrag im Forum schreiben, eigenen (X)html-Pluginloader zum Download anbieten, das ganze eben mit Nachdruck zum Thema machen.

Heute gibt es EINEN empfohlenen (X)html-Pluginloader und ein Archiv im WIKI, das vorübergehende Chaos hat ein Ende. Ich weiss, dass das nicht allein meine Leistung war, aber den Anstoss dazu habe ich doch irgendwie gegeben.

Auch eine gleichzeitige Installation mehrerer Plugin-Versionen in einer CMSimple-Installation ist eigentlich ausgeschlossen, solange diese Versionen den gleichen Namen haben. Ein Nur-Anwender wird wohl kaum einzelne Dateien aus verschiedenen Downloads auf den Server kopieren, sondern das alte Plugin löschen und das neue installieren. Gerade deshalb ist es wichtig, dass die Daten nicht im Plugin-Verzeichnis liegen, sondern wie bei "gallery" eben woanders, damit sie beim löschen des alten Plugins oder der alten Plugin-Version nicht versehentlich mit weg sind.

Solange also die Daten nicht im Plugin-Verzeichnis liegen und von allen Versionen eines Plugins genutzt werden können, sehe ich weiterhin kein Problem.

Das zeigt aber wieder die Notwendigkeit einer Entwickler-Dokumentation, da könnte dann z. B. vorgegeben werden, dass Plugin-Daten in einem bestimmten Verzeichnis ausserhalb des Plugin-Ordners abzuspeichern sind, z. B.:

cmsimple/plugindata/ublog/ oder
cmsimple/plugindata/gallery/ usw.

Auch solche Dinge wie "tag( )" gehören da rein.

Dazu müssten sich ein paar Leute finden, die das ganze mal theoretisch aufarbeiten und so eine Entwickler-Dokumentation für CMSimple-Plugins erstellen. Ich selbst weiss noch zu wenig über Plugin-Programmierung, um mir da den Hut aufzusetzten, wäre aber gerne bereit, mitzuarbeiten und Ideen zu liefern. Und dabei weiter zu lernen

[Holger]

Dazu müssten sich ein paar Leute finden, die das ganze mal theoretisch aufarbeiten und so eine Entwickler-Dokumentation für CMSimple-Plugins erstellen.

Das Sache ist angestoßen, wenn auch noch nicht wirklich spruchreif:
http://www.cmsimpleforum.com/viewtopic. ... rt=0#p1754

Leider beteiligen sich noch nicht viele Entwickler. Wenn's aber einmal angefangen ist wird es sicher weitere
Leute geben die sich beteiligen.

Ansonsten bleibe ich dabei: Plugins sollten nicht mit gleichem Namen verschiedene Funktionalität bieten.

Holger

[Till]

Und meiner Meinung nach sollten die Daten von Plugins nicht außerhalb des Plugins gehalten werden. Das gibt sonst ein riesiges Durcheinander mit den verschiedensten CMSimple Unterverzeichnissen. Wenn jemand Updates machen möchte, dann sollte er wissen, den Content Folder seines alten Plugins zu behalten. Und ich glaube, das war bisher auch nocht nie ein Problem.

Till

[Holger]

Und meiner Meinung nach sollten die Daten von Plugins nicht außerhalb des Plugins gehalten werden.

+1

Holger

Edit: Aber das Gallery-Plugin macht es schon besser: Das Verzeichnis wird, abhängig vom Funktionsaufruf, angelegt wo der User es möchte. Das Plugin macht somit keinerlei Vorschriften wo die Daten abzulegen sind.

[Gert]

Das gibt sonst ein riesiges Durcheinander mit den verschiedensten CMSimple Unterverzeichnissen.

Deshalb habe ich ja vorgeschlagen, im CMSimple-Root ein Verzeichnis "plugindata" einzurichten (so wie es die Verzeichnisse "content" und "downloads" gibt), in dem dann jedes Plugin ein Unterverzeichnis hat.

Wenn man dann eine neue Version des Plugins drüberbügelt (das kann ein ganz normales Update sein) werden die Daten oder die Inhalte des Plugins davon garantiert nicht berührt. Wir alle wissen, wie wichtig Datensicherung ist, aber jedem von uns ist es sicher schon einmal passiert, dass er da ein wenig nachlässig war und Daten weg oder überschrieben waren. Ich meine das nicht nur auf CMSimple bezogen. Gerade einem unerfahrenen Anwender kann sowas bei einem Update schon mal passieren, wenn das Daten- oder Content-Verzeichnis nicht geschützt oder woanders ist.

Ich habe jedenfalls schon bei meinem ersten DOS-Lehrgang Anfang der 90er gelernt, dass man Programme und Daten strikt trennen sollte. Das erste bei der Einrichtung eines neuen PC ist die Einrichtung eines Datenpfades oder -Laufwerks, dann bewegt man jedes Programm dazu, alle Daten in Unterverzeichnissen dieses Datenpfades oder -Laufwerks abzulegen. Das erleichtert dann auch die Datensicherung enorm. In Windows gibt es dafür das Verzeichnis "eigene Dateien", das mittlerweile fast alle Windows-Programme bedienen.

Insofern wäre es sogar sinnvoll, die Unterverzeichnisse der Plugin-Daten im Verzeichnis CMSimpleRoot/content/ anzulegen. Dann kann man alle Content-Daten, CMSimple und Plugins, in einem Zug sichern.

So wie bei gallery, das ein Verzeichnis "gallery" direkt im CMSimple-Root erzeugt bzw. nutzt, würde natürlich ein ungeordnetes Sammelsurium an Unterverzeichnissen im CMSimple-Root entstehen. So sollte es auch nicht sein, ich habe das nur als Beispiel angeführt, weil gallery das einzige mir bekannte Plugin ist, das im Originalzustand und in der Bedienungsanleitung die Daten nicht im Plugin-Verzeichnis ablegt.

Wer sich mit CMSimple-Scripting auskennt kann ja die Plugin-Daten sowieso hinlegen, wo er will. Es geht mir mal wieder nur um die Standardlösung (Auslieferungszustand, Bedienungsanleitung, bei gallery: help.htm)

[mvwd]

Hallo zusammen,

Und dann können wir täglich fragen "woher hast Du es herunter geladen?". Ach ja, schon klar. Die Version von X hat einen Bug, der ist in Version von Z behoben, allerdings fehlt da das Feature von Y....
Vor der Vorstellung graut's mir jetzt schon. Ja und dann stellt euch einmal vor das ein Anfäger in ein und der selben Installation
Version X, Y und Z gleichzeitig installiert...

....da muss ich Holger Recht geben. Gerade als Entwickler, der dann doch mal um Unterstützung gebeten wird, sollte man wissen, mit welcher Version der Anwender denn nun arbeitet. "Fremde" Versionen zu supporten ist quasi unmöglich.
Das habe ich bisher so nicht realisiert. Daher werde ich den "neuen" (X)HTML-uBlog gerne (sofern von Gert erlaubt/gewünscht) als neue offizielle Version (vermutlich dann V.0.87) auf meiner Homepage hinterlegen.Dann kriegt Gert auch endlich seinen Link als Dankeschön .

mvwd.