A "safe mode" to easily disable all third party plugins

Feature
1

One common problem with Discourse installs:

  • you update to the latest version

  • due to internal Discourse changes, one of your plugins breaks

  • the plugin doesn’t just break, it breaks your entire site which now has JS errors or maybe even a white screen

  • you open a meta support topic about how updating Discourse broke your whole site :sadpanda:

  • we ask “hmm, did you try disabling all third party plugins”

We need a much easier way for people to enter ‘safe mode’ where only official Discourse plugins that are bundled with Discourse during a clean install are loaded.

I am open to whatever implementation makes sense, but switching to “safe mode” needs to be much easier to stem the flood of support topics on Discourse updates breaking third party plugins.

(This is on the official 1.7 release list as well.)

14 Likes
2

At risk of revealing my gross ignorance, please correct my assumptions about the processes.

  1. rebuild is initiated
  2. Discourse git pulled in
  3. plugin gits pulled in
  4. plugin Ruby gets added in
  5. plugin assets get compiled
  6. plugin may or may not be enabled

I’m guessing breakage caused by plugins can happen in a few places from either or both bad Ruby code / bad Ember code

I think it might be fairly easy to disable plugins after an upgrade forcing re-enabling one-by-one and checking for Ember errors at that point.

But I don’t know how / where isolating the plugin Ruby and asset compiling should be approached.

Maybe if plugins have rspec and qunit tests editing travis.yml “before_install:” in addition to editing app.yml could work?

3 Likes
3

The easiest would be to add a new “--safe” parameter to the launcher (eg “./launcher rebuild --safe”).
That parameter would then be passed to Discourse which would not load any of the non-blessed plugins.

3 Likes
4

It’s my understanding that we’re trying to keep ./launcher at least sort-of Discourse agnostic. My easiest recommendation would be to have either ./discourse-setup or some other new command that would comment out all non-blessed plugins and rebuild. I think it should have two modes, one that disables non-blessed plugins (is that as simple as the ones from the discourse github account?) and another that would disable all plugins.

A more complex solution would be a ./plugins script that would provide a way to install and remove individual plugins as well as disable them.

I started thinking about a ./help script that would do things like check available memory and ram, offer suggestions (e.g., suggest ./launcher cleanup), and print out disk and memory specs that could be pasted into a plea for help.

6 Likes
5

I will be taking this, so here is my amended spec :space_invader:

  1. Distribute a file with Discourse that lists the names of all “officially supported” plugins.

  2. Split out “plugin.js” from “application.js”, 2 assets will be split out:
    a: plugin-safe.js for all officially supported plugins
    b: plugin-third-party.js for unofficial plugins.

  3. Add a new ENV var for booting in safe mode: DISCOURSE_SAFE_MODE=1 if set then only supported plugins are installed

  4. Add a new ENV var for booting in “super safe mode”: DISCOURSE_SAFE_MODE=NO-PLUGINS if set no plugins at all are loaded

  5. If booted in safe mode, display a banner to all staff (or something along those lines) showing that site is in safe mode. Banner will link to docker manager page where you can quit safe mode

  6. Amend Docker Manager to allow you to “reload Discourse in Safe Mode” and “Exit Safe Mode”

Points I am thinking about:

  1. In safe mode what do we do about “site customizations” which can potentially break stuff? Current thinking, allow you to specify “how safe” you want stuff when entering safe mode.

  2. In safe mode what do we do about “color” customizations etc which may, in very rare cases, break stuff? Current thinking, do nothing.

  3. New structure will allow you to “preview in JavaScript safe mode” without restarting, if all you want to do is check the JS components of a plugin are not broken. Should we expose this? Current thinking, maybe…

3 Likes
6

As someone who might write a “disable all 3rd party plugins” script before this grand plan gets implemented, could it be the case that “officially supported” and "live at github under the discourse account be synonymous?

This seems like a fine idea, and given that there’s a means to preview and see not-yet-turned-on customizations, it should be easy enough to implement.

7

Looks like this is complete, so closing.

1 Like