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