# Improving /admin/plugins **URL:** \ **Category:** Feature\ **Created:** [April 4, 2018, 4:23pm UTC](https://meta.discourse.org/t/improving-admin-plugins/84585 "2018-04-04T16:23:27Z")\ **Posts on this page:** 1\ **Showing post:** 1
**Author:** ![Stephen](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/stephen/32/95011_2.png) [@Stephen](https://meta.discourse.org/u/Stephen)\ **Post date:** [April 4, 2018, 4:23pm UTC](https://meta.discourse.org/t/improving-admin-plugins/84585/1 "2018-04-04T16:23:28Z")
So I’ve been helping a couple of communities troubleshoot and tidy up their instances. In both cases some of that housekeeping involved removing broken and/or redundant plugins. It was pretty straightforward for me to do, but that’s only because I’m reasonably in tune with the changes which have occurred over the past 12-18 months, so when I see plugins such as presence I know that it has since been merged into core (although the link from /admin/plugins still refers back to the original empty repo). Are there any plans to restructure the plugins page as a part of the /admin overhaul? It would be great if plugins which are actually part of core (such as discourse-details, discourse-narrative-bot, discourse-nginx-performance-report, discourse-presence, docker manager, lazyYT and poll) were grouped separately, and if a repo which is known to have been merged into the current version is also still in the config maybe chuck up an alert? While I couldn’t find a current example, I can’t discount the possibility that there be cases of plugins which still have a repo whilst also being merged into core so as to support older versions of Discourse. How is that handled by Discourse today? How are less engaged admins meant to identify plugins which become core functionality? --- _[View the full topic](https://meta.discourse.org/t/improving-admin-plugins/84585)._