[3.3] Recent Topics NG

[LukeWCS]

Wir sind mal wieder im Konsens.

Sind wir meistens, wir ticken ähnlich.

Meine Idee ist den Fork nur abzutrennen und dadurch ein eigenständiges Repository zu erhalten. Die Historie sollte erhalten bleiben.

Also exakt wie bei WWH, roger, dann machen wir das so.

Ich hatte das gestern an einem anderen Repository getestet, ging leider daneben - lustige Geschichte.
Hast du einen guten Tipp zur Durchführung oder muss ich wieder durch ein hartes Selbststudium.

Ich spiels bei mir mal durch, denn das ist bei mir ja auch schon wieder ewig her, 2018 halt. Seitdem hatte ich keine Exts mehr komplett übernommen, sondern entweder als Co. bei anderen mitgewirkt oder komplett eigene Exts entwickelt. Wenn ich das durchgespielt habe, kriegst von mir wieder eine Step-by-Step Liste. Da ist ja schon mal immens hilfreich, dass du auch GH Desktop nutzt, weil ich glaub das geht komplett damit.

Gestern hatte ich mit einen Roboter vom Support gechattet. Hätte wahrscheinlich geklappt, wenn ich alles verstanden hätte.

Ja, immer diese lästigen Anrufbeantworter.

Zuerst dachte ich dass wir RTNG gleich abtrennen sollten. Bin dann jedoch auch zu dem Schluss gekommen das wir nach deinen Listenpunkt 2 unser Repository auf eigene Füsse stellen sollten.

Jupp, je weniger wir haben, um so weniger müssen wir beim Umbau berücksichtigen. Und mir gehts auch darum, das wir zuerst eine ordentliche und stabile letzte Patchlevel Version bekommen, die man auch als Release freigeben "könnte". Denn dann ist sichergestellt, das wir uns während dem Umbau nicht noch mit irgendwelchen Bugs rumplagen müssen, die wir evtl. neu eingeschleppt haben. Deswegen machen wir jetzt auch keine grossen Änderungen mehr, ausser der Entfernung der Schnittstelle für die besagte NV Ext.

Während dem Umbau machen wir auch nichts anderes als den Umbau. Also keine neuen Features, keine funktionellen Änderungen. Kurz gesagt, "RT heisst jetzt RTNG, sonst ändert sich nix". Reimt sich zwar nicht wie der original Werbe Slogan, aber du weisst was ich meine.

Ich werde jetzt ersteinmal nickvergessen.newspage entfernen. Vielleicht finde ich beim Durchforsten des Codes noch etwas was unter Listenpunk 2 fällt.

Genau so wars gedacht, weil du den besseren Gesamtüberblick über RT hast als ich. Ich habe mich ja primär mit einigen wenigen Bereichen von RT befasst. Und du machst das wie du Zeit und Lust hast, wir haben keinen Terminplan. ^^

Würde es in diesem Stadium nicht Sinn machen wenn ich dich als Collaborator eintrage. Bis die neuen Strukturen fertig sind können wir eh nichts von dritten gebrauchen.

Guter Punkt, hatte ich vergessen dich darauf anzusprechen: ja, das wäre sinnvoll. Bei ExtOnOff haben wir das auch so gemacht, da hat mich chris1278 als Co. im Repo eingetragen, damit ich eigenständig dort agieren kann.

[LukeWCS]

Thorsten, wegen Standalone Repo anlegen auf Basis des Forks: Ich habe mir GH Desktop angeschaut und verschiedenes probiert und hatte damit keinen Erfolg. Ich bin mir auch nicht mehr sicher, ob ich das überhaupt damit gemacht habe. GH Desktop hatte ich nicht von Anfang an, sondern zuerstmal nur mit GH Web gearbeitet, dann kam Sourcetree und dann erst GH Desktop. Ich vermute also, dass ich das damals mit Sourcetree gemacht hatte, welches ich aber nicht mehr nutze und deinstalliert habe.

Aber die GH Web GUI bietet einen Import. Das ist eigentlich dazu gedacht, dass man von einer GH fremden Quelle importiert, funktioniert aber so wie es aussieht auch bestens mit einem GH Repo als Quelle. Darum würde ich vorschlagen das du das mal machst, damit wir dann testen können, ob sich das Ergebnis dann wie ein normales Repo verhält, wovon ich aber mal ausgehe.

1. Bei GH anmelden.
2. Oben in der persönlichen (grauen) Leiste auf das + Pulldown klicken und dort "Import repository" wählen.
3. Bei "Your old repository's clone URl" gibst du ein: https://github.com/IMC-GER/RecentTopics/.
4. Bei "Repository name" gibst du ein: RecentTopicsTest, damit (hoffentlich) niemand auf die Idee kommt, das nutzen zu wollen.
5. Dann "Begin import" klicken und abwarten, dauert nen Moment, das Ding hat ne Fortschrittsanzeige.

Das Ergebnis war in meinem Fall ein Klon deines Forks, welches aber keinerlei Verbindung mehr zu Sajaksi Repo hatte und das wollten wir ja erreichen; ein Standalone Repo. Wenn unsere Tests damit dann alle klappen, kannst den Schritt später nochmal wiederholen, wenn wir im bisherigen regulären Repo die letzte Patchlevel Version erstellt haben. Dann würde ich beim Import als Repo Name RecentTopicsTestNG vorschlagen. Somit ist klar um was es geht und unterscheidet sich trotzdem deutlich vom Original.

[IMC]

Hi Patrick,

das war mit deiner Anleitung super einfach.
Bei meine letzten suche bei Github hatte ich eine Anleitung zu einer Lösung über die Befehlszeile gefunden. Dein Weg ist deutlich einfacher.
Ich habe dich bei RecentTopicsTest als Collaborator eingetragen. Für den Fall dass du dort etwas direkt testen möchtest.

Meine anstehenden Arbeiten für RecentTopics beginne ich in der nächsten Woche.

[LukeWCS]

Bei meine letzten suche bei Github hatte ich eine Anleitung zu einer Lösung über die Befehlszeile gefunden. Dein Weg ist deutlich einfacher.

Ich habe sonst auch nur Anleitungen für die Shell gefunden. Ich weiss aber mit Sicherheit, dass ich das damals nicht in der Shell gemacht habe.

Ich habe dich bei RecentTopicsTest als Collaborator eingetragen. Für den Fall dass du dort etwas direkt testen möchtest.

Passt. Anfangen mit testen würde ich gerne damit, ob ich als Co. noch Zugriff auf das neue Repo haben, wenn du das privat setzt. Wenn du das mal machen könntest... Wenn das ginge wäre das perfekt, denn dann könnten wir den Umbau komplett privat machen, ohne das uns währenddessen Dritte reingrätschen. Auch wenn natürlich sowieso niemand direkt in unsere Codebase pushen kann, wäre es trotzdem "ablenkend", wenn im Umbau-Repo plötzlich fremde PRs oder Issues auftauchen. Deswegen wäre es mir am liebsten, wenn wir das Ding komplett abschotten könnten.

Meine anstehenden Arbeiten für RecentTopics beginne ich in der nächsten Woche.

Roger. Wenn du das hast und wir das getestet haben, können wir ein letztes Release mit der "alten" Struktur im bisherigen Repo machen und das Repo dann in den Archiv Modus versetzen. Dann kann kein GH User noch etwas an dem Repo machen, also keine PRs, Issues und sonstige Aktionen mehr. Durch ein letztes Patchlevel Release würde sich dann auch unser neuer Ext Name schon mal etablieren, da RTNG ohnehin schon ausserhalb von phpBB.de bekannt wurde. Und uns würde das auch die nötige Zeit geben, in Ruhe den Umbau zu machen, während jeder Admin problemlos noch das "alte" RTNG herunterladen kann, auf dessen Basis wir das "neue" machen.

[IMC]

ob ich als Co. noch Zugriff auf das neue Repo haben, wenn du das privat setzt. Wenn du das mal machen könntest...

Ich habe es jetzt auf Privat gesetzt.
Da keine Warnung kam, und bei dir immer noch "Direct access" steht, gehe ich davon aus dass du Zugriff hast.

[LukeWCS]

Klappt prima, habe Zugriff, Push tut ebenfalls.

edit:

Reset auf einen vorherigen Commit und Force Push klappt auch. Wunderbar, damit ist der Weg über Import generell gangbar.

[LukeWCS]

Thorsten, durch das Thema von chris1278 "nebenan", ist mir eine weitere Macke aufgefallen. Im Listener Code fiel mir etwas auf, das ich dann im phpBB Source genauer untersucht hatte. Es geht um die User Defaults. Um zu sehen ob meine erste Beurteilung korrekt ist, habe ich einen Test durchgeführt mit 2 neuen Usern "rt1" und "rt2".

Um das testen zu können, habe ich die ACP-Defaults so gesetzt:

Anzeigeort: Unten
Anzahl Aktuelle Themen: 10
Nach Themen Startzeit sortieren: Ja
Nur ungelesene Themen anzeigen: Ja

Dann der Reihe nach rt1 registriert (E-Mail aus) und rt2 (E-Mail an). Ergebnis:

rt1
[ externes Bild ]

rt2
[ externes Bild ]

Bei rt1 wurden nur die Migrations-Defaults gesetzt, nur bei rt2 wurden, wie es korrekt ist, die ACP-Defaults gesetzt. Sowas fällt natürlich nur dann auf, wenn man auch im ACP abweichende Defaults definiert hat. Ursache ist ein falsches Event, welches im phpBB Source innerhalb eines Blocks ausgeführt wird mit der Bedingung ($config['email_enable']). Ergo wird der Block nicht ausgeführt und somit auch nicht das Event, wenn E-Mail deaktiviert ist. Ich guck mir das heute Abend genauer an und mach dann vorab mal pl16 als Fix. Ein passendes Event habe ich schon, aber das muss ich dann noch testen.

[IMC]

Thorsten, durch das Thema von chris1278 "nebenan", ist mir eine weitere Macke aufgefallen.

Als du chris1278 gebeten hast die E-Mailfunktion auszuschalten bin ich sofort wach geworden.
Ich habe es schon getestet. Mit den darauf folgenden Event core.ucp_register_register_after funktioniert es auch mit abgeschalteter E-Mail.

Den Fix kann ich in meine Änderungen mit einarbeiten. Ist schnell gemacht.

[chris1278]

Das kann ich bestätigen. Auch bei meiner Extension geht das.

[LukeWCS]

Als du chris1278 gebeten hast die E-Mailfunktion auszuschalten bin ich sofort wach geworden.

hrhrhr demnächst beenden wir noch gegenseitig unsere Sätze... und dann wirds bedenklich.

Jupp, exakt das Event wollte ich nehmen, da wir aus dem Event Paket nur user_id benötigen, und das wird von diesem Event genauso geliefert.

Den Fix kann ich in meine Änderungen mit einarbeiten. Ist schnell gemacht.

Jut, dann kann ich mich ja wieder LFWWH widmen, da ärgere ich mich gerade auch mit einem Problem rum, welches im Zuge meiner RT Tests bezüglich dem Register-Defaults-Problem aufgetreten ist. Kaum hat man ein Loch gestopft, entdeckt man gleich das nächste.