[3.3] [Fork] Recent Topics NG

[IMC]

Ich habe den "Quick Fix" von LukeWCS im Fork eingefügt.

Beim Senden meines letzten Post habe ich vom Forum keine Benachrichtigung erhalten dass zwischenzeitlich neue Beträge erstellt wurden. Ist dies ein neues phpBB Problem oder Zufall?

[LukeWCS]

Thorsten, ich habe deinen Fork eben lokal als Repo geklont. Dabei ist mir aufgefallen, dass das Repo eine stark abweichende Codebase hat im Vergleich zum Zip recenttopics_imcger_fork-01.zip. Du kannst das selbst prüfen, indem du dein eigens erstelltes Zip mit dem Repo Zip vergleichst: im Releases Bereich bei "Recent Topics Fork 01" mal den Inhalt der beiden Zips komplett abgleichen (Compare Tool):

recenttopics_imcger_fork-01.zip
Source code (zip)

Ich hatte mir recenttopics_imcger_fork-01.zip lokal im TB installiert und da bereits angefangen mit Änderungen, bis ich eben die Abweichungen zum Repo bemerkte. Was ist denn nun die gültige Codebase? Das was im Repo steht oder recenttopics_imcger_fork-01.zip? Weil das zweite Release recenttopics_imcger_fork-02.zip entspricht genau der aktuellen Repo Codebase, weicht aber massiv von recenttopics_imcger_fork-01.zip ab.

[IMC]

Hi Patrick,

das ZIP 02 ist das Richtige!! Ist identisch mit dem Repositorie.

Das ZIP 01 hatte ich dummerweise von dem Spiegel meines Produktive Boards gemacht. Da wollte ich mir zwei Arbeitsschritte sparen.
Das dies unterschiedlich ist habe ich erst später (zu Spät) realisiert.
Da gibt es unwesentliche Anpassungen im Style (die nur in meinem Style Wirkung zeigen) und eine Änderung in derrecenttopics.php die noch nicht nachgepflegt worden ist, die Funktion aber nicht beeinflusst. Habe ich eben nochmal mit WinMerge verglichen. Alle anderen Unterschied sind nur Formatierungen/Einrückungen. Also keine Codeänderungen.

Ich werde da das nächste mal gewissenhafter arbeiten. Versprochen!

[LukeWCS]

Solange man das noch klären kann, ist alles gut.

Der Hintergrund ist, wenn wir jetzt beide daran arbeiten, ist es sehr wichtig das wir auch beide die gleiche Codebase nutzen. Es würde unnötig umständlich werden, wenn du mit Version b) und ich mit Version a) arbeiten würden. Denn in dem Fall hätte ich jetzt quasi mit deinem LB Mirror gearbeitet. ^^

Jut, dann lösche ich das bei mir im TB nochmal komplett und fange frisch mit dem aktuellen Repo Stand an.

Okay, ich würde vorschlagen die bisherigen Releases und Tags erstmal alle zu löschen und keine weiteren Releases zu erstellen, bis wir beide unsere jeweiligen Änderungen drin haben und eine testfähige und vor allem gemeinsame Basis haben. Bei jeder Änderung ein neues Release zu machen ist zum einen unnötiger Aufwand und zum anderen wenig sinnvoll, solange wir mitten im bauen sind. Ein Release kann ausserdem dazu verleiten, das als Release fürs LB zu betrachten. Nicht jeder der über den Fork stolpert liest dieses Thema hier.

Was meinst?

Vorab-Releases können übrigens auch explizit als "Pre-release" gekennzeichnet werden, siehe LFWWH bei den Versionen <2.0.0: https://github.com/LukeWCS/lf-who-was-here-2/releases

Hier die Details die ich nicht mehr im anderen Thema schreiben wollte.

Wegen Versionsprüfung. Diese ist ist in mehrfacher Hinsicht seltsam. Dazu wird ausgerechnet Curl implementiert samt Mozilla SSL Zertifikatspaket. Ich kann nicht nachvollziehen, warum man das so umständlich machen muss/will. Wenn man wirklich eine eigene Versionsprüfung im ACP Modul realisieren wollte, kann man das ganz simpel mit fertigen PHP Funktionen realisieren. Und nicht mal das muss man, weil phpBB ja schon eine Funktion für Versionsprüfung bietet, nämlich genau die, die der ExtMgr auch nutzt. Dazu kommt, dass Recent Topics keine Ext ist, bei der man regelmässig ins ACP Modul gehen würde. Die wird normal einmal eingestellt und gut ist. Schon alleine deswegen ist eine extra Versionsprüfung im ACP Modul wenig sinnvoll. Die Benutzer sind es eh gewöhnt, dass man Ext Versionen simpel alle auf einmal im ExtMgr prüfen kann.

Etwas wegen Versionnummer, ich weiss nicht, ob du das "Thanks For Posts" Fiasko mitbekommen hast. Da gabs (und gibt es immer noch) ein prima Chaos, weil viele Benutzer nie wirklich mitbekommen haben, dass davon zwei völlig unabhängige Entwicklungen existieren. Ich bin einer von denen: viewtopic.php?p=1385730#p1385730 . Hat mich allerdings nicht direkt betroffen, weil ich das nur im TB hatte.

Darum:

1. Um auf der sicheren Seite zu bleiben, würde ich vorschlagen, das wir nur solche Änderungen vornehmen, bei denen keine neuen Migrationen nötig sind.
2. Was hältst du davon, wenn wir unsere Sub-Versionen entsprechend in die Versionsnummer einbetten? Bei phpBB und CDB gelten 3 Segmente, uns fehlt also quasi ein viertes für unsere Zwecke. Aber auch das kann man lösen, indem wir einfach ein Pseudo-Segment nehmen. Da würde sich die PatchLevel (pl) Version anbieten, weil dass das einzige Versionssuffix ist, welches höher als die eigentliche Versionsnummer ist. Deine erste Version des Forks wäre dann quasi 2.2.15-pl1, meine Entfernung der Versionsprüfung stufen wir als 2.2.15-pl2 ein und deine darauf aufbauende Änderungen die du geplant hast, dann als 2.2.15-pl3. Nur als Beispiele. Diese Versionierung würde auch helfen den Überblick zu behalten, denn aktuell kann man beim Fork nicht wirklich erkennen, welche Version da installiert ist. Im ExtMgr sieht man nur 2.2.15, wie beim Original.

Diese beiden Eigenschaften hätten einen immensen Vorteil: wenn der Original Autor wieder die Arbeit an seiner Ext aufnimmt, könnten Benutzer (inklusive wir beide), die unseren Fork benutzt haben, problemlos auf die dann neue offizielle Version wechseln.

Sorry für diese wall-of-text, habe fertig!

[IMC]

ist es sehr wichtig das wir auch beide die gleiche Codebase nutzen.

Das kleine Malör betraf nur das hochgeladene ZIP-Archiv. Änderungen am Repositorie mache ich seit ein paar Monaten mit GitHub Desktop, das sollte safe sein.

ich würde vorschlagen die bisherigen Releases und Tags erstmal alle zu löschen und keine weiteren Releases zu erstellen, bis wir beide unsere jeweiligen Änderungen drin haben und eine testfähige und vor allem gemeinsame Basis haben.

Das hört sich sinnvoll an. Werde ich Morgen löschen.

Etwas wegen Versionnummer, ich weiss nicht, ob du das "Thanks For Posts" Fiasko mitbekommen hast. Da gabs (und gibt es immer noch) ein prima Chaos, weil viele Benutzer nie wirklich mitbekommen haben, dass davon zwei völlig unabhängige Entwicklungen existieren. Ich bin einer von denen: viewtopic.php?p=1385730#p1385730 . Hat mich allerdings nicht direkt betroffen, weil ich das nur im TB hatte.

Nee, aber das werde ich mir Morgen anschauen. Obwohl ich „offiziell Alt“ bin, lerne ich immer noch gern dazu.

1. Um auf der sicheren Seite zu bleiben, würde ich vorschlagen, das wir nur solche Änderungen vornehmen, bei denen keine neuen Migrationen nötig sind.

Auf alle Fälle. Sonst würde die kompatibilität mit späteren ... Ach, hast du schon weiter unten begründet.

2. Was hältst du davon, wenn wir unsere Sub-Versionen entsprechend in die Versionsnummer einbetten? Bei phpBB und CDB gelten 3 Segmente, uns fehlt also quasi ein viertes für unsere Zwecke. Aber auch das kann man lösen, indem wir einfach ein Pseudo-Segment nehmen. Da würde sich die PatchLevel (pl) Version anbieten, weil dass das einzige Versionssuffix ist, welches höher als die eigentliche Versionsnummer ist. Deine erste Version des Forks wäre dann quasi 2.1.15-pl1, meine Entfernung der Versionsprüfung stufen wir als 2.1.15-pl2 ein und deine darauf aufbauende Änderungen die du geplant hast, dann als 2.1.15-pl3. Nur als Beispiele. Diese Versionierung würde auch helfen den Überblick zu behalten, denn aktuell kann man beim Fork nicht wirklich erkennen, welche Version da installiert ist. Im ExtMgr sieht man nur 2.1.15, wie beim Original.

Erscheint mir sinnvoll. Wenn jetzt erst einmal kein Release mehr erstellt wird, wie halte ich die Versionsstände fest? Als Branches? Ich kenne mich mit den Möglichkeiten nicht so gut aus.

Ich bin mir sicher das ich bei diesem Projekt ein Menge dazu lernen werde. Freue mich schon drauf.

[LukeWCS]

Mahlzeit

Änderungen am Repositorie mache ich seit ein paar Monaten mit GitHub Desktop, das sollte safe sein.

Das ist aus zweierlei Gründen prima; zum einen weil man sich damit die tägliche Arbeit mit Repos erheblich vereinfachen kann und zum anderen, weil ich das ebenfalls einsetze. Da können wir uns also dann auch problemlos austauschen.

Wenn jetzt erst einmal kein Release mehr erstellt wird, wie halte ich die Versionsstände fest? Als Branches?

Das musst du nicht, weil das eine Grundfunktion einer VVS wie Github (bzw. git) ist. Sprich, Github erledigt das schon für dich. Du kannst jederzeit die Ansicht deines Repos auf den Stand eines beliebigen Commits umschalten. Dann siehst du das Repo exakt in dem Zustand in dem es war, als du den Commit eingepflegt hast. Du kannst dann sogar direkt über den grünen Button "Code" ein Repo Zip erstellen, dass dann einen exakten Snapshot des Repo Zustands zum Zeitpunkt des Commits enthält.

Ein Release, oder besser gesagt das dabei entstehende Tag, erleichtert solche Aktionen lediglich, ist aber nicht zwingend dafür erforderlich. Du kannst über einen kleinen Umweg auch selbst jederzeit Tags erstellen im GH Repo, die du quasi als "Marker" nutzen kannst. Solche Marker werden dann auch direkt in GH Desktop in der Historie angezeigt. Releases haben auch den Vorteil, das man dann sehr einfach 2 Releases vergleichen kann. So kann man sich simpel alle Unterschiede zum vorherigen Release anzeigen lassen. Das ist primär für Ext Coder, Style Designer und Übersetzer hilfreich.

Mit Branches kann man arbeiten, wenn man zum Beispiel etwas kurzfristig testen will und noch nicht sicher ist, ob man das in den Main Branch übernimmt. Oder aber um Benutzern auf die Schnelle einen QuickFix anbieten zu können, ohne dazu gleich den Main Branch zu ändern. Also quasi etwas, das eh nur kurz Bestand hat und bei der nächsten Version nicht mehr relevant ist. Branches sind auch lokal nützlich, weil du bei GH Desktop ja auch Branches anlegen und umschalten kannst. Branches sind also ideal um Dinge organisieren und separieren zu können. Und ein Branch kann dann auch in einen anderen migriert werden. Ich habe bei mir z.B. lokal in deinem Repo einen Branch "2-1-15-pl2" angelegt, in dem ich z.Z. die Änderungen einpflege. So kann ich jederzeit dein Repo lokal umschalten zwischen dem offiziellen/öffentlichen Zustand und meinem lokalen Dev Zustand.

edit: Welche Toogle Variante hast du eig. geplant, die von Udo und mir? Davon ist es abhängig, inwieweit ich XHTML entferne.

[IMC]

Hi Patrick, danke für die Erklärungen.

Die Releases habe ich gelöscht und die Versionsnummer in der composer.json wie besprochen auf pl1 hoch gesetzt.

Als Toogel Button werde ich die Version von Udo und dir nutzen.

[LukeWCS]

Ideal, so sieht man im ExtMgr sofort, dass der Fork installiert ist.

Wegen Toggle, dann weiss ich Bescheid und kann entsprechend vorgehen. Willst du das eig. selbst einbauen, oder soll ich das gleich mit erledigen? Weil ich eh in den Templates unterwegs bin um XHTML zu entfernen und auch Twig Code überarbeite.

[IMC]

Da sage ich mal Ja, kannst du gerne mitmachen.
Für den Toggel hast du so'n schönes Macro und mein Wissen zu TWIG ist noch begrenzt.

[LukeWCS]

Generell werden die Erfahrungen die ich mit den Validierungen von LFWWH sowie mit den Validierungsberichten der Kollegen gesammelt habe mit einfliessen.

Da sage ich mal Ja, kannst du gerne mitmachen.

Okay, schon erledigt.

Für den Toggel hast du so'n schönes Macro und mein Wissen zu TWIG ist noch begrenzt.

Twig ist mächtig und mit der alten phpBB Template Syntax nicht mehr vergleichbar. Was man sehr häufig antrifft (auch bei RT), ist so ein if/else/endif Konstrukt, das wird sehr oft bei Radios und Selects benutzt:

Code: Alles auswählen

{% if RT_INDEX %} checked="checked"{% endif %}

Das rührt noch von der alten phpBB Syntax her und ist meist das Ergebnis des Twig Konverters. Viele Coder benutzen dieses Konstrukt noch immer, weil Gewohnheit. Eigentlich ist das ein Konstrukt für mehrzeilige Blöcke. Und hier ist halt auch noch XHTML Notation enthalten, was das zusätzlich unnötig aufbläht. Für einzeilige Geschichten geht das deutlich kompakter:

Code: Alles auswählen

{{ RT_INDEX ? ' checked' }}

Und mit Makros spart man zusätzlich eine Menge unnötig redundanten Code, vor allem bei vielen simplen Ja/Nein Schaltern.

Aber okay, Kleinkram, der wird nebenher erledigt.