CMSimple_XH 1.6.8

[olape]

Das würde ich sehr ungern tun. Wenn dann nämlich eine Supportanfrage kommt, und der User die Version 1.6.8 nennt, kann gleich nachgefragt werden: "Welche 1.6.8? Die mit oder dem Fix?"

Hm, grundsätzlich verstehe ich das schon.

Aber wenn die User sich durch Forum wühlen müssen, um den Fix zu finden, bleibt anschliessend die gleiche Frage.
Hast du schon...?
Nur für den User ist das wesentlich umständlicher.

Ich meinte als zusätzlichen Download nicht ein gesamtes neues Paket, sondern wirklich nur die eine Datei.

[cmb]

Vielleicht kann man bei zukünftigen Versionen im Backend eine Art News unterbingen.
Da könnte man solche Infos kurzfristig zur Verfügung stellen.

Vielleicht keine schlechte Idee -> hi_updatecheck -> Arbeit für Holger

Konkreter:
Updatecheck schaut nicht nur allgemein nach Updates, sondern auch irgendwo auf cmsimple-xh.org ob "News" (z.B. für Bugfixes) verfügbar sind.
Falls ja, ein Link dorthin.
Dort: Kurze Beschreibung um was es geht (siehe Post Olape).

Okay, das ist vielleicht für dringliche und kleine Fixes eine sinnvolle Sache (und vielleicht nicht nur für Fixes, sondern auch für allgemeine wichtige Hinweise). Holger, was meinst Du?

Ich meinte als zusätzlichen Download nicht ein gesamtes neues Paket, sondern wirklich nur die eine Datei.

Na ja, ich sehe eigentlich keinen wesentlichen Unterschied bzgl. des Updates, ob nun eine einzelne Datei oder ein Patch 1.6.8→1.6.9 ausgeliefert wird. Ich hab's nur mal mit dem einen Fix probiert: okay, es sind dann 12 Dateien statt nur einer einzigen, aber das Update wird trotzdem nicht wesentlich länger dauern. Und zumindest wissen alte Hasen, dass sie das Update nur über die bestehende Installation drüberbügeln müssen – ohne groß nachzulesen.

Der wesentliche Unterschied ist aber, dass diejenigen, die morgen oder später erst downloaden, gar nicht mehr patchen müssen.

[lck]

Gibt es dann für diejenigen die noch nicht auf 1.6.8 geupdatet haben, ein CMSimple_XH-update-1.6.7-to-1.6.9 Paket? Das wäre sinnvoll und zeitsparend, zumindest für den Nutzer, leider nicht für dich Christoph, den Macher

[olape]

Aber bis die 1.6.9 fertig ist, steht eine fehlerhafte Version online.
Das finde ich nicht gut.

Schaun wir mal auf MS. Wenn der Vergleich auch etwas hinkt.
Es gibt ständig Updates und irgendwann mal ein Servicepack oder wie bei Windows 10 ein ganz neues Build, in das dann alle die Änderungen gesamt einfliessen.
Ich denke das kann man schon ein wenig vergleichen.

Und einfach nur drüberbügeln ist auch nicht immer, jedenfalls bei mir.
Und ich gehe davon aus, es gibt noch den einen oder anderen, den das auch betrifft.
Aber es ist nicht mehr viel zum Glück.

[Holger]

Okay, das ist vielleicht für dringliche und kleine Fixes eine sinnvolle Sache (und vielleicht nicht nur für Fixes, sondern auch für allgemeine wichtige Hinweise). Holger, was meinst Du?

Ob wir jetzt eine oder zwei Dateien prüfen wäre ja egal.
Nur für die Umsetzung habe ich noch keine Idee. Bei der "normalen" Updateprüfung ist die Sache ja ein simpler Versionsvergleich. Auch die Auszeichnung als kritisches Update ist simpel realisiert.
Aber wie könnte man "allgemeine Hinweise" und "kleine Fixes" handhaben? Immer anzeigen, wenn serverseitig vorhanden? Wann löscht man sie dann wenn man nicht sicher sein kann, dass jeder Anwender sie gelesen hat? Vielleicht ein Timestamp mit letztem Info-Datum auf dem Client ?.

Besser ist es IMO, wenn man wirklich konsequent neue Versionsnummern vergibt. Dann kommt automatisch eine Info. Und einen allgemeinen Hinweis kann man der Meldung übrigens auch per Versions-File mitgeben.

Vielleicht wäre es sinnvoller, wenn wir für solche Zwecke eine Mailingliste eröffnen. Oder, vielleicht noch viel schöner, Jerrys Newsletter-Plugin verwenden.

[cmb]

Unter Einstellungen > Info: Dort ist immer noch der Link zu dem alten WIKI http://www.cmsimplewiki.com/
Löschen (?) oder eher ändern zu http://cmsimplewiki-com.keil-portal.de/
Ich tendiere eher dazu, den Link zu ersetzen durch Hartmuts Seite "Alles auf einen Blick" http://www.cmsimple-xh.org/de/?Alles_auf_einen_Blick

Letzteres finde ich eine gute Idee – die Info ist zwar nur auf Deutsch, aber wir haben ja schließlich sehr viele deutscher Nutzer. Ich hab's auf der Roadmap für 1.6.9 vermerkt.

Umgesetzt mit r1694.

[cmb]

wegen des jQuery-Updates: warum packen wir beim Update-Paket nicht eine config.php mit sinnvollen Einstellungen dazu? So ist das Plugin ja auch im Original-Download vorhanden. Autoload kann man abschaffen, wenn die Templates die Regeln beachten würden. Ansonsten könnte auch Autoload per default an sein und der Hinweis wäre: "Autoload gegebenenfalls nach dem Update ausschalten".

Ich hatte das bereits umgesetzt, aber dann sind mir Bedenken gekommen. Ganz egal wie Autoload vorgegeben wird, könnte es im schlimmsten Fall die Site praktisch unbenutzbar machen, so dass der User in der Konfiguration nicht mehr nachbessern kann. Das möchte ich daher ungern auf die Schnelle für 1.6.9 so machen. Für 1.6.10 können wir hoffentlich noch mal in Ruhe drüber nachdenken (und das am besten in einem eigenen Thread).

[cmb]

Beim 1.6.7>1.6.8 Patch ist mir aufgefallen, dass die Verzeichnisse/Daten nach dem Auspacken auf dem Server die Berechtigungen 0777/0666 haben. Mein Provider meckert..
Das kann sicher auf 0755/0644 geändert werden.

Scheint mit Phing zumindest unter Windows derzeit nicht machbar. Daher wieder zurück zum manuellen "Re-zippen".

[cmb]

Gibt es dann für diejenigen die noch nicht auf 1.6.8 geupdatet haben, ein CMSimple_XH-update-1.6.7-to-1.6.9 Paket?

Wäre natürlich grundsätzlich möglich, aber wo hören wir da auf? Es könnte dann entsprechend genausogut Updates von 1.6.6 auf 1.6.9 etc. geben. Und letztlich kann man sich solche Update-Pakete auch leicht selbst zusammen stellen, falls mehrere Domains aktualisiert werden sollen. Dazu einfach nacheinander die Upate-Pakete ins selbe lokale Verzeichnis entpacken (bestehende Dateien überschreiben), und zwar in ihrer chronologischen Reihenfolge. Voilà!

Schaun wir mal auf MS. Wenn der Vergleich auch etwas hinkt.
Es gibt ständig Updates und irgendwann mal ein Servicepack oder wie bei Windows 10 ein ganz neues Build, in das dann alle die Änderungen gesamt einfliessen.
Ich denke das kann man schon ein wenig vergleichen.

Na ja, eigentlich liefert MS schon lange jeweils einen Patch am Patchday (etwa Monatsmitte). Unter Win10 ist das wohl etwas flexibler, aber so mancher Bug wird eben nicht sofort behoben – evtl. wird aber zumindest ein Quick-Fix zur Verfügung gestellt. Die Info dazu muss man sich aber irgendwo suchen. Ist eigentlich nicht viel anders als bei CMSimple_XH 1.6.8. Und im Vergleich zu Windows, ist CMSimple_XH kostenlos.

Aber es ist nicht mehr viel zum Glück.

Hoffentlich schaffen wir das Stückchen noch.

Letztlich hätte der Filebrowser-Bug es eigentlich gar nicht ins Release schaffen dürfen, weil er beim Testen sofort hätte auffallen müssen. In diesem Fall liegt die Schuld bei mir; ich hatte im Juni einen wohl nicht getesteten Patch erstellt, und als ich diesen fünf Monate später eingespielt habe, habe ich wieder nicht getestet. Sorry!

Allerdings gebe ich zu bedenken, dass so mancher Bug durch manuelles Testen des Entwicklers nicht unbedingt gefunden würde. Das müsste letztlich der QS-Abteilung überlassen werden, die wir leider nicht haben, und leider haben wir auch noch immer keine vollumfängliche automatisierte Testsuite. Da besteht dringend Verbesserungsbedarf.

[Holger]

wegen des jQuery-Updates: warum packen wir beim Update-Paket nicht eine config.php mit sinnvollen Einstellungen dazu? So ist das Plugin ja auch im Original-Download vorhanden. Autoload kann man abschaffen, wenn die Templates die Regeln beachten würden. Ansonsten könnte auch Autoload per default an sein und der Hinweis wäre: "Autoload gegebenenfalls nach dem Update ausschalten".

Ich hatte das bereits umgesetzt, aber dann sind mir Bedenken gekommen. Ganz egal wie Autoload vorgegeben wird, könnte es im schlimmsten Fall die Site praktisch unbenutzbar machen, so dass der User in der Konfiguration nicht mehr nachbessern kann. Das möchte ich daher ungern auf die Schnelle für 1.6.9 so machen. Für 1.6.10 können wir hoffentlich noch mal in Ruhe drüber nachdenken (und das am besten in einem eigenen Thread).

Eigentlich kann es beim Update, wenn man wirklich das Update-Paket drüber bügelt, doch überhaupt kein Problem geben. Die bereits vorhandenen jQuery-Versionen, die in der config.php gewählt sind, bleiben doch erhalten. Es kommen lediglich neue Versionen dazu. Wenn der User nach dem Update nichts anpasst, bleibt es eben bei den bis dahin genutzten Versionen.
Daher ist es natürlich auch komplett in Ordnung, wenn ein Update-Paket ohne config.php des jQuery-Plugins ausgeliefert wird.
Die Verunsicherung bei parken kam vermutlich eher von der Anleitung. Da müssten wir wohl, wie oben beschrieben, nachbessern und vielleicht auch genauer erklären, dass eigentlich nicht viel zu verstellen ist.