Plugins & themes: Make it clear when plugin/theme is listed in the official directory or not (manually installed, removed for inactivity)

[CawlinTeffid]

Use case or problem

When a plugin or theme is removed from the community repo, the user isn’t notified. Instead they’re allowed to continue unknowingly using a thing that isn’t maintained.

For example, I only found out that Customizable Sidebar had been merged into Commander when I opened its description page to get the link for someone and the page was missing with no explanation. I had to search the web to figure out what had happened, and it was an annoying hassle.

More recently, someone in Discord mentioned that a plugin I have installed (but turned off a while back because of bugs) had been deprecated.

These aren’t how I should find out — Obsidian should tell me.

When themes are removed they still retain a placeholder entry (I’m not sure that’s intentional), but it’s uninformative: Plugins & themes: Make it clear when plugin/theme is listed in the official directory or not (manually installed, removed for inactivity) - #24 by jhgfd.

Proposed solution

Minimally: when checking for updates, also check for installed plugins/themes that have been removed from the community repository. Notify if any are found.

Ideally: Provide a way for developers who remove their plugins/themes to leave a message, and for Obsidian’s devs to do the same if they remove one.

It would also be good to have a standard way for the developer to notify the user that a plugin/theme which hasn’t been removed is no longer maintained. (Plugins & themes: Make it clear when plugin/theme is listed in the official directory or not (manually installed, removed for inactivity) - #8 by CawlinTeffid)

A pop-up notification would be useful to catch the user’s notice, and something more permanent like a banner should be added to the item’s entry in the list of installed items. Possibly a tombstone entry in the community repo could be shown to users who have the removed plugin installed, since people sometimes search there instead of in their list of installed ones (themes sort of have a tombstone already but it’s blank).

Current workaround (optional)

I just find out by happenstance, but I suppose you could manually check the description page of every installed plugin every so often to see if it still exists.

Potential future workaround: Use only to notify about potentially abandoned packages · Issue #70 · swar8080/obsidian-plugin-update-tracker · GitHub

Related feature requests

Automatic plugin updates

Use case or problem I would like to know that my Obsidian use the newest version of all installed plugins. Proposed solution Add option to turn on auto update plugins (like obsidian auto update feature) Current workaround (optional) Go to settings and click for Community plugins → Check for updates → Update All Related feature requests (optional) i don’t find

Notification about plugin updates

Use case or problem I would like to know when there are plugin updates available so that I know I can update them when I have time (I guess some updates might break things). I use Intellij (IDE) and it behaves similarly - doesn’t update plugins automatically but informs about updates and it let users decide. Proposed solution Maybe info in status bar with number of plugin updates. Current workaround Manually checking from time to time if there are updates.

Notify the user when an installed plugin is obsolete/not maintained

Use case or problem Some plugins might not be maintained for a long time, and therefore they are more prone to break or to cause problems, potentially even without the user noticing before it is too late to fix them. Proposed solution It would be super useful and a life-saver to notify the user (upon opening Obsidian) when within their installed plugins there are some which have not been updated in a long time (let’s say one year). Current workaround (optional) Manually check when installed pl…

Related discussion

Curating out-of-date plugins

Following on from this thread about out-of-date plugins: How are community plugins currently curated? Would it be possible to ask developers to provide a compatibility statement—similar to WordPress plugins—confirming that the latest version of their plugin has been tested to work with XX version of Obsidian? Would it be prudent to remove plugins from the directory if they aren’t updated for XX months? The old plugins would still be available on GitHub for anyone who wants them, but dec…

Changes

(Examples of users encountering the problem are added in comments as I find them.)

• 2025-06-06: Expanded to include themes.
• 2025-05-19: Added detail about how the plugin’s status might be communicated.
• 2025-04-01:
  • Added related FR from Plugin Ideas.
  • Added potential future workaround.
• 2024-06-24: Added mention of plugins that haven’t been removed but which have the dev has indicated aren’t maintained.
• 2023-03-02: Added “and for Obsidian’s devs to do the same if they remove a plugin.”

[CawlinTeffid]

Nearly a year later, still seeing users with Advanced Mobile Toolbar installed who don’t know it became part of Commander and isn’t maintained: Discord

[ichmoimeyo]

My workaround is to monitor …

Commits · obsidianmd/obsidian-releases

via RSS

 

EDIT: … and if desired, create a filter to only show posts that have in the title:
“archived” OR “remove”
or->
“removed” OR “remove”
or->

/remov/i (regex)

[LBF38]

What about using the plugin’s manifest.json to help this usecase ?
It could be a simple flag similar to isDesktopOnly or a more structured object.
For reference: Manifest - Developer Documentation

Moreover, the manifest.json can have an associated official JSON schema to provide better context to developers.
For reference on this topic: JSON Schema - Creating your first schema

Hope it helps !

[CawlinTeffid]

Advanced Mobile Toolbar has apparently finally broken and left a user wondering about replacements because they weren’t notified of its removal and incorporation into Commander.

[CawlinTeffid]

…And another Advanced Mobile Toolbar user: Discord

[CawlinTeffid]

“I saw the notice that users should switch to Metabind only when I was grabbing the link to Buttons’ github repo” — Discord

[CawlinTeffid]

Dataloom is still in the plugin store, but its last update 2 months ago added a message to the description saying it is no longer maintained and that users should migrate to something else. This user only found out today:

Hey folks, just wanted to mention how outdated I’ve been in the plugins thingie cause I found out I’ve been using a deprecated plugin 2 months after it was killed (Discord)

This is a different case from that described in the feature request, but related, and for the end user very similar. A standard way to notify the user of this would be good.

[CawlinTeffid]

A user tried to install a plugin they use in one vault in a new vault but wasn’t able to find it in the community store because it’s not there anymore.

I just realized that the plugin I am using for “Calendar View” is 3 years old and is no longer in the community store. searching for another Calendar View plugin dont’ bring me what I want . It is very bizzare. (Discord)

I wanted to install it on one of my new vaults and I was forced to copy paste the folder manually. … I was wondering I am searching for a wrong keyword or something. (Discord)

[CawlinTeffid]

Here are 11 people in 2 GitHub issues confused by the disappearance of a plugin from community plugins:

• Hi Am Gloria Am not sure if this is how to request for this plugin but I can't find it in obsidian community of plugins? Please avail it somewhere or direct me? I have some books I'd like to convert to markdothat obsidian can use? · Issue #19 · akaalias/obsidian-extract-pdf · GitHub
• Plugin not found in Community Plugins Tab · Issue #21 · akaalias/obsidian-extract-pdf · GitHub

It looks like the plugin was removed over 2 years ago but is still receiving comments this year wondering what’s up.

(Hat-tip to @ roygbiv_. / SyrusSouls whose curiousity about the plugin and its status led me to the issues: Discord)

[Synchronicity]

This is a critical missing feature. Users who unwittingly continue to use removed plugins could potentially incur data loss/corruption. Immediate In-app notification is particularly important when plugins have been removed because of security issues.

[joethei]

That mechanism exists already, we can blacklist plugins, or specific plugin versions, which will automatically be disabled on all user devices.
It hasn’t been used that often so far, see the list here: obsidian-releases/community-plugin-deprecation.json at master · obsidianmd/obsidian-releases · GitHub

If we are aware of data loss or security issues we disable plugins, but most of the time a plugin is just outdated, and does not work, without data loss, that’s what this FR is about.

[Dale]

Use case or problem

Currently when you turn on community plugins you get a warning about the risks and the mitigations that come with the plugin directory. However, there’s no distinction between risks for official plugins and risks for unofficial plugins.

This therefore has the effect of implying that any plugin installed after that point has the same level of risk. But this isn’t true. Installing a plugin through BRAT or by manually unzipping a download holds far greater risk because policy and review only applies to those officially submitted to the directory.

Proposed solution

I think this can be fairly easily improved.

On launch (or periodically), Obsidian could check if there are new plugins installed that are not in the list of those installed through the directory, and it could then give a big extra modal warning that plugins not installed through the directory, even if installed through another plugin, come with even more risks — Such as stealing your data, monitoring your actions, etc.

This delineation (Between managed installs and unmanaged installs) is the security vulnerability the review process is trying to mitigate. But the current messaging doesn’t highlight this, it instead lumps them all together and implies they’re all as de-risked as the official directory.

I believe this kind of improvement will bring a greater awareness to users when they’re installing things that might be a risk to them.

Related

This came from a discussion on Discord regarding telemetry restrictions. Not super relevant but here’s the link if curious.

[Dale]

I think there’s some argument to be made about whether the levels of risk are actually very different between the two. But I would point out that the current warning talks a lot about mitigations that the plugin directory provides — None of which apply to non-directory installed plugins.

So it’s also about making it clear that when installing a plugin manually those aforementioned mitigations no longer apply.

[WhiteNoise]

@Dale

However, there’s no distinction between risks for official plugins and risks for unofficial plugins.

This therefore has the effect of implying that any plugin installed after that point has the same level of risk.

I don’t agree with this logical deduction. I don’t think it’s logical expect that a manually installed plugin has been reviewed. The BRAT plugin itself has its own disclaimers in the readme.

[WhiteNoise]

I renamed this FR to make it broader.

This FR is about making clear to the user (via icon, or notification) whether an installed plugin is NOT part of the official plugin directory. Either because it was manually installed by the user or because it was at some point removed from the official directory due to inactivity.

As explained by Joethei, a mechanism for deactivating a plugin that is causing data-loss is already implemented and is not related to this feature request.

[Dale]

I don’t think it’s logical expect that a manually installed plugin has been reviewed.

I think we agree. That’s what I’m saying.
A manually installed plugin may not have ever been reviewed - or may have even been reviewed and rejected.

Therefore, I believe there should be a reminder on abnormal install of a plugin that plugins not installed through the official directory carry further risk.

A disclaimer in the BRAT readme isn’t enough as that’s likely never read, and BRAT isn’t the only way to manually install.

[WhiteNoise]

No, I don’t think we agree at all.
I think a user that manually installs a plugin understands that said plugin has NOT gone through the review process.
The user is taking intentional actions that go beyond what the official directory offers, so they should understand that whatever they install has not gone through the review process.

[Dale]

Oh, I understand what you’re saying now.

I think a user that manually installs a plugin understands that said plugin has NOT gone through the review process.

I don’t think that’s a very reliable assumption. Certainly many people understand that, but that doesn’t mean all do. Especially new users.

The user is taking intentional actions that go beyond what the official directory offers.

But how do they know that’s what they’re doing?
Being in the Zeitgeist, watching YouTube videos, reading forums, these all create awareness for non-tech-savvy individuals but not for those that don’t research these things.

If you look at the community plugins notice. It doesn’t say that “only things directly accessible from this search box” are community plugins. And in the user flow of installing either type of plugin for the first time (community or URL), you’re still required to turn off restricted mode and read about community plugin safeguards.

To give a slightly related example… I regularly tell friends about the plugins I make and the next thing I usually have to explain is “What is a plugin”…

So when someone in the “community” says to get this functionality you install this URL using the BRAT community plugin". How does a layman know what’s risky and what’s riskier?

(Deleted my previous post cause I felt I could describe it more succinctly)

[rblock]

I support this request because I just had a problem with was difficult to solve because, as I eventually found out, that the culprit was a plugin that wasn’t listed anymore.

But annoyingly, I wouldn’t know because when I selected Browse in the Community Plugins section of the settings dialog, it wasn’t show even as I selected to only show installed plugins.

So, it seems, even if you select there to show only installed plugins, the ones that are no longer available are not shown because is filters the online available plugins and ignores what really is installed.

I only found the culprit because I deactivated one-by-one the plugins in the plugin list until I hit the culprit. That that plugin´, Budget WYSIWYG, was the culprit I knew from another thread over here. But because it wasn’t listed using the Browse plugins dialog, I had hours more to find this plugin.