# Smoke-testing plugins during upgrade process

**URL:** <https://meta.discourse.org/t/smoke-testing-plugins-during-upgrade-process/71118>\
**Category:** Feature\
**Created:** [October 1, 2017, 8:18am UTC](https://meta.discourse.org/t/smoke-testing-plugins-during-upgrade-process/71118 "2017-10-01T08:18:48Z")\
**Posts on this page:** 1\
**Showing post:** 4

<div class="post-metadata">

**Author:** ![david](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/david/32/157490_2.png) [@david](https://meta.discourse.org/u/david)\
**Post date:** [October 1, 2017, 8:30am UTC](https://meta.discourse.org/t/smoke-testing-plugins-during-upgrade-process/71118/4 "2017-10-01T08:30:19Z")

</div>

I agree the user experience right now is pretty bad - plugins break regularly, and uninstalling one-by-one is incredibly tedious when using the default install.

> [@codinghorror](#):
>
> We don’t accept responsibility for plugins we didn’t write

I don’t think it’s a case of responsibility, more about making the Discourse product more resilient to change. I don’t think anyone would expect the core team to maintain 3rd party plugins.

I think a good first step towards making things better would be to add some kind of “disable plugin” button to Docker\_manager. Then a future thing could be to make disabling broken plugins automatic based on acceptance tests.

I think it should be possible to implement that so that it only requires restarting the server, rather than rebuilding… but not 100% sure of that

---

_[View the full topic](https://meta.discourse.org/t/smoke-testing-plugins-during-upgrade-process/71118)._