Avatar

Update des Forums scheint verbesserungswürdig (Technics)

by Milo ⌂, Thursday, November 09, 2017, 08:24 (11 days ago)
edited by Auge, Thursday, November 09, 2017, 11:08

Hallo,

die derzeitige Updateroutine ist wirklich verbesserungswürdig. Wenn gegenwärtig etwas am CSS geändert wird, müssen Leute, die ein eigenes Template pflegen, mühselig Zeile für Zeile durchgehen und die Änderungen suchen. Das motiviert keinen, eigene Templates zu erstellen. Hier sollten wir mal überlegen, wie wir den Anwendern die tatsächlichen Änderungen am Template und der CSS besser zugänglich machen können. Ein Hinweis wie: Wenns Dich näher interessiert, schau ab Zeile XYZ, finde ich ehrlich gesagt nicht zielführend. Das muss irgendwie[tm] besser gehen. ;-)

Bei den PHP-Dateien könnten wir auch eine Art Versionsnummer einführen - pro Datei eine individuelle. Weiterhin haben wir eine globale Liste mit allen Files, deren individuellen Versionsnummern und eine Zuordnung zur Version des Forums. Damit könnten wir zumindest für diese Files prüfen, ob sie beim Update auch hochgeladen oder vergessen wurden.

Viele Grüße
Micha

[edit]: Dies war ursprünglich eine Antwort auf jenes Posting.

--
Surveyor-Software: Geodetic Network Adjustment & Deformation-Analysis and Transformation

Avatar

Update des Forums scheint verbesserungswürdig

by Auge ⌂ @, Thursday, November 09, 2017, 09:55 (11 days ago) @ Milo

Hallo

die derzeitige Updateroutine ist wirklich verbesserungswürdig. Wenn gegenwärtig etwas am CSS geändert wird, müssen Leute, die ein eigenes Template pflegen, mühselig Zeile für Zeile durchgehen und die Änderungen suchen. Das motiviert keinen, eigene Templates zu erstellen. Hier sollten wir mal überlegen, wie wir den Anwendern die tatsächlichen Änderungen am Template und der CSS besser zugänglich machen können.

Dass es dieses Problem gibt, ist mir auch schon aufgekommen. Die Änderungen, oder zumindest einige davon (Bedienelemente, Elemente mit neuen Infos), muss ich ja auch immer in mein (noch unfertiges) Template einpflegen.

Ein Hinweis wie: Wenns Dich näher interessiert, schau ab Zeile XYZ, finde ich ehrlich gesagt nicht zielführend. Das muss irgendwie[tm] besser gehen. ;-)

Da hast du recht. Der Hinweis war allerdings eher dazu gedacht, erst einmal auszuloten, ob candleman überhaupt eigene Änderungen hat, die berücksichtigt werden müssen, bevor ich nachts um elf, wenn ich eigentlich in's Bett will, anfange, alle Stellen, an denen es tatsächlich Änderungen gibt, aufzuführen.

Bei den PHP-Dateien könnten wir auch eine Art Versionsnummer einführen - pro Datei eine individuelle.

Ich vermute dahinter einen Integerzähler oder hast du an eine klassisch aufgebaute Versionsnummer wie z.B. 2.3.1.96 gedacht?

Weiterhin haben wir eine globale Liste mit allen Files, deren individuellen Versionsnummern und eine Zuordnung zur Version des Forums.

Hui, das ist konsequent, aber auch pflegeaufwendig. So, wie ich mir das vorstelle, muss ich jeder Datei bei jeder Änderung, die in einen Commit mündet, eine neue Nummer geben. Da ich oft mehrere Commits zu einem Pull Request bündele und diesen dann, wenn es sich um ein geschlossene Änderung handelt, per "Squash and Commit" ins Hauptrepository einfüge, wo es hinterher als ein Commit zu sehen ist, kann es sein, dass Versions- oder Seriennummern einzelner Dateien übersprungen würden. Ich kann mir zwar auf Anhieb nicht vorstellen, warum das zu Problemen führen sollte, es sollte aber bei der Ausformulierung des Systems bedacht werden.

Damit könnten wir zumindest für diese Files prüfen, ob sie beim Update auch hochgeladen oder vergessen wurden.

Die PHP-Dateien könnte man so abfrühstücken. Die bleiben so, wie sie von uns gestellt werden, außer, ja, außer irgendwer baut sich noch eigene Funktionen in die Skripte ein. Dann steht der, auch wenn ich von ihm erwarte, Diffs interpretieren zu können, vor dem gleichen Problem wie einer mit Änderungen am Template. Womit wir wieder beim Auslöser wären.

Ich möchte da eine strikte gedankliche Trennung der Ausgangssituationen vornehmen.

Es gibt einige, die Änderungen am Default-Template vorgenommen haben. Die sind bei jedem Update davon betroffen, aufpassen zu müssen, ihre Änderungen mit dem Upload der Dateien des Default-Templates nicht zu überschreiben. Eigentlich möchte ich an der Stelle sagen: Selber schuld, wir warnen schließlich gebetsmühlenartig davor, das Default-Template zu ändern. Das hilft dem betroffenen Forumsbetreiber natürlich nicht. Er braucht die Informationen über die konkreten Änderungen und muss sie vor dem Upload der Template-Dateien einpflegen.

Demjenigen, der ein eigenes Template benutzt, fehlen im Zweifelsfall nur eine oder ein paar neue Funktionen, wie z.B. bei der 2.4-er Serie die Links, Buttons und die Seite für die Bookmarks. Sie/er macht aber normalerweise nichts kaputt. Um das eigene Template anzupassen, braucht aber auch ein Betreiber mit eigenem Template die Informationen über die konkreten Änderungen um sein Template zu erweitern.

Wir brauchen also für die Templates einen Mechanismus der Dokumentation, der auch für Laien zweiter Stufe (basteln mit HTML und CSS selbst am/ein Template) vertändlich ist. Ich würde das in einer eigenen Seite des Wikis sammeln wollen, in der Blöcke für neue MLF-Versionen oben angefügt werden.

Folgende, mit Templates in Zusammenhang stehende Änderungen müssen mMn dokumentiert werden.

- Änderung an der HTML-Struktur. Entfernen, hinzufügen und umbenennen von Elementen, Klassen und IDs. Auch wichtig für eigene JavaScripte, die nach Änderungen im HTML-Quelltext auf nicht mehr existente oder umbenannte Elemente oder Attribute zielen könnten.
- Änderungen in den Sprachdateien. Neue Strings, umbenannte Schlüssel.
- Änderungen im CSS, z.B. auch durch Änderungen im HTML verursachte Umbenennungen von Selektoren (Klassen, IDs).

Die Dokumentation sollte mMn mit Verweis auf die Zeilen/Abschnitte im Quellcode erfolgen und eventuell Codeausschnitte der relevanten Stellen enthalten. Der Aufwand wird bei Major-Releases (2.4, 2.5, etc.) mit neuen Funktionen erheblich. Bei Bugfix-Releases sollte er sich hingegen in Grenzen halten. Wir müssen bloß ein Schema erarbeiten, wie sowas aussehen soll, damit wir das nicht aus Versehen bei jedem Release unterschiedlich gestalten.

Tschö, Auge

--
further development of mlf1

Avatar

Update des Forums scheint verbesserungswürdig

by Milo ⌂, Thursday, November 09, 2017, 10:17 (11 days ago) @ Auge

Hallo,

Die Änderungen, oder zumindest einige davon (Bedienelemente, Elemente mit neuen Infos), muss ich ja auch immer in mein (noch unfertiges) Template einpflegen.

Nicht nur Du. ;-)

Ich vermute dahinter einen Integerzähler oder hast du an eine klassisch aufgebaute Versionsnummer wie z.B. 2.3.1.96 gedacht?

Einen einfachen int. Zähler, da dieser unabhängig von der Forenversion ist. Die Forenversion kennt also die int. Nummer der Datei, die sie benötigt. Die Datei selbst weiß aber nicht, zu welcher Version sie gehört.

muss ich jeder Datei bei jeder Änderung, die in einen Commit mündet, eine neue Nummer geben.

Jede Datei, die auch tatsächlich geändert wurde, erhält zwischen den Forenversionen eine neue Nummer. Aktuell haben wir die Forenversion 2.4.6. Die contact.inc.php hat bspw. die Version 3. Wenn nun im Zuge der Erneuerungen auf Version 2.4.7 das Kontaktformular geändert wurde, wird die 3 durch eine 4 ersetzt. In der globalen Liste entsprechend:

index.inc.php 12
contact.inc.php 4 // vorher 3 - Einzige Änderung
admin.inc.php 37
....

Die PHP-Dateien könnte man so abfrühstücken. Die bleiben so, wie sie von uns gestellt werden, außer, ja, außer irgendwer baut sich noch eigene Funktionen in die Skripte ein. Dann steht der, auch wenn ich von ihm erwarte, Diffs interpretieren zu können, vor dem gleichen Problem wie einer mit Änderungen am Template. Womit wir wieder beim Auslöser wären.

Ja aber die Wahrscheinlichkeit wäre hier geringer. Es scheint für mich naheliegender, dass einer die Optik ändert als unter Haube zu schrauben. Aber klar, das Problem würde weiterhin besehen aber einen vermutlich deutlich kleineren Kreis an Nutzern treffen.

Demjenigen, der ein eigenes Template benutzt, fehlen im Zweifelsfall nur eine oder ein paar neue Funktionen, wie z.B. bei der 2.4-er Serie die Links, Buttons und die Seite für die Bookmarks. Sie/er macht aber normalerweise nichts kaputt. Um das eigene Template anzupassen, braucht aber auch ein Betreiber mit eigenem Template die Informationen über die konkreten Änderungen um sein Template zu erweitern.

Wenn wir bestimmte Funktionalitäten ändern (PHP), diese dann ins Template (via SMARTY) transportieren, dann ist eben leider jeder betroffen, da u.U. das alte Template gar nicht mehr lauffähig ist. Wenn wir also eine Variable entfernen oder umbenennen, dann trifft das eben alle und es muss dann nachvollziehbar sein, was zu ändern ist im Template/CSS/JavaScript.

- Änderung an der HTML-Struktur. Entfernen, hinzufügen und umbenennen von Elementen, Klassen und IDs. Auch wichtig für eigene JavaScripte, die nach Änderungen im HTML-Quelltext auf nicht mehr existente oder umbenannte Elemente oder Attribute zielen könnten.
- Änderungen in den Sprachdateien. Neue Strings, umbenannte Schlüssel.
- Änderungen im CSS, z.B. auch durch Änderungen im HTML verursachte Umbenennungen von Selektoren (Klassen, IDs).

Die Dokumentation sollte mMn mit Verweis auf die Zeilen/Abschnitte im Quellcode erfolgen und eventuell Codeausschnitte der relevanten Stellen enthalten. Der Aufwand wird bei Major-Releases (2.4, 2.5, etc.) mit neuen Funktionen erheblich. Bei Bugfix-Releases sollte er sich hingegen in Grenzen halten. Wir müssen bloß ein Schema erarbeiten, wie sowas aussehen soll, damit wir das nicht aus Versehen bei jedem Release unterschiedlich gestalten.

Ja, ich denke, dass trifft den Kern. Wie man das dann ausgestaltet, weiß ich im Moment auch noch nicht ;-)

Viele Grüße
Micha

--
Surveyor-Software: Geodetic Network Adjustment & Deformation-Analysis and Transformation

Avatar

Update des Forums scheint verbesserungswürdig

by Auge ⌂ @, Thursday, November 09, 2017, 11:06 (11 days ago) @ Milo

Hallo,

Ich vermute dahinter einen Integerzähler oder hast du an eine klassisch aufgebaute Versionsnummer wie z.B. 2.3.1.96 gedacht?


Einen einfachen int. Zähler …

Gut.

… muss ich jeder Datei bei jeder Änderung, die in einen Commit mündet, eine neue Nummer geben.


Jede Datei, die auch tatsächlich geändert wurde, erhält zwischen den Forenversionen eine neue Nummer.

Also eine neue Zählernummer nur bei Release einer neuen Version, nicht bei jedem Commit, von dem die Datei betroffen ist. Das verringert den Aufwand erheblich.

Die PHP-Dateien … bleiben so, wie sie von uns gestellt werden, … außer irgendwer baut sich noch eigene Funktionen in die Skripte ein. Dann steht der, auch wenn ich von ihm erwarte, Diffs interpretieren zu können, vor dem gleichen Problem wie einer mit Änderungen am Template.


… das Problem würde weiterhin bestehen aber einen vermutlich deutlich kleineren Kreis an Nutzern treffen.

Das ist klar.

Demjenigen, der ein eigenes Template benutzt, fehlen im Zweifelsfall nur eine oder ein paar neue Funktionen, wie z.B. bei der 2.4-er Serie die Links, Buttons und die Seite für die Bookmarks. Sie/er macht aber normalerweise nichts kaputt. Um das eigene Template anzupassen, braucht aber auch ein Betreiber mit eigenem Template die Informationen über die konkreten Änderungen um sein Template zu erweitern.


Wenn wir bestimmte Funktionalitäten ändern (PHP), diese dann ins Template (via SMARTY) transportieren, dann ist eben leider jeder betroffen, da u.U. das alte Template gar nicht mehr lauffähig ist. Wenn wir also eine Variable entfernen oder umbenennen, dann trifft das eben alle und es muss dann nachvollziehbar sein, was zu ändern ist im Template/CSS/JavaScript.

Korrekt.

- Änderung an der HTML-Struktur. Entfernen, hinzufügen und umbenennen von Elementen, Klassen und IDs. Auch wichtig für eigene JavaScripte, die nach Änderungen im HTML-Quelltext auf nicht mehr existente oder umbenannte Elemente oder Attribute zielen könnten.
- Änderungen in den Sprachdateien. Neue Strings, umbenannte Schlüssel.
- Änderungen im CSS, z.B. auch durch Änderungen im HTML verursachte Umbenennungen von Selektoren (Klassen, IDs).

Die Dokumentation sollte mMn mit Verweis auf die Zeilen/Abschnitte im Quellcode erfolgen und eventuell Codeausschnitte der relevanten Stellen enthalten. Der Aufwand wird bei Major-Releases (2.4, 2.5, etc.) mit neuen Funktionen erheblich. Bei Bugfix-Releases sollte er sich hingegen in Grenzen halten. Wir müssen bloß ein Schema erarbeiten, wie sowas aussehen soll, damit wir das nicht aus Versehen bei jedem Release unterschiedlich gestalten.


Ja, ich denke, dass trifft den Kern. Wie man das dann ausgestaltet, weiß ich im Moment auch noch nicht ;-)

Ich stöbere gerade in den Hilfedokumenten von Github, um herauszubekommen, welche Automatismen existieren, um mit Markdown ein navigierbare Hilfe mit anspringbaren Zwischenüberschriften zu erstellen. Sieht gut aus.

Tschö, Auge

PS: Ich mache daraus mal einen eigenen Thread.

--
further development of mlf1

Avatar

Update des Forums scheint verbesserungswürdig

by Auge ⌂ @, Thursday, November 09, 2017, 12:30 (11 days ago) @ Milo

Hallo,

Die Dokumentation sollte


Ja, ich denke, dass trifft den Kern. Wie man das dann ausgestaltet, weiß ich im Moment auch noch nicht ;-)

Ich habe mal einen ersten Versuch für die Theme-bezogenen Änderungen in der Version 2.4.6 gewagt. Das mag nicht der Weisheit letzter Schluss sein, bietet mMn aber bei Bedarf Anknüpfungspunkte für Nachfragen.

Tschö, Auge

--
further development of mlf1

Avatar

Update des Forums scheint verbesserungswürdig

by Milo ⌂, Thursday, November 09, 2017, 12:57 (11 days ago) @ Auge

Hi,

Ich habe mal einen ersten Versuch

Wow, das ist recht ausführlich und würde in der Tat viel zusätzliche Arbeit bedeuten. Insbesondere weil es auch teilweise Begründungen liefert. Für letzteres haben wir ja schon die Changelog. Daher hatte ich ursprünglich etwas flacheres im Sinn à la:

CSS:
Änderungen
#last-posting
#last-posting li
#last-posting li a

Entfernt
#last-posting span
#sidbar

Neu
#foo
#bar


Vielleicht ist etwas zwischen diesen Varianten auch sinnvoll. Der Anwender will ja letztlich beim Updaten nicht soviel (über die Hintergründe) lesen sondern wissen, was zu tun ist, oder?? Ich bin nach wie vor unschlüssig über das WIE...

Viele Grüße
Micha

--
Surveyor-Software: Geodetic Network Adjustment & Deformation-Analysis and Transformation

Avatar

Update des Forums scheint verbesserungswürdig

by Auge ⌂ @, Thursday, November 09, 2017, 15:08 (11 days ago) @ Milo

Hallo

Ich habe mal einen ersten Versuch


Wow, das ist recht ausführlich und würde in der Tat viel zusätzliche Arbeit bedeuten. Insbesondere weil es auch teilweise Begründungen liefert.

Ja, das ist recht umfangreich. Es ist ja auch nur ein erster Versuch.

Für letzteres haben wir ja schon die Changelog.

Ist das in einem stichwortartigen Changelog, wie wir es führen, sinnvoll darstellbar?

Daher hatte ich ursprünglich etwas flacheres im Sinn à la:

CSS:
Änderungen
#last-posting
#last-posting li
#last-posting li a

Entfernt
#last-posting span
#sidbar

Neu
#foo
#bar

Hmm, das ist wohl um einiges übersichtlicher. Die Frage ist nur, was an Zusatzinformationen geliefert wird. Beispiel: In #sidebar dies hinzugefügt, dafür in #modmenu jenes entfernt. Den Zusammenhang möchte ich schon liefern, damit bei einem Update nicht anstatt Dateien einzelne Zeilen oder Angaben vergessen werden.

Vielleicht ist etwas zwischen diesen Varianten auch sinnvoll.

Wahrscheinlich.

Der Anwender will ja letztlich beim Updaten nicht soviel (über die Hintergründe) lesen sondern wissen, was zu tun ist, oder?? Ich bin nach wie vor unschlüssig über das WIE...

Lass uns mal weiter probieren und diskutieren. Um es mit Helmut K. zu sagen: „Wichtig ist, was hinten raus kommt.“

--
further development of mlf1

RSS Feed of thread
powered by my little forum