Adding server-side plugin disabling to safe mode

Dev
1

I find that folks often first try safe mode whenever anything breaks and they’re using 3rd party customisations. This makes sense. You don’t know where the issue is coming from.

However, safe mode only disables javascript. If there’s any server-side code, typically the immediate solution is to un-comment all plugins in the app.yml file. That’s fine, however it requires a rebuild and is relatively ‘technical’. If you’re a non-technical user, commenting out stuff in the app.yml is not something you take to lightly.

I’m wondering about the viability of a PR that adds in server-side plugin disabling in safe mode. I’m thinking something along the lines of this in the 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

Yes, the same effect could be achieved by the user going through their site settings and switching the plugins off that way, however I find that users rarely actually do this.

2 Likes
2

Current safe mode is just for the current page and goes away in a new tab or a refresh. So it is completely safe for testing.

Your proposal would change the meaning of it into flipping a setting persistently, affecting the entire site. That means it also needs to be restricted to admins.

I understand your proposal, but it’s a big change in behavior.

3 Likes
3

True.

I think the key point is that non-technical site admins look for a fix to get their site working when it’s broken. A “Safe mode” is often perceived to do that (rightly or wrongly). Perhaps a way to do this would be to have additional admin safe-mode controls.

You could add a big button in the /admin/plugins route to automatically disable all plugins in the same way, however I wonder whether it would have the same effect. Perhaps it would.

I’m also drawn to this as it’s quite doable within the current Discourse plugin architecture.

5 Likes
4

What do you think @sam?

5

Usually the stuff that breaks plugins are incompatible core changes, often things don’t even boot if you include a problem plugin, or bootstrap

An all plugins off feature would have to restart the app somehow to be correct

I think I would be open to a docker manager plugin change that would allow you to easily disable/enable plugins by moving stuff in and out of the plugins directory and restart the app, it could make debugging faster

4 Likes
6

I think that would be good as well.

However, I do find that a not in-substantial number of errors come from code wrapped in the server-side plugin api, which would be handled by this (I think?).

Currently, the ‘safe mode’ (or something like it) is not a complete solution to breaking issues either. Adding a automatic disabling of plugins would make it a slightly better solution, reducing the number of instances in which a full restart / config change is required, and better reflecting how non-technical site admins see it.

I guess I’m looking for incremental relatively easy steps. Perhaps the docker manager change is equally straightforward from a technical perspective.

7

Yes, if possible someday, it would be very good to have a single “disable all plugins” boolean in the admin settings, which works without any container rebuilding. However, not being a Discourse developer (having only a year of node.js, vuejs app development), my instincts tell me this is not an easy change and would be a very big change to the architecture.

Our legacy LAMP forum had this feature and we cannot count the times we used this boolean to quickly trap an error as related to plugins. However, the software architecture is so different, it’s not even useful to compare.

I’m personally confident the Discourse Team will come up with something. Lot’s of users are addicted to plugins and there will be more dragons over time.

Thanks for looking into this.

1 Like
8

A big factor for me is that this feature would be 100% for self hosters, I don’t really want to carry a safe mode for plugins in core, it is certainly not something we would use, coordinating a restart across 5 clusters is hard

Docker manager is the right vehicle here, it already supports restarting the app, something that you need for your proposal to work and it can do all of the stuff it needs without changes to discourse core

5 Likes
9

Got it. I’ll focus my attention there.

4 Likes