Homepage    |    GitHub    |    API    |    FAQ

Important: plugins that use deprecated APIs will no longer work

This is an important announcement for all plugin developers (and pre-release users) - from the next pre-release (v2.2.4), all deprecated plugin calls are converted to errors. It means that any plugin still using such API will no longer work.

Most deprecation notices have been around for about six months and have been printing warnings in the console since then, so most should be fixed by now. However if you notice any plugin no longer working please let me know and notify the plugin developer too.

One plugin I've noticed is the "Outline" one, which still uses the old registerSetting API.

The reason for turning old deprecation notices into errors is that new developers might copy and paste code from deprecated plugins, thus potentially making deprecated code more and more widespread, and making it harder to remove that old code later on. Some of that old code causes crashes and issues that are hard to debug so it should be removed.

FAQ

How to check if my plugin uses a deprecated API?

Simply run the plugin while the console is open. In there search for "deprecation notice" or "no longer supported" and that should list the deprecation issues along with instructions on how to fix them.

What if the plugin developer is no longer around?

In that case someone else will have to fork and publish again the plugin (provided it's open source). There's no easy way around this unfortunately. All these deprecation notices happened while the plugin system was still actively under development so if a plugin was built at that time and didn't fix the deprecation issues there's not much to do other than forking.

2 Likes

In fact it looks like there are still a few that use the registerSetting API:

https://github.com/search?p=1&q=joplin+registerSetting&type=Code

Fixing it should be easy, it just means converting this:

await joplin.settings.registerSetting('mySetting1', { ... });
await joplin.settings.registerSetting('mySetting2', { ... });

To this:

await joplin.settings.registerSettings({
	'mySetting1': { ... },
	'mySetting2': { ... },
});
2 Likes

Would it be useful to have a system in place so that if a plugin is reported + verified as non-functional then it is marked as such somehow on the Plugin repo? i.e. grey it out/hide it/add warning/make it non-searchable in Joplin etc.? Maybe use an issues page on the Plugin Repo?

For sure there are many such improvements we could make, also rating plugins, sorting by number of downloads, etc. but as always it's a matter of finding someone to do it. The solutions I choose in general are based on my ability to actually do it, but they aren't necessarily the best solutions.

2 Likes

For me I think the issue here is that views/stats etc. are a nice QoL update but having an "offical" place for plugins means its contents need to at least be compatible with the currently available version of Joplin, if there are dependencies which have broken its functionality then, in a perfect world, these would be detected at a code level and flagged but for the frequency at which they will appear I think a community approach works just fine.

I just had a play with the new pre-release version and the outline plugin, it still allows you to install the plugin just fine. Is it at least worth adding a dismissable banner warning users that they have an incompatible plugin loaded and flag it up as such on the plugin settings page? This wouldn't stop you downloading and installing it but at least on a first attempt to run it will warn the user.

The plan has always been to not have any plugin API breaking changes so none of what you're discussing is worth implementing.

The deprecated methods in this case are exceptional because the plugin system was still in development and unstable, but the API is stable now and there should no longer be any breaking change (not breaking plugins is a top priority). My plan in the future is that any unstable API is marked as such and opt-in only.

That makes perfect sense then, if the API won't change then yeah, there shouldn't be any broken plugins.

I can't update the plugin plugin itself from the app.
image

running JoplinPortable from a USB stick on Windows 10

Hi, I have the same error message/bug for every plugin update. But I use a non supported method = JUNCTION on Windows (= the GNU/Linux symbolic link equivalent) to set my home folder on a trucrypt file. My solution, for earch plugin update, is:
1/ copy each xxxxxx_joplin.xxx.jpl file from tmp to the upper directory ("JoplinProfile" here)
2/ quit Joplin
3/ remove the xxxx preceding the _ for each plugin file present in the "JoplineProfile" directory
4/ copy each of these plugin files in the plugin directory
5/ re-launch Joplin
And that way it works.
Best,
Bruno
PS : here is a link to my issue I closed because I thought it was related to my unsupported config Can't update plugins on windows with Joplin 1.7.10 / 1.7.11 · Issue #4533 · laurent22/joplin · GitHub

1 Like

Any news about the "Convert Text To New Note" plugin? I used it several times a day, it's essencial for a Zettelkasten-like usage. It's been really upsetting making all that work manually. I guess it should be a core feature in Joplin, not an external plugin that can be broke or disappear anytime...

2 Likes

@ambrt, it looks like several of your plugins are quite popular. Do you plan to release a new version at some point?

As mentioned here the fix is relatively simple.

2 Likes

I agree that the "Convert Text to New Note" plugin is/was tremendously useful.

1 Like

The dev (ambrt) might be on vacation...

I noticed ambrt hasn't been active in the forum since April. Since they have a few plugins, would it be possible for Joplin itself to fork those until / if they return? Especially in this case since it looks like someone else has already created the necessary pull request. Maybe the plugins would be put in a "Legacy" or "Unmaintained" state to indicate they are end of life. Might not be the best approach, maybe it requires someone more actively taking it over to be useful. Just thinking of the easiest way for them to be "recovered" by the original author if they come back.

3 Likes

Regarding the legacy/EOLstate, I asked something similar earlier on in this thread but the response was that 1) it requires somebody to manually maintain it and 2) there are no plans to introduce any further breaking changes to the API that would cause a plugin to stop working entirely.
Would a "last updated" section in the plugin window/box/doohickey make sense instead? Rather than having to actively mark it, it becomes unofficially unmaintained just by virtue of it being an old date that the user can judge for themselves.

If the license allows, anyone can fork the plugin and release a new one under a new package and plugin ID. The plugin ID would have to be different otherwise it will be rejected by the repo script for security reasons.

For the unmaintained ones, we have an obsoletes list for that purpose so we'll move them to it.

And in the future we'll indeed try hard not to break any plugin, as I don't want this to be like Firefox or Thunderbird. I wrongly thought that not many plugins were using these deprecated APIs but quite a few did unfortunately.

1 Like

Already implemented the fix and did a PR. Let's hope the dev is able to merge it.

1 Like