Disable javascript for disabled plugins

AI 生成的摘要

The discussion revolves around the issue of disabled plugins in Discourse still loading their JavaScript, causing site breakages. david proposes a solution by adding a pre-processor that wraps plugin definitions, allowing Discourse to ignore definitions for disabled plugins. He has a working PR (https://github.com/discourse/discourse/pull/5103) that seems to work locally and on his instance. Mittineague questions whether there’s a way to force a disabled plugin to load for enabling purposes, and david responds that the admin interface still allows enabling the plugin without requiring JavaScript.

One of the main issues people seem to have on Meta is broken plugins. There is a natural assumption that ‘disabling’ a plugin in the admin interface will stop any issues caused by it. The reality is that plugin javascript is still loaded, and can still completely break Discourse.

I have a working PR which ‘fixes’ this behaviour.

If you’ve ever looked at the plugin_third_party.js file, you’ll know it looks something like this (eval only used in development, but similar idea in production)

I’ve added a pre-processor which wraps those definitions so they end up like this:

Then, before the application starts up, discourse.js steps through each one of those definitions, and will ignore any definitions for disabled plugins. (we already have a list of disabled plugins client-side for automatically disabling plugin outlets).

As far as I can tell locally and on my instance, it works great. I can deliberately add a broken “import” line to a plugin file, see that the site is broken, go and disable the plugin, and then the site works again :tada:

Is this the right approach to be taking?

https://github.com/discourse/discourse/pull/5103

If one disables a plugin is there a way to force it to load so that it can be enebled?

The option to enable it is still available in the admin interface - that doesn’t need any JavaScript :slight_smile: