Stop community plugins from appearing among updates -- two instances of the same plugin installed

Share & showcase
1

Plugins have a way of breaking. Sometimes on one platform or another or all. Murphy’s law.
Either you message the dev at GitHub or if the plugin’s current functionality seems to be nearing its maximum potential and generally you are happy with how it was working before and it just broke on you, there is a simple method to go through.

  1. Quit Obsidian.
  2. Go to the plugin’s GitHub page and from releases, pick the version you’d like to install (obviously the last version which you knew was functioning). Download the files. Chances are the data.json file you’ve had is good enough and it’s not available to download anyway.
  3. Copy the downloaded files (usually 2 or 3; you don’t need the zip) over the existing ones in the plugin folder (in .obsidian>plugins>(obsidian-)plugin_name, you’ll find it).
  4. Open the manifest.json file of the plugin in a text editor and rename the ID of the plugin to anything. Best to rename it to the version number you’ve picked to download. E.g.:
id: obsidian-some-plugin1.1.0,
name: Some Plugin 1.1.0,
  • I did the rename in the second line as well, so I can see within Obsidian that this is a terminated case with me.
  1. In the community-plugins.json file (which holds the list of the currently enabled plugins), rename the plugin to the name with the changed id:
    "obsidian-some-plugin1.1.0".
  2. Open Obsidian. Go back to work.

If future updates of core Obsidian should break the currently functioning version of your plugin again, you’d need to try and install the latest version of the plugin, or if it’s an important plugin with daily updates, you should not bother with hacking things anyway. Otherwise, you can do this cause it doesn’t take long and it’s easy to see among the list of community plugins that one or two are odd ones out and need future attention.

2

One related plugin to this topic: “Plugin Update Tracker” (I’m not sure how much it increases CPU load).

3

Ah, okay. Sounds familiar. Never tried it. My use case involves bad experience having chosen to upgrade.
Plugin doesn’t activate (failed to load plugin), freezes iOS Obsidian or PC install and the like. Usually auxiliary stuff not vital to workflow but still.

4

This method can be used to install two instances of the same plugin as well, brought up here, for instance.

Obviously, there will arise the friction of possible hotkey assignment issues (duplicates need to be deleted) and duplications of context menu items (where there is no way to know which command belongs to which instance but one can memorize it).

I am using this method right now to have different custom dictionaries default to either instance of the Various Complements plugin.
Using a Commander macro to add items to one txt file and the normal shortcut to the other. In the second instance I removed all other (vault or internal link management) functionality.

In my experience, it is better/safer to rename the second instance in a way that doesn’t closely resemble the first plugin’s id name.