Hinzufügen der serverseitigen Plugin-Deaktivierung zum abgesicherten Modus

Entwickler
1

Ich stelle fest, dass Nutzer oft zuerst den abgesicherten Modus ausprobieren, wenn etwas nicht funktioniert und sie Drittanbieter-Anpassungen verwenden. Das ist nachvollziehbar. Man weiß nicht, woher das Problem kommt.

Der abgesicherte Modus deaktiviert jedoch nur JavaScript. Wenn es serverseitigen Code gibt, besteht die übliche Sofortlösung darin, alle Plugins in der app.yml-Datei wieder zu aktivieren (auskommentieren). Das ist in Ordnung, erfordert jedoch einen Neuaufbau und ist relativ „technisch“. Wenn Sie kein technisch versierter Nutzer sind, sollten Sie Dinge in der app.yml nicht leichtfertig auskommentieren.

Ich frage mich, wie praktikabel ein PR wäre, der das Deaktivieren serverseitiger Plugins im abgesicherten Modus ermöglicht. Ich denke an etwas in der Art im Safe-Mode-Controller:

find_opts = {
  include_official: params["only_official"] != 'true',
  include_unofficial: params["no_plugins"] == "true"
}
      
Discourse.find_plugins(find_opts).each do |plugin|
  if plugin.enabled_site_setting.present?
    SiteSetting.set(plugin.enabled_site_setting, false)
  end
end

Ja, denselben Effekt könnte man erreichen, indem der Nutzer durch seine Seiteneinstellungen geht und die Plugins dort deaktiviert. Allerdings stellen wir fest, dass Nutzer dies selten tatsächlich tun.

2

Der aktuelle abgesicherte Modus gilt nur für die aktuelle Seite und wird in einem neuen Tab oder nach einem Neuladen deaktiviert. Er ist also für Tests völlig unbedenklich.

Ihr Vorschlag würde die Bedeutung dahingehend ändern, dass eine Einstellung dauerhaft umgeschaltet wird und die gesamte Site betrifft. Das bedeutet, dass dies ebenfalls auf Administratoren beschränkt werden muss.

Ich verstehe Ihren Vorschlag, aber es handelt sich um eine erhebliche Änderung des Verhaltens.

3

Stimmt.

Ich denke, der Kernpunkt ist, dass nicht-technische Administratoren nach einer Lösung suchen, um ihre Website wieder funktionsfähig zu machen, wenn sie gestört ist. Ein „Sicherer Modus

4

Was denkst du, @sam?

5

Normalerweise sind es inkompatible Kernänderungen, die Plugins zum Absturz bringen. Oft startet das System gar nicht mehr, wenn Sie ein fehlerhaftes Plugin oder einen fehlerhaften Bootstrap enthalten.

Eine Funktion zum vollständigen Deaktivieren aller Plugins müsste die Anwendung auf irgendeine Weise neu starten, um korrekt zu funktionieren.

Ich wäre offen für eine Änderung des Docker-Manager-Plugins, die es ermöglicht, Plugins einfach zu deaktivieren oder zu aktivieren, indem man Dateien in das Plugins-Verzeichnis verschiebt oder daraus entfernt und die Anwendung neu startet. Das könnte das Debugging beschleunigen.

6

Ich denke, das wäre ebenfalls gut.

Allerdings finde ich, dass eine nicht unbeträchtliche Anzahl von Fehlern aus Code stammt, der in die serverseitige Plugin-API eingewickelt ist, was damit abgefangen würde (glaube ich zumindest).

Derzeit ist der „Safe Mode

7

Ja, falls es irgendwann möglich ist, wäre es sehr gut, in den Admin-Einstellungen eine einzelne boolesche Option „Alle Plugins deaktivieren

8

Ein wesentlicher Faktor für mich ist, dass dieses Feature zu 100 % für Self-Hoster gedacht wäre. Ich möchte einen Safe-Mode für Plugins nicht im Kern mitführen, da wir ihn definitiv nicht nutzen würden. Die Koordinierung eines Neustarts über fünf Cluster hinweg ist schwierig.

Der Docker-Manager ist hier das richtige Werkzeug. Er unterstützt bereits das Neustarten der Anwendung – eine Voraussetzung für Ihren Vorschlag – und kann alle erforderlichen Aufgaben ohne Änderungen am Discourse-Kern erfüllen.

9

Verstanden. Ich werde mich dort konzentrieren.