[3.3] Recent Topics NG

[IMC]

Hi Patrick,

v2.2.15-pl22 ist hochgeladen. Die Änderungen der Variablen, Namesräume, Klassen- und Dateiennamen usw. habe ich wie besprochen durchgeführt.

Die Erweiterung der Templates um die neuen Einstellungen werde ich in der nächsten Woche angehen. Inklusive der von dir vorgeschlagenen Anpassung. Einige Template-Variablen werde ich in dem Zuge auch noch mal umbenennen.

Danach wäre es schön wenn du dir die Texte der Sprachdaten einmal anschaust. Das Überarbeiten und Verbessern von Texten gehört nicht zu meinen Stärken.

Hinweise zur Optimierung des Codes sind jederzeit willkommen.

[LukeWCS]

Okay, dann weiss ich Bescheid. pl22 ist die fehlerkorrigierte Version bezüglich fehlender RT Anzeige?

[IMC]

Ja, bei mir wird alles richtig angezeigt.

[LukeWCS]

Okay, in so einem Fall (Fehler bei einer PL Version) wäre es (zukünftig) hilfreich/sinnvoll, wenn du den zugehörigen Eintrag im Changelog/Commit-Meldung auch explizit mit dem Präfix "Fix:" markieren würdest mit Bezug auf die fehlerhafte PatchLevel Version, damit alles nachvollziehbar bleibt und man sofort sieht, das es einen Fehler gab und nun auch einen Fix gibt. Denn im aktuellen pl22 Changelog ist nicht ersichtlich, das es überhaupt einen Fehler gab.

edit: Okay, davon unabhängig habe ich nicht gleich realisiert, dass pl22 bereits die erste Version mit geänderter Struktur ist und mich zuerst über eine Container-Fehlermeldung gewundert.

[IMC]

Okay, in so einem Fall (Fehler bei einer PL Version) wäre es (zukünftig) hilfreich/sinnvoll, wenn du den zugehörigen Eintrag im Changelog/Commit-Meldung auch explizit mit dem Präfix "Fix:" markieren würdest

Habe ich nachgeholt. Sollte jetzt im Commit stehen.

edit: Okay, davon unabhängig habe ich nicht gleich realisiert, dass pl22 bereits die erste Version mit geänderter Struktur ist und mich zuerst über eine Container-Fehlermeldung gewundert.

Wo kommt den die Meldung und wie sieht diese aus? Ich habe eben vorsichtshalber den paybas Ordner von Server gelöscht und RTNG deaktiviert, Arbeitsdaten gelöscht und neu installiert. Keine Fehlermeldung.

[LukeWCS]

Eine solche schwere Container-Fehlermeldung bekommt man dann, wenn man versucht eine Ext zu aktivieren, die sich im falschen Ordner befindet.

Ich habe zuerst nicht realisiert, dass das bereits die neue Struktur ist, weil im Repo ja leider kein Pfad existiert. Das ist zwar sehr Composer-freundlich, aber absolut Endbenutzer-unfreundlich. Jetzt klingeln Crizzo die Ohren.

In logischer Konsequenz daraus habe ich versucht, pl22 in einem paybas\recenttopics Kontext zu aktivieren, wodurch es natürlich sofort geknallt hat.

[IMC]

weil im Repo ja leider kein Pfad existiert.

Es besteht jetzt keine Notwendigkeit mehr dies so zu lassen. Das kann ich mit dem nächsten Patch ändern. Stört mich auch, da das Erstellen eines Archivs dadurch etwas umständlich ist. Bei meinen anderen Repos habe ich auch den kompletten Pfad.

[LukeWCS]

Es besteht jetzt keine Notwendigkeit mehr dies so zu lassen.

Das sehe ich genauso.

Das kann ich mit dem nächsten Patch ändern. Stört mich auch, da das Erstellen eines Archivs dadurch etwas umständlich ist. Bei meinen anderen Repos habe ich auch den kompletten Pfad.

Ich habe mir bereits deine Repos angeschaut und eben das dann auch festgestellt. Auch darum wäre eine Änderung besser, damit das wieder zu deinen anderen Repos passt. Auch mir ist das lieber, weil dann meine Arbeitsvorgänge in Bezug auf Updates und GH einfacher sind.

Ich hab jetzt ehrlich gesagt nicht damit gerechnet, dass du derart schnell die Struktur umstellst. Aber wenn du das jetzt schon hast, sollten wir gleich Tabula rasa machen und das von Anfang an mit paar Änderungen weiter führen. Im Nachhinein betrachtet, war es nicht so sinnvoll, dass wir den Anzeigenamen "Recent Topics (fork by IMC & LukeWCS)" geändert haben bei unseren PatchLevel Versionen. Denn jetzt haben beide denselben Anzeigenamen, aber wir können immerhin an der Version erkennen, was da installiert ist. Das ist auch durchaus wichtig in Zukunft, wenn Endbenutzer uns ihre Version mitteilen müssen, bei einem Supportfall.

1. Wir sollten ab sofort keine PL Versionen mehr verwenden, sondern ganz reguläre und vor allem eigene Versionen, denn jetzt sind wir nicht mehr abhängig von den alten Strukturen und vor allem machen wir ja jetzt keine "Patches" mehr, sondern reguläre Updates. Zuerst hatte ich überlegt bei 1.0.0 zu beginnen. Das wäre zwar technisch durchaus korrekt, aber bei den Endbenutzern eher schwer zu vermitteln. Deswegen hätte ich vorgeschlagen, dass wir bei 3.0.0 beginnen. Das würde RT mit neuer Struktur auch ganz klar von unseren PL Versionen trennen. Was meinst du dazu?
2. Wie bei den andren Repos jetzt den technischen Namen als Unterordner. Da sind wir uns ja schon einig.
3. Was da noch zur alten Struktur gehört, wie z.B. der Ordner "contrib", entfernen.
4. Entsprechend muss da natürlich dann auch .gitattributes angepasst werden.

Wir könnten das natürlich jetzt mit einem neuen GH Commit ändern, aber dann hätten wir die Version 2.2.15-pl22 schon in der Historie und das finde ich nicht so ideal. Wenn du nichts dagegen hast, würde ich das Repo auf den Stand von pl21 zurücksetzen, damit du dann die neue Struktur mit neuer Version nochmal einpflegen kannst. Was meinst dazu? Wenn ja, den Reset muss ich machen, das geht nicht in der GH UI, aber dazu muss ich erst wissen, ob du alles vom jetzigen Repo Zustand grundsätzlich gesichert hast. Nicht dass da irgendwas bei pl22 mit ins Repo kam, was du sonst nirgends mehr hast.

[IMC]

dass du derart schnell die Struktur umstellst.

Die neuen Features funktionieren nicht ohne eine Änderung der Migration. Da ist es nur sinnvolle alles auf neue Beine zu stellen.

Zuerst hatte ich überlegt bei 1.0.0 zu beginnen. Das wäre zwar technisch durchaus korrekt, aber bei den Endbenutzern eher schwer zu vermitteln. Deswegen hätte ich vorgeschlagen, dass wir bei 3.0.0 beginnen.

Genau diese Überlegung in Bezug auf die Versionsnummer hatte ich auch schon die letzten Tage. Da sind wir im Konsens.

Was da noch zur alten Struktur gehört, wie z.B. der Ordner "contrib", entfernen.

Stattdessen kommt ein neuer Ordner Namens docs in dem die Events dokumentiert werden. Dort steht zwar nur etwas zu den Template-Events. Ich bin mir jedoch sicher dass die Core-Events genau so behandelt werden müssen/sollten.

damit du dann die neue Struktur mit neuer Version nochmal einpflegen kannst. Was meinst dazu?

Können wir so machen. Ich habe zu Sicherheit ein zusätzliches Backup gemacht.
Aber als welche Version lade ich es hoch? Als v3.0.0-a1. Von der Version 3.0.0-rc1 sind wir noch etwas entfernt.

[LukeWCS]

Stattdessen kommt ein neuer Ordner Namens docs in dem die Events dokumentiert werden. Dort steht zwar nur etwas zu den Template-Events. Ich bin mir jedoch sicher dass die Core-Events genau so behandelt werden müssen/sollten.

Wobei du jetzt die Coding Guidelines von phpBB selber verlinkt hast. Die gilt zwar natürlich in grossen Teilen auch für uns Ext Entwickler, aber speziell die Event Dokumentation in diesen Guidelines bezieht sich auf Core Events von phpBB selber. An diese Ordnerstruktur sind wir in dem Fall nicht gebunden.

Ich habe z.B. meine Events bei WWH in Form einer FAQ dokumentiert: https://www.phpbb.com/customise/db/exte ... 2/faq/3616. Das wurde auch von den Validatoren nie bemängelt. Relevant ist, dass Events dokumentiert sein müssen, insbesondere bei CDB Exts. Aber wo und wie, dass können wir selber entscheiden. Wenn du das aber in einem docs Ordner innerhalb der Ext Struktur haben willst, können wir das natürlich so machen.

Können wir so machen. Ich habe zu Sicherheit ein zusätzliches Backup gemacht.

Wunderbar, das war für mich dann jetzt auch der Startschuss; Repo ist auf 2.2.15-pl21 zurückgesetzt. Habe das lokal aber zur Sicherheit auch nochmal gesichert.

Aber als welche Version lade ich es hoch? Als v3.0.0-a1. Von der Version 3.0.0-rc1 sind wir noch etwas entfernt.

Das können wir jetzt frei entscheiden. Während dem Umbau wäre Alpha gar nicht verkehrt, weil währenddessen anfängliche Macken sich kaum vermeiden lassen, was alleine schon mal damit zusammenhängt, das wir die Ext nicht ursprünglich entwickelt haben und somit auch nicht jedes Detail aus dem Stand kennen. Wenn wir mit dem Umbau fertig sind, könnte man dann Beta nehmen, das wäre dann auch der frühestmögliche Zeitpunkt, wo wir das Repo für die Öffentlichkeit freigeben könnten.