phpBB.de

migoe hat geschrieben: ↑19.06.2022 11:54 Das ist tatsächlich ein Übertragungsfehler

Danke für die Rückmeldung.

"Eigentlich" benenne ich die Ordner auf dem Server immer um und übertrage dann alle Dateien und Ordner bei, aber diesmal habe ich die Dateien doch wieder einfach nur drüberkopiert. Jetzt habe ich es aber hoffentlich kapiert!

Schau mal in meine Sig im ersten Link unter Punkt 4.c. Da wird erklärt, warum Exts beim Update nicht überschrieben werden dürfen.

Den Binärmodus habe ich aber mittlerweile aktiviert, was aber trotzdem nicht bedeutet, dass Fehler bei der Übertragung passieren können.

Richtig, Übertragungsfehler kann das nicht verhindern.

Aber der Auto-Modus war in der Vergangenheit schon oft die Quelle für unnötige Probleme. Im phpBB Umfeld immer im Binär-Modus hochladen, weil dann der FTP Client nicht in den hochzuladenden Dateien "herumbastelt", sondern die Dateien exakt so überträgt, wie sie der Autor erstellt hat. Wenn der Auto-Modus in manchen Situationen die notwendigen Parameter nicht korrekt ermittelt, dann werden Dateien u.U. kaputtkonvertiert.

Wir haben dafür auch einen eigenen KB Eintrag: Knowledge Base - Binär (BINARY) != ASCII - Beim Upload des Forums beachten

EMP 1.0.3 veröffentlicht.

Luke
Hast du eine Lösung für den Fall dass eine Erweiterung den Zugriff aufs Forum verhindert? Es gibt ja das Script von David63 von .com für solche Fälle, mit dem alle Erweiterungen sauberer deaktiviert werden können als nur die Aktivierung über phpmyadmin auf Null zu setzen.
Eine Lösung von dir würde ich bevorzugen.

Haiopaio. Nein das geht auch mit dem Script von david nicht. Wenn du z.B. einen Fehler hast der ne Weisse seite direkt bei Aufruf erzeugt musst du auch dort direkt in die DB das deaktivieren.

@HaioPaio

Da du von "Skript" sprichst, nehme ich an, du meinst nicht die Ext von david63, sondern seinen Artikel:

https://www.phpbb.com/support/docs/en/3 ... s-at-once/

HaioPaio hat geschrieben: ↑25.06.2022 10:03 Hast du eine Lösung für den Fall dass eine Erweiterung den Zugriff aufs Forum verhindert? Es gibt ja das Script von David63 von .com für solche Fälle, mit dem alle Erweiterungen sauberer deaktiviert werden können als nur die Aktivierung über phpmyadmin auf Null zu setzen.

Auch wenn EMP die Seite "Erweiterungen verwalten" komplett ersetzt, ist es dennoch auf die grundsätzliche Funktionsfähigkeit des ACPs und des ExtMgr angewiesen. Einen wirklich brauchbaren Rettungsanker bei blockierenden Exts kann man nur mit separaten Lösungen realisieren, die möglichst wenig bis gar nicht auf phpBB Komponenten angewiesen sind.

Das Skript von david63 bindet nur die absolut nötigsten Komponenten von phpBB ein und deaktiviert alle Exts auf ordentlichem Weg, bei dem auch eine vorhandene ext.php bei den einzelnen Erweiterungen ausgeführt wird. Es wird hier also mit der gleichen Technik gearbeitet wie auch bei EMP oder phpBB selbst, aber ohne dabei auf eine funktionierende Login-Infrastruktur angewiesen zu sein.

Eine Lösung von dir würde ich bevorzugen.

Das Skript von david63 ist bereits eine gute Lösung um Exts ausserhalb von phpBB noch sauber deaktivieren zu können. Erst wenn das auch nicht mehr möglich ist, sollte/muss man die direkte DB Methode wählen. Per phpMyAdmin oder anderen MySQL Clients zu hantieren, oder mit dem STK, ist also quasi die absolute Notlösung wenn alles andere versagt.

edit: Korrektur. Das Skript von david63 setzt voraus, dass in der aktuellen Session noch ein Gründer eingeloggt ist/war. Habe es mir gerade näher angeschaut. Eigentlich logisch, denn es arbeitet mit den ExtMgr Funktionen von phpBB und diese sind automatisch an die Login-Infrastruktur gekoppelt.
edit2: @Kirk, danke für den Hinweis bezüglich Reihenfolge/Ignorieren. Startbeitrag korrigiert. Hatte ich gestern vergessen.

LukeWCS hat geschrieben: ↑25.06.2022 11:01Das Skript von david63 bindet nur die absolut nötigsten Komponenten von phpBB ein und deaktiviert alle Exts auf ordentlichem Weg, bei dem auch eine vorhandene ext.php bei den einzelnen Erweiterungen ausgeführt wird. Es wird hier also mit der gleichen Technik gearbeitet wie auch bei EMP oder phpBB selbst, aber ohne dabei auf eine funktionierende Login-Infrastruktur angewiesen zu sein.

Ich habe eben mit dem Skript etwas herum gespielt.

Wenn ich nicht am Board angemeldet bin wird bei der Ausführung des Skripts der Login gestartet. Dieser sollte in dem Fall beim Aufruf auch Funktionieren.

Nachdem das Skript alle Extensions deaktiviert hat werden sie dennoch im ACP angezeigt. Sie sind zwar alle deaktiviert aber nicht aus dem Cache entfernt. Diesen musste ich manuell leeren.

Testboard: phpBB 3.3.8-RC1

IMC hat geschrieben: ↑25.06.2022 15:20 Wenn ich nicht am Board angemeldet bin wird bei der Ausführung des Skripts der Login gestartet.

Ja alles andere wäre ja auch mehr als nur gefährlich. Stell dir mal vor jemand kann sich ohne einloggen das skript aufrufen und alle erweiterungen deaktivieren. Ne das muss man net haben.

Das war nur als Hinweis geschrieben dass der Login bei der Verwendung des Skripts funktionieren muss.

Wegen Login, jupp das Skript benötigt entgegen meiner ersten Aussage einen Login. Hatte das im Edit ja richtig gestellt.

IMC hat geschrieben: ↑25.06.2022 15:20 Nachdem das Skript alle Extensions deaktiviert hat werden sie dennoch im ACP angezeigt. Sie sind zwar alle deaktiviert aber nicht aus dem Cache entfernt. Diesen musste ich manuell leeren.

Ja, grad geschaut, in dem Skript ist kein cache->purge() eingebaut. Das wäre eig. wichtig, wenn es um das Schalten von Exts geht. Insbesondere wenn Exts deaktiviert werden.

Gut, davon abgesehen ist das Skript ein Werkzeug für den Notfall. Mit EMP und Co. hat das nüscht zu tun.

Es gibt aktuell ein Problem mit der Funktion "Berechtigungen des Benutzers testen" in Kombination mit EMP: Wenn die besagte Funktion benutzt wird, gibt es eine Fehlermeldung (Fatal):

Fatal error: Cannot declare class auth_admin, because the name is already in use in ...

Die Meldung hat keinerlei Auswirkungen, das Forum kann danach also ganz normal erneut aufgerufen werden.

Wer "Berechtigungen des Benutzers testen" nutzen will, muss kurzfristig EMP deaktivieren. Ich habe inzwischen die Ursache gefunden, allerdings noch keine Lösung dafür. Mit der gemeldeten Klasse "auth_admin" hat EMP übrigens nicht direkt etwas zu tun.