phpBB.de

Hallo
Beim testen meiner EXT Average Daily Posts and Topics on Index unter 3.3.16 ist mir aufgefallen dass wenn man die Arbeitsdaten löscht, das ACP Modul in der Modul-Konfiguration im ACP weiterhin vorhanden ist. Dieses Verhalten konnte ich bei WWH auch nachvollziehen.
Ich hab mir mal die Code Changes angesehen, da wurde in der migrator.php das hier geändert. Macht man diese Änderung rückgängig, dann wird das Modul auch korrekt entfernt. Des weiteren ist mir aufgefallen da ich jenes public function revert_data() auch in anderen EXTs drin habe, dort beim löschen der Arbeitsdaten nichts zurück bleibt. Nur wenn dieses oben genannte in einer migrations Datei vorhanden ist wo die ACP Module module.add erstellt werden, kommt es zu diesem Verhalten. Dies ist z. B. in dieser sowie bei WWH EXT der Fall.

Ich bin noch nicht dazu gekommen das alles selber anzuschauen, aber hier mal vorab einer meiner Beiträge von unserem privaten Bastelforum als zusätzliche Info:

LukeWCS hat geschrieben: Okay, das würde heissen, dass das dort auftritt, wo Rechte manuell entfernt werden. Und genau das war mal irgendwann notwendig, weil der Migrator das nicht selbst machte. Das hatte ich ja mal festgestellt und hier gemeldet. Irgendwann konnte der Migrator das dann selbst, aber das ist ja eben trotzdem noch in unseren Exts vorhanden teilweise. Das hiesse also, das primär sehr alte Exts betroffen sind, die noch zu 3.1 und 3.2 Zeiten entstanden sind.

Nach meiner Einschätzung dürfte dieses Problem bei allen Exts auftreten, wo Rechte manuell per Migration entfernt werden. Mir ist aber noch der Zusammenhang mit den Modulen unklar. Da fehlt mir noch das sichten aller Infos und auch Tests.

edit: Aufgrund von Udos Erkenntnissen, habe ich den verantwortlichen Commit im phpBB Repo ermittelt:

[ticket/17533] Fix reverting migrations logic

Diesbezüglich hab ich im Tracker noch jenes gefunden: https://tracker.phpbb.com/browse/PHPBB- ... lter=16890

Ich habe neben "LF who was here" noch "Stats Permission", was ebenfalls betroffen ist. Da Udo bereits das Problem bei WWH entdeckt hat, musste ich das ja nicht mehr testen und habe stattdessen StatsPerm unter die Lupe genommen und folgendes festgestellt:

1. Das Migrator Tool permission.remove ist definitiv eine der möglichen Ursachen. Es könnte also auch noch andere Migrator Tools betreffen, das ist aber aktuell nur eine Vermutung. Dazu habe ich folgenden Test gemacht und die Migration von StatsPerm temporär geändert:

Original: Test: Der Code von "Test" ist natürlich sinnfrei, aber er hat das zutage gefördert, was ich wissen wollte, also ob alleine die Existenz von revert_data() das Problem ist, oder eine oder mehrere Anweisungen (Migrator Tools) das Problem darstellen. Beim Original Code tritt exakt das auf, was Udo bereits geschildert hat: Nach der Installation verbleibt das ACP Modul als "Geister-Modul" in der DB. Ändere ich die Migration testweise ab wie oben gezeigt, dann wird das Modul wie es sein sollte entfernt.

Laut Stichproben in meinem lokalen Erweiterungen Ordner habe ich festgestellt - wie nicht anders erwartet - das davon etliche Entwickler und somit viele Erweiterungen betroffen sind, die in der Vergangenheit permission.remove in der Migration eingebaut haben.

2. Seltsamerweise gibt es bei einer solchen Ext mit Modul Artefakt nach der Deinstallation keine Probleme, wenn man die Ext erneut installiert. Die Installation verläuft dann trotzdem ohne Fehlermeldung seitens des Migrators. Das irritiert mich im Moment sehr, denn in so einem Fall müsste der Migrator eigentlich einen Fehler melden, dass ein Modul mit diesem Namen schon vorhanden ist.

edit: Korrektur für Punkt 2: Das hängt laut Test von Udo offensichtlich von der Ext ab und ist nicht allgemeingültig.
edit2: Korrektur für Punkt 1, letzter Absatz: Nach aktuellen Kenntnisstand, betrifft das vermutlich eher wenige Erweiterungen.

Hello, wenn einem ein deartiges Verhalten zuvor in irgendeiner Weise bekannt gewesen wäre, hätten sich EXT-Autoren meiner Meinung nach, viele Sorgen und ein Suchen ersparen können.

Insofern danke ich euch, da auch ich so manches Mal an meinem Verstand gezweifelt habe. Es wäre mir vieles erspart geblieben.

Auf die Entwicklungen seitens der Entwickler (Com) bin nun bereits ehrfüchtig neugierig.

Liebe Grüße


====
Edit: Leider wurden nicht alle wesentlichen ausführlichen Bestandteile (Release highlights) etc. (Fehler) deutlich erwähnt.

====
Edit:
Sorry. Augenscheinlich habe ich das insgesamt vorab bei der Ankündigung in Teilen übersehen.

Zu 1.
Konnte dies bei meiner EXT 1:1 nachstellen.
Zu 2.
Wenn ich bei meiner EXT die Arbeitsdaten lösche und danach erneut versuche diese zu Installieren, bekomme jenes angezeigt: Mit deiner StatsPerm EXT hatte ich beim erneuten inst. auch keine Probleme.

Ja, genau diese Meldung hatte ich eigentlich erwartet. Hätte auch sein können, dass das ein lokales Problem bei mir im TB wäre. Und das wäre ja auch nicht das erste Mal, denn da spielt meist der phpBB Cache eine Rolle. Es haben schon mehrere Ext Entwickler festgestellt, dass der Cache bei den Aktionen "Aktivieren/Deaktivieren/Arbeitsdaten löschen" manchmal entweder nicht vollständig gelöscht oder aber nicht mehr vollständig aufgebaut wird. Das ist aber ein Fehler der nicht gezielt provoziert werden kann und somit ist Fehlersuche nahezu aussichtslos.

Wenn du das aber auch mit StatsPerm festgestellt hast, müsste es ja einen ermittelbaren Unterschied geben. Aber okay, das ist jetzt eher ein sekundäres Problem.

Hab das als Edit in meinem Beitrag für Punkt 2 vermerkt.

Neuester Zwischenstand, Udo und ich haben weitere Tests durchgeführt:

• Die Einschätzung, dass davon viele Erweiterungen betroffen wären, trifft nach aktuellem Kenntnisstand eher nicht zu. Entsprechend habe ich beim relevanten Beitrag von mir noch einen zweiten Edit hinzugefügt.
• Die Modul Artefakte sind nur ein Teil des Problems: bei den betroffenen Erweiterungen werden ausserdem auch nicht alle config Variablen entfernt. Das konnten Udo und ich unabhängig mit je einer eigenen Ext zuverlässig reproduzieren.
• Bei mir trat ausserdem das Problem auf, dass nach einer Installation bestimmte config Variablen schlicht einen falschen Wert hatten. Aber das scheint wohl erneut ein Cache Problem gewesen zu sein, denn nachdem ich diesen einmal manuell gelöscht hatte, trat der Fehler bei erneuter Installation nicht mehr auf.

Aktuellste Vermutung: Momentan sieht es so aus, als ob speziell die Methode revert_data() mit der Migrator Anweisung permission.remove das Problem darstellt. Das wird auch von meinem Test gestützt, den ich bereits oben erwähnt hatte. Wenn ich die Migration testweise wie angeben präpariere, dann gibt es bei der Deinstallation keine Artefakte, weder bei den Modulen, noch bei den config Variablen. Das wurde auch gestützt von etlichen weiteren Tests mit anderen Erweiterungen, die zwar ebenfalls revert_data() und permission.remove in den Migrationen verwenden, aber eben nicht kombiniert wie bei den Erweiterungen von Udo und mir.

Ticket ist jetzt erstellt:

[PHPBB-17650] Migrator bug prevents complete uninstallation for certain extensions - phpBB Tracker

edit: Von unserem Bastelforum

LukeWCS hat geschrieben:7.5.2026:
Hab noch eine Ext mit der Kombi gefunden, das Original "Recent Topics 2.2.13". Aber das lässt sich unter PHP 8 ja nicht mal mehr installieren.

edit2: Ich habe auch in unserem Bastelforum nach meinem Beitrag gesucht, wo ich das den Kollegen gemeldet hatte, dass der Migrator nicht selbständig Berechtigungen entfernt bei der Deinstallation. Zu dem Zeitpunkt war phpBB 3.2.3 die aktuellste Version.

LukeWCS hat geschrieben:15.10.2018:
Ich habe ausserdem festgestellt, das man für Rechte in den Migrationsdateien explizit eine Deinstallation einbauen muss. So wie du es realisiert hast, würden die Rechte bei "Arbeitsdaten löschen" nicht automatisch entfernt werden. Bei Rechten gelten da wohl andere Regeln.

Irgendwann viel später (Jahre) hatte ich dann festgestellt, das phpBB die Berechtigungen selber löscht. Zu dem Zeitpunkt war phpBB 3.3.11 die aktuellste Version.

LukeWCS hat geschrieben:31.3.2024
Das ist, glaube ich, gar nicht mehr nötig. Vor ewigen Zeiten hat phpBB ja nicht die Rechte selber entfernt, bemerkt hatte ich das damals bei WWH. Müsste man aber aktuell testen.

Update: Ich habe auf .com eine weitere Ext entdeckt die betroffen ist, AnubisBB. Ich wollte mich eigentlich über den aktuellsten Stand informieren, dabei fiel mir das Gespräch zwischen Prosk8er und NeoDev auf, ab hier lesen:

Re: [3.3][ALPHA] AnubisBB - proof-of-work bot defense