[3.3] [CDB][3.3] Erweiterungen komplett Aktivieren/Deaktivieren

[IMC]

Aus meiner Sicht gibt es zwei Lösungsansätze.

Bei Extensionen, bei denen die Abhängigkeiten bereits bekannt sind, kann das Array zum Aktivieren/Deaktivieren vorher in die richtige Reihenfolge gebracht werden.

Bei Extensionen, bei denen nicht bekannt ist ob eine Abhängigkeit besteht kann die ext.php vorher eingelesen werden und auf Abhängigkeiten untersucht werden. Dies kann je nach Komplexität ein kleine Herausforderung werden. Kann aber auch einfach gehalten werden.

[LukeWCS]

Moin IMC

Bei Extensionen, bei denen die Abhängigkeiten bereits bekannt sind, kann das Array zum Aktivieren/Deaktivieren vorher in die richtige Reihenfolge gebracht werden.

Wie willst du das automatisiert in Erfahrung bringen? Also die bekannten Abhängigkeiten? Das ginge eigentlich nur über manuelle Erfassung einer Abhängigkeitsliste, weil phpBB keinen Abhängigkeitsmechanismus für Erweiterungen bietet. Das wäre ein Fass ohne Boden, wer pflegt sowas?

Bei Extensionen, bei denen nicht bekannt ist ob eine Abhängigkeit besteht kann die ext.php vorher eingelesen werden und auf Abhängigkeiten untersucht werden. Dies kann je nach Komplexität ein kleine Herausforderung werden. Kann aber auch einfach gehalten werden.

Einen Parser für die ext.php zu schreiben ist keine triviale Angelegenheit und würde den Rahmen von ExtOnOff bei weitem sprengen. Ausserdem gibt es viele "kreative Ideen" wie man eine ext.php benutzen kann, wie ich in den letzten Jahren gesehen habe. Für die ext.php gibt es keinen bindenden Standard. Dementsprechend kann da jeder im Prinzip machen was er will. Das automatisiert zu parsen und alle Varianten berücksichtigen zu wollen, wäre also ebenfalls ein Fass ohne Boden und hochgradig fehleranfällig.

Wenn die Ext anzeigen würde, welche Ext den Prozess unterbrochen hat, wäre schon viel gewonnen. Dann kann der Admin gezielt danach schauen. Das untersuchen wir z.Z., was aber auch nicht trivial ist, weil es in phpBB ja nie vorgesehen war, mehr als eine Ext gleichzeitig zu aktivieren. Dementsprechend war es auch nie nötig, dass phpBB explizit anzeigt, welche Ext gerade versucht wurde zu aktivieren oder deaktivieren.

Als mittelfristige Lösung müsste bei den betreffenden Exts (2) einfach eine bestimmte - und technisch gesehen unnötige - Abhängigkeitsprüfung entfernt werden. Langfristig braucht man natürlich eine andere Lösung.

[IMC]

Hi Luke,

Mein Post sollte nur ein paar Ideen geben für eine spätere Lösung bzw. Umsetzung des Problems. In wieweit diese praktikabel und umsetzbar sind muß am ende Chris entscheiden.

Also die bekannten Abhängigkeiten? Das ginge eigentlich nur über manuelle Erfassung einer Abhängigkeitsliste,

So hatte ich das gemeint.

Einen Parser für die ext.php zu schreiben ist keine triviale Angelegenheit und würde den Rahmen von ExtOnOff bei weitem sprengen. Ausserdem gibt es viele "kreative Ideen" wie man eine ext.php benutzen kann, wie ich in den letzten Jahren gesehen habe. Für die ext.php gibt es keinen bindenden Standard.

In dem Code von phpBB stecke ich leider nicht so tief drin. Im ersten Moment hätte ich gedacht das ich in der ext.php die Zeichenkette ->is_enabled( suche und dann schaue ob eine, und wenn welche Extension dort abgefragt wird. Wenn es eine Vielzahl von Möglichkeiten gibt um zu prüfen ob eine Extension bereits aktive ist kann dies natürlich nicht die Lösung sein.

Ich könnte mir aber auch vorstellen das der Admin auf der Settingpage dieser Extension einmalig festlegt welche Extensionen und in welcher Reihenfolge diese automatisch aktiviert werden sollen. Dieser sollte schon wissen wie die Abhängigkeiten seiner installierten Extensionen sind. Dies würde ich ähnlich wie bei der "Sortable Captcha" Extension umsetzen.

Aber wie ich schon schrieb, dies sind nur ein paar Ideen. Die Lösung kann und wird am Ende ganz anders aussehen.

[LukeWCS]

nAbend IMC

Die angesprochene Fehlermeldung von phpBB kann durch zig verschiedene Bedingungen getriggert werden. Die Abhängigkeit zu einer anderen Ext ist nur eine davon. Wenn zum Beispiel ein Admin PHP hochstuft, dann irgendwann mal später mit extonoff alles deaktiviert und anschliessend wieder aktiviert, kann das dazu führen, dass eine der Exts nicht mehr aktiviert werden kann, weil die PHP Version jetzt zu hoch ist. Oder die phpBB Version. Oder irgendwas anderes nicht mehr passt.

Dementsprechend wäre es ein ziemlich "schwieriges" Unterfangen einen Parser für ext.php bauen zu wollen.

[IMC]

Ich habe eine Methode gefunden die laut der Beschreibung die Lösung sein könnte.
https://area51.phpbb.com/docs/code/3.3. ... enableable
Ich bin die nächsten Tage ohne PC. Kann es deshalb nicht testen.

[LukeWCS]

nAbend

https://area51.phpbb.com/docs/code/3.3. ... enableable

Ja, exakt diese Methode wird innerhalb einer ext.php verwendet um phpBB mitteilen zu können, ob die Ext aktiviert werden darf oder nicht. Du verwendest sie übrigens schon selbst, bei "Image upload use ImageMagick".

Das ist eine Trigger Funktion, mit der quasi von der Ext an phpBB ein Signal (boolean) gesendet werden kann. Damit kannst du also nicht umgekehrt von phpBB prüfen lassen, ob sich eine Ext aktivieren lassen "würde". Klingt paradox, ich hoffe du kannst es trotzdem nachvollziehen.

[IMC]

Das ist eine Trigger Funktion, mit der quasi von der Ext an phpBB ein Signal (boolean) gesendet werden kann. Damit kannst du also nicht umgekehrt von phpBB prüfen lassen, ob sich eine Ext aktivieren lassen "würde". Klingt paradox, ich hoffe du kannst es trotzdem nachvollziehen.

Genau dass ich dies prüfen lassen kann hatte ich gedacht.
Ich hatte Code im Core gefunden der mich zu der Annahme verleitet hat. Ich mache in der nächsten Woche mal etwas "Trial & Error". Auch wenn nur Error dabei raus kommt habe ich auf alle Fälle was dazu gelernt.
Morgen geht es in die Eifel.

[chris1278]

Morgen geht es in die Eifel.

Grüss mir meine heimat!

[LukeWCS]

Gute Reise IMC.

Kleine Zwischen-Info für diejenigen, die ExtOnOff testen. Neue Möglichkeiten können auch neue Probleme mit sich bringen, so auch bei ExtOnOff. In den letzten Tagen sind uns mehrere Probleme aufgefallen, die jedoch allesamt keinerlei Gefahr für phpBB oder die Exts darstellen. Diese sind wie folgt:

• Da ExtOnOff direkt die Funktionen des ExtManagers nutzt, wird selbstverständlich auch eine vorhandene ext.php ausgeführt, die unter anderem dazu genutzt werden kann, Voraussetzungen zu prüfen. Sollte dabei eine Ext aufgrund dieser Prüfung eine Aktivierung verweigern, hat das einen sofortigen Abbruch der Aktion "Alle Erweiterungen aktivieren" zur Folge. Das ist ein Problem das wir momentan nicht lösen können, weil uns dazu Funktionalitäten von phpBB fehlen. Zum Beispiel bietet phpBB keine Möglichkeit einen Vorgang fortzusetzen, wenn eine Ext nicht aktiviert werden kann. In diesem Fall wird die entsprechende phpBB Fehlermeldung getriggert und die Ausführung von ExtOnOff wird somit abgebrochen. Das kann nicht verhindert werden.
• In diesem Zusammenhang zeigte sich eine weitere Schwäche von phpBB; Standardmeldungen können nicht um zusätzliche Informationen erweitert werden. Es gibt dafür schlicht keine Funktion. Eine Änderung der passenden Sprachvariable ist auch nicht möglich, weil das gesamte Sprachobjekt nach dem Laden geschützt ist. Man ist hier also leider dazu gezwungen "Tricks" anzuwenden. Denn wenn eine Ext den Vorgang unterbricht, muss der Admin auf jeden Fall die Information bekommen, welche Ext den Vorgang unterbrochen hat, egal wie. Dafür habe ich eine Möglichkeit gefunden, die dann bei 1.0.1 integriert sein wird.
• Des Weiteren hat Kirk festgestellt, dass nach der Aktivierung bei manchen ACP-Exts keine Anzeige mehr sichtbar ist. Also bei Exts die im ACP im globalen Bereich zusätzliche Anzeigen/Links zur Verfügung stellen. Bei der Untersuchung dieses Problems habe ich festgestellt, dass der Cache dafür verantwortlich ist. Präzise gesagt der Twig Cache wird nicht mehr vollständig aufgebaut. Dieses Problem haben wir die letzten 2 Tage untersucht und einen brauchbaren Workaround gefunden. Auch das wird dann bei 1.0.1 integriert sein.

Bis 1.0.1 verfügbar ist, genügt es nach dem deaktivieren und reaktivieren einfach den Forencache zu löschen.

[LukeWCS]

Zwischendurch ein kleines Info-Update:

Bei Punkt 1 muss man differenzieren, wie wir inzwischen in unserem kleinen Bastel Forum gelernt haben. Das eine Ext den Aktivierungsvorgang abbricht, ist nicht Standard. Ich habe mir viele Exts angeschaut, bei denen die Autoren eine ext.php verwenden, um die Voraussetzungen zu prüfen. Solange "nur" die Voraussetzungen geprüft werden, jedoch keine eigene Fehlerbehandlung implementiert wurde, wird eine Ext, die sich nicht aktivieren lässt, ganz einfach "übersprungen". Das heisst ExtOnOff kann dann problemlos mit den anderen Exts fortfahren.

Punkt 2: Nur einige wenige Exts haben eine solche eigene Fehlerbehandlung und für diese Exts haben wir inzwischen eine zusätzliche Anzeige eingebaut, damit der Admin auf jeden Fall informiert wird, welche Ext genau den Vorgang unterbrochen hat. Somit sind solche Exts weniger problematisch, weil man so immerhin erfährt, welche das ist.

Punkt 3: Dafür haben wir inzwischen einen tatsächlich funktionsfähigen Workaround gefunden. Der erste Workaround (4.5.2022) hat sich leider als unbrauchbar erwiesen. Der neue hat dagegen inzwischen zig hunderte von Deaktivieren/Aktivieren Vorgängen erfolgreich absolviert, ohne auch nur ein einziges Mal ein Problem zu verursachen. Alle ACP-Exts funktionierten nach dem Aktivieren wie sie sollen.

Darüber hinaus wird die nächste Version etliches Neue bringen. Neben einigen sichtbaren Änderungen und Neuerungen sind das vor allem viele subtile Verbesserungen und auch Fixes.