# Plugin admin section

**URL:** https://meta.discourse.org/t/plugin-admin-section/14514
**Category:** Feature
**Tags:** rfc, spec
**Created:** [April 7, 2014, 1:20am UTC](https://meta.discourse.org/t/plugin-admin-section/14514 "2014-04-07T01:20:29Z")
**Posts on this page:** 12
**Page:** 1

<div class="post-metadata">

### Author: ![sam](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/sam/32/102149_2.png) [@sam](https://meta.discourse.org/u/sam)
#### Post date: [April 7, 2014, 1:20am UTC](https://meta.discourse.org/t/plugin-admin-section/14514/1 "2014-04-07T01:20:30Z")

</div>

## Problem

At the moment, short of using discourse docker plugin there is no place to list the current plugins, install plugins or disable plugins in the admin UI.

It makes diagnosing issues sometimes tricky, staying up to date with plugins and so on.

## Version 0

Version 0 of the admin plugin UI will be **VERY** simple.

1. Add an extra tab to the admin screen that lists plugins
2. Allow plugins to be enabled or disabled from the UI
3. If a plugin is disabled/enabled a restart of Discourse is required. This should be tracked, eg: display “Your plugin was disabled but will not be deactivated till you restart Discourse”
4. A table needs to be added to track enable / disable state for plugins, by default anything missing from the table is enabled.
5. UI should display which plugins are out-of-date (same way as discourse docker manager does it)
6. Disable / Enable option to be suppressed for any multisite installs. (probably via a GlobalSetting)

Version 0 will not cover

1. Upgrade logic for plugins via UI
2. Installation of new plugins or plugin discovery.

* * *

Since this involves UI, **no work to be completed prior to UI mocks**

* * *

Long term I envisage this deprecating [GitHub - discourse/docker\_manager: Plugin for use with discourse docker image · GitHub](https://github.com/discourse/docker_manager) , instead what docker manager will do is simply implement various hooks like “this is how you restart discourse hook” or “this is how you install a plugin hook”. Cross machine restarts get tricky, installation in Docker environment is tricky.

---

<div class="post-metadata">

### Author: ![lightyear](https://avatars.discourse-cdn.com/v4/letter/l/848f3c/32.png) [@lightyear](https://meta.discourse.org/u/lightyear)
#### Post date: [May 5, 2014, 5:58pm UTC](https://meta.discourse.org/t/plugin-admin-section/14514/2 "2014-05-05T17:58:28Z")

</div>

I’d love to implement this if someone else comes up with the mockups that we can agree on.

(Even would love to work on Version-1 if both installation and upgrade aren’t in this one yet 😉 )

---

<div class="post-metadata">

### Author: ![codinghorror](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/codinghorror/32/110067_2.png) [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [March 3, 2015, 8:43am UTC](https://meta.discourse.org/t/plugin-admin-section/14514/3 "2015-03-03T08:43:59Z")

</div>

This is in place for Discourse 1.2, not sure how many of the above cases it meets though.

---

<div class="post-metadata">

### Author: ![lightyear](https://avatars.discourse-cdn.com/v4/letter/l/848f3c/32.png) [@lightyear](https://meta.discourse.org/u/lightyear)
#### Post date: [March 3, 2015, 1:44pm UTC](https://meta.discourse.org/t/plugin-admin-section/14514/4 "2015-03-03T13:44:07Z")

</div>

> [@codinghorror](#):
>
> This is in place for Discourse 1.2, not sure how many of the above cases it meets though.

From all I see, it only covers:

> [@sam](#):
>
> 1. Add an extra tab to the admin screen that lists plugins

of Version 0. All else are missing. So we have an incomplete Version 0.

---

<div class="post-metadata">

### Author: ![codinghorror](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/codinghorror/32/110067_2.png) [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [March 3, 2015, 8:17pm UTC](https://meta.discourse.org/t/plugin-admin-section/14514/5 "2015-03-03T20:17:18Z")

</div>

Hmm, not quite, version information is also shown.

---

<div class="post-metadata">

### Author: ![codinghorror](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/codinghorror/32/110067_2.png) [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [May 12, 2016, 8:33am UTC](https://meta.discourse.org/t/plugin-admin-section/14514/6 "2016-05-12T08:33:01Z")

</div>

One thing that would be _HUGELY_ useful here is an “enable / disable” button for each plugin.

Considering how many times the answer to a support question is “please disable all third party plugins”. It’s a lot. Like.. _a lot a lot_.

Even a “[safe mode](https://meta.discourse.org/t/53504?silent=true)” where all third-party plugins are disabled would be a massive help.

---

<div class="post-metadata">

### Author: ![sam](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/sam/32/102149_2.png) [@sam](https://meta.discourse.org/u/sam)
#### Post date: [May 12, 2016, 8:57am UTC](https://meta.discourse.org/t/plugin-admin-section/14514/7 "2016-05-12T08:57:14Z")

</div>

The tricky thing is orchestrating the coordinated restart of all the processes

---

<div class="post-metadata">

### Author: ![Tom\_Newsom](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/tom_newsom/32/115981_2.png) [@Tom\_Newsom](https://meta.discourse.org/u/Tom_Newsom)
#### Post date: [May 12, 2016, 9:41am UTC](https://meta.discourse.org/t/plugin-admin-section/14514/8 "2016-05-12T09:41:39Z")

</div>

God yes. Especially when a general update breaks a plugin, it would be great to quickly turn it off rather than break out a command line, edit app.yml and do a rebuild.

---

<div class="post-metadata">

### Author: ![RBoy](https://avatars.discourse-cdn.com/v4/letter/r/2bfe46/32.png) [@RBoy](https://meta.discourse.org/u/RBoy)
#### Post date: [June 14, 2017, 3:46pm UTC](https://meta.discourse.org/t/plugin-admin-section/14514/9 "2017-06-14T15:46:36Z")

</div>

Suggestion: Since there is an #official list of plugins available, why not make an `Install` plugin button which retrieves from the list of official plugins and then automatically updates the app.yml file and triggers a rebuild (like what /admin/upgrade does).

This would achieve 2 things:

1. Simplify the plugin installation (and since it’s from the official list it’s easy to maintain)
2. Build in login to avoid conflicts, if a plugin moves from plugin status to core or something else, essentially official plugins can be handled gracefully and “managed” to avoid upgrade, change of state, deprecation etc situations

---

<div class="post-metadata">

### Author: ![cpradio](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/cpradio/32/4970_2.png) [@cpradio](https://meta.discourse.org/u/cpradio)
#### Post date: [June 14, 2017, 3:50pm UTC](https://meta.discourse.org/t/plugin-admin-section/14514/10 "2017-06-14T15:50:01Z")

</div>

> [@RBoy](#):
>
> why not make an Install plugin button which retrieves from the list of official plugins and then automatically updates the app.yml file and triggers a rebuild

IIRC, the app.yml is outside of the container and thus not directly accessible to Discourse. The Discourse software itself is sandboxed in the docker container and therefore cannot alter the app.yml in any way.

---

<div class="post-metadata">

### Author: ![jimkleiber](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/jimkleiber/32/121814_2.png) [@jimkleiber](https://meta.discourse.org/u/jimkleiber)
#### Post date: [January 7, 2022, 6:41pm UTC](https://meta.discourse.org/t/plugin-admin-section/14514/11 "2022-01-07T18:41:11Z")

</div>

As I noticed the chat plugin isn’t working on my site, I’d love to turn off all plugins that were not the chat plugin to 1) see if that fixes the problem and thus means there’s a plugin clash and 2) if so, then start to one-by-one turn on plugins to figure out which one is causing the problem.

Right now, with [safe mode](https://meta.discourse.org/t/53504?silent=true) I can only turn off all third-party plugins or all plugins, which doesn’t give me the granularity I’d hope.

I can still disable/enable (almost) every plugin from its settings menus, and yet it takes a while, I think it’d just be easier to have a plugin enable/disable checklist also on the [safe mode](https://meta.discourse.org/t/53504?silent=true) page, would make it so much faster.

---

<div class="post-metadata">

### Author: ![chapoi](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/chapoi/32/537252_2.png) [@chapoi](https://meta.discourse.org/u/chapoi)
#### Post date: [December 4, 2025, 11:10am UTC](https://meta.discourse.org/t/plugin-admin-section/14514/12 "2025-12-04T11:10:02Z")

</div>


