Deprecating pre-installed template feature

I am Nishant Mittal. And I'll be working on re-implementing the template features as a plugin. (Template Plugin). And after the plugin is complete we plan to remove the functionality from the original application.

One of the main things we are worried about here is that it would be weird for the people who use this feature currently and when they update the app, the template feature would suddenly vanish. So, far I've not come up with an elegant way to deal with this.

Looking forward to the ideas from the community?

1 Like

I had an idea about recovering the templates after they install the plugin. I can add an option in the menu like "Recover templates" and that would take the templates from the directory and create notes for them in a new notebook "Templates" as we are planning to use it for storing templates in the new plugin.


Having a period to transition where both versions are active before removing the old version would be sufficient to allow for users to get familiar with the new version. Some way to notify users that use templates would be nice as well but might not be worth the effort depending on how many people use the feature. Maybe some warning text/popup when you create note from template during this transition period?

I personally wouldn't want to see the old templates just disappear and a new method appear on updating Joplin without warning and no transition period.

1 Like

We wouldn't have both versions at the same time since the idea is to replace one with the other, and we want the new version to be identical to the previous one, but with maybe some extra features.

So because of that it should be possible to make the transition relatively easy, making it unnecessary to have two versions.

1 Like

Hmm, but why have a menu item for this? Why not run it automatically?

I guess the ideal scenario would be this:

  • The user starts the app, and the template feature works like before without having to do anything.

If it's not possible to do exactly this, we should try to get as close as possible to it. And if there are manual steps, we need to decide how to inform the user about it. They shouldn't discover that the feature is gone and have to look in forums and GitHub issues to find out how to restore it.


You can release one version that detects if the user had templates and, if he did, installs the plugin and migrates them.


If it’s a plugin, it shouldn’t be by default in Joplin.

First step: notify the user about the switch to a plugin, and offer an easy way to install it.

Then, in the plugin, detect wether it's running in a version of Joplin that provides templates itself, and simply do nothing on that. At the same time, remind the user to upgrade Joplin.

Also, while Joplin could do the template handling itself, if it detects the plugin, it should no-op that bit and leave it to the plugin.

So in other words, a grace period, where functionality in the core and in a plugin can coexist somewhat peacefully.

I'm assuming that plugins can see the Joplin version and that they can effectively no-op. Otherwise, it's a bit harder...

1 Like

@nishantwrp, what's your plan regarding this issue? How do you plan to manage the transition?

There are good ideas in this thread, so I'd suggest you write down a small spec about it where you describe the problem, and propose one or two possible solutions.


So after some discussion here's how I've thought to tackle the transition.

  • Plugin will not work on versions of Joplin having template feature. This way we don't have to worry about both features working together.
  • When people upgrade to a version that will not have the template feature in built. A pop-up will be displayed to the users who have templates in their templates directory that the template feature has been moved to a separate plugin.
  • The plugin when installed will check for any templates in the legacy template directory and move them to the templates notebook and rename the templates directory to templates.old.

Please feel free to add some suggestions.


In the message, you could also add a link to the plugin screen in Joplin, from which they can search and install the plugin. The message banner you'll use for this supports that kind of extra link.


Oh ok. That's cool I'll try to add a PR for the banner to the same dev_no_template branch.