Trilium - Plugin Manager

[ricolandia]

This idea started in #9726

@ecodiv @eliandoran @Nriver

I went ahead and built a working prototype. The repo is at https://github.com/ricolandia/trilium-plugin-manager — a single JS Frontend note that fetches a registry, shows plugin cards, and installs/uninstalls with one click. No server, no CLI, no Docker.

Two install methods:

• sourceUrl (recommended) - points to a .js/.jsx raw file, creates a code note directly. No token needed.
• zipUrl - legacy ZIP fallback for manual import.

That said, this is a community interim solution while the official plugin system is still on the roadmap. What we really need is:

1. An official plugin system built into TriliumNext (like Obsidian, Joplin, Logseq have)
2. A standard format - single .js/.jsx files + a registry entry
3. More community plugins published in that format

@ecodiv's Weekly Planner is the perfect example: a self-contained .jsx that generates its own child notes. No ZIP, no export, no import hassle. The more plugins we publish this way, the easier it is to build momentum toward an official system.

There's a Plugin Developer Guide in the repo if anyone wants to publish their plugin. Happy to help shape the standard if there's interest.

Screenshot

[ricolandia]

Everything is working, but I found a new way to create child notes. I am trying it...

Problem
Today, a plugin with multiple components (e.g., Shared Notes = Widget + Handler + Config) needs to:

• Option A: Embed the sources in the JSX (WIDGET_SOURCE = \...``) — resulting in a huge JSX that is fragile and hard to maintain.
• Option B: Include manual setup logic in each JSX — leading to duplicated code across plugins.

Proposed solution: JSON Manifest
The registry gets a manifestUrl field:

{
  "id": "shared-notes",
  "manifestUrl": "https://raw.githubusercontent.com/.../manifest.json",
  "sourceUrl": "https://raw.githubusercontent.com/.../shared-notes.jsx"
}

[ricolandia]

Plugin Manager update: now with multi-note support via manifest.json"

A quick update on the Plugin Manager — it now supports plugins with multiple notes through a manifest.json file.

What changed

Until now, the Plugin Manager could only install single-file plugins (a .js or .jsx downloaded as one code note). Many plugins need more than that: a render note + a widget + a config note + a backend handler. The manifest system solves this.

How it works

A plugin's registry entry can now point to a manifestUrl instead of (or in addition to) a sourceUrl:

{
  "id": "shared-notes",
  "manifestUrl": "https://raw.githubusercontent.com/user/repo/main/Shared-Notes/manifest.json"
}

The manifest describes every note the plugin needs:

{
  "notes": [
    {
      "title": "Shared Notes",
      "type": "text",
      "content": "Open this note to use the plugin."
    },
    {
      "title": "Widget",
      "type": "code",
      "mime": "application/javascript;env=frontend",
      "sourceUrl": "widget.js"
    },
    {
      "title": "Handler",
      "type": "code",
      "mime": "application/javascript;env=backend",
      "sourceUrl": "handler.js"
    },
    {
      "title": "Config",
      "type": "text",
      "content": "Set your name and endpoint here."
    }
  ],
  "relations": [
    { "type": "renderNote", "from": "Shared Notes", "to": "Widget" }
  ],
  "labels": [
    { "note": "Widget", "name": "widget", "value": "" },
    { "note": "Handler", "name": "customRequestHandler", "value": "shared-notes-reply" },
    { "note": "Config", "name": "sharedNotesConfig", "value": "" }
  ]
}

On install, the Plugin Manager:

1. Downloads the manifest
2. For each note: if it has a sourceUrl, downloads the source (relative to the manifest URL); if it has content, uses it directly
3. Creates all notes via api.createNewNote()
4. Applies labels (including #pluginId, #pluginVersion, #pluginName for tracking)
5. Creates ~renderNote and other relations

No ZIP, no ETAPI, no token, no deadlock. All notes are created in one backend transaction.

Three install methods now

Method	Use case	Token?
sourceUrl	Single .js/.jsx file	❌
manifestUrl	Multiple notes with labels/relations	❌
zipUrl	Legacy Trilium export ZIP	✅ (manual import)

Current plugins already using manifests

The official registry now has 4 multi-note plugins using this system:

• AI Chat — render note + JS code + config
• Attribute Garbage Collector — render note + JS code
• Knowledge Debt Dashboard — render note + JS code
• Shared Notes — render note + widget + handler + config

For plugin developers

If your plugin needs more than one note, create a manifest.json in your plugin folder, host the sources as raw files, and point manifestUrl to the manifest. The Plugin Developer Guide covers the full format.

Repo: https://github.com/ricolandia/trilium-plugin-manager

Feedback and plugin submissions welcome!

[ricolandia]

Maybe it's MVP solution for the maintainers:

The plugin format is now simple enough that it could be officially curated without much overhead. The idea:

1. Adopt the format as a community standard — a single .js/.jsx file or a manifest.json pointing to raw files on GitHub. No build tools, no packaging, no server.

2. GitHub as the registry — all plugins live in a single repo (or a curated list). Each plugin is just a folder with its source files:

   plugins/
   ├── weekly-planner/
   │   ├── planner.jsx
   │   └── manifest.json
   ├── ai-chat/
   │   ├── AI Code.js
   │   ├── manifest.json
   └── ...
   

   Raw GitHub URLs serve as both the source and the manifest — no hosting needed.

3. TriliumNext ships with a built-in registry URL — the Plugin Manager (or an official version of it) comes pre-configured pointing to the curated repo. Users don't need to set up anything. Just open the plugin manager and browse.

4. Maintainers curate what works — a PR-based workflow: developers submit their plugin as a PR to the curated repo. Maintainers review, test, and merge. Once merged, the plugin appears in every TriliumNext instance automatically.

This is exactly how Joplin, Logseq, and Obsidian handle community plugins — and it works. The difference is that our format is simpler: no npm packages, no build step, no CLI. Just raw files served from GitHub.

The Plugin Manager I built is a proof of concept. If the project adopts the standard, I'll happily adapt it to whatever the official implementation looks like — or donate( I can delete it from my repository ) the code if that's easier.

What matters is having one place where users can discover and install plugins without configuring URLs, tokens, or anything else.

[ricolandia]

✨ Manifest Generator

To make it dead simple for anyone to create a multi-note plugin, I put together a manifest generator prompt:

📄 https://github.com/ricolandia/trilium-plugin-manager/blob/main/MANIFEST_GENERATOR.md

How it works:

1. The developer fills out a few sections in the prompt: plugin name, URLs, note titles, labels, relations
2. Pastes it into any AI chat (Claude, ChatGPT, etc.)
3. Gets a ready-to-use manifest.json back
4. Saves the manifest + source files in their repository (GitHub raw URLs)
5. Submits the registry entry — done

No need to learn the JSON format by heart. Just describe what notes the plugin needs, and the generator handles the rest.

The same prompt also works as a manual checklist for validation (raw URLs, encoding, label formatting, etc.).