[Feature request] Disable/hide metadata plugin

Please describe your suggestion, and the problem it'd solve.

Add a toggle to disable/hide a plugin so it doesn't appear in the "Import tags from plugin" list.

Currently there are 21 options shown in the list, and I think normal users will only use 4 or 5 of them on a regular basis. As there will be more plugins to come, it is important to allow the user to hide plugins, resulting in a much cleaner interface.

Long-term the idea is more to stop bundling all plugins with the core server and to rely on an external repo instead; It's currently not very efficient to have to wait for a new server release to get a bunch of plugin fixes.

Only issue is that requires a bunch of infrastructure work so it hasn't been done yet :^)

Each plugin is a single file I assume (not familiar with Perl), so the easiest way might be to use a GitHub repo to store plugins and download directly from it; you could even put a description file for all plugins in the repo, so no need to bundle plugin info with the server.

Another way could be to add a fixed first option to the "select" menu, with a generic text like "Parse URL...", that when called checks if exists a plugin that can work with the specified URL.

The plugins should expose a method that must be called passing an URL and returns true or false. Also it might be useful to add a new plugin category ("scrapers"?) to easily exclude these plugins from the "select" menu.

Sorry for reviving the old threads, but +1 for this well my use case is, for it's easier to select when editing the meta data (on my case, i only use the latest bottom ones) so add an option to hide the plugins from this select dropdown is super neat feature 👍

i gave some thought to a plugin repo multiple times in the past, but the issue comes with handling updates and making sure the plugins remain downloaded even for setups like docker users who trash the entire container on updates 🤔

the plugin repo would need an index file generated by CI or smth that lists the hosted plugins, their versions and download URLs; Then we could check that against the on-server plugins, which would need to be stored in a directory outside of the server/container filesystem..

i gave some thought to a plugin repo multiple times in the past, but the issue comes with handling updates and making sure the plugins remain downloaded even for setups like docker users who trash the entire container on updates 🤔

the plugin repo would need an index file generated by CI or smth that lists the hosted plugins, their versions and download URLs; Then we could check that against the on-server plugins, which would need to be stored in a directory outside of the server/container filesystem..

i don;t know how perl behaviour (i think it was perl) but can't it be done like disable / hide it from frontend only? so the update handling is still the same as before or in perl, it need to be deleted / removed from the plugins directory for proper disable / hide ?

if it's that way, for docker user, maybe you can make some env for it? and the script is just remove / move the plugins to other directory if the env set to true for example ? as for the normal user, just make some documentation to remove / move the plugins downloaded to other folder

making sure the plugins remain downloaded even for setups like docker users who trash the entire container on updates

I don't think there is much that can be done for docker, once the container is deleted, everything is gone. For current users, if they added/modified any plugin in the current deployment, they will have to manually backup those plugins. After that, the user can simply bind-mount the plugin folder outside of the container.

The script management is probably the easiest part: the script folder can be structured like this:

Plugin/
    |- custom/
    |- Download/
        |- Pixiv.pm
    |- Login/
    |- Metadata/
        |- Pixiv.pm
    |- Scripts/
    |- metadata.json

The custom folder is for the user's personal plugins and will never be checked for updates.

And the metadata.json can be like this:

{
    "version": 1.0,
    "plugins": [
        "Download": [
            {
                "name": "Pixiv",
                "version": "1.0",
                "source": "https://raw.githubusercontent.com/Difegue/LANraragi/refs/heads/dev/lib/LANraragi/Plugin/Download/Pixiv.pm",
                "sha512": "1d88c0e24a69624e7f8bdb6de5b1e3e2777e6fd4c1726c2ca03f2f8d747232a1ee0183486d0bb84be7bc6902aa604837b2a9be0a4c56a28bb682b79fdf743fbd"
            }
        ],
        "Metadata": [
            {
                "name": "Pixiv",
                "version": "0.4",
                "source": "https://raw.githubusercontent.com/Difegue/LANraragi/refs/heads/dev/lib/LANraragi/Plugin/Metadata/Pixiv.pm",
                "sha512": "686a0078730c50f0ee3c911ea403849cf3a62dce6433d226e311e7acca407737054fc7f2779a9b52e829df532e92bc9c5199875fef98ff187aa23a815e4687be"
            }
        ]
    ]
}

Its content can be updated by using Github workflow with

on:
  push:
    paths:
      - 'lib/LANraragi/Plugin/**'

When starting the LRR server:

1. (Check if there is a newer metadata file and) download metadata.json from the repo
2. Check if local plugins are obsolete by using the checksum or version number
   • Check sum: prevert file corrupted or modified, but slower
   • Version number: faster, but there is a risk of the file being broken
3. Show a pop-up in the web UI to notify the user

It sounds like we're basically designing a package manager (apt, pacman, winget, brew) but for plugins for LRR at this point, no?

We could define a plugin registry and protocol, and keep metadata for plugins and plugin registries in the database, completely separating it from the LRR service. Then, have a standard (default) plugin registry (e.g. "difegue/lrr-plugins") provide all the info about existing plugins ("pixiv", "comicinfo", etc. and all their versions/hashes) that are available for download/upgrade. If the user wishes, they may also replace the existing registry with something else. The registry could be local, or remote (on github), and git registries should still support unit testing.

Then on startup LRR would:

1. fetch plugin metadata from redis, then check if they exist on disk,
2. fetch plugin registry from redis, applying a default one if none exist,
3. fetch full plugin metadata from remote plugin registry, and identify outdated plugins or new ones

And LRR's plugins page would just be an interface for the user to add/remove/update/upgrade/downgrade/upload/download plugins, as well as update plugin registries.

Obviously this is quite a bit of work though, but there are no shortage of package managers to draw inspiration from.

I'm not too big a fan for having a metadata.json file be in the repo, hashes and all. This is a permanent file that's only useful once (on initialization), and metadata that does not synchronize with the commits of the plugin source code should stay in the database. We'd also need to anticipate situations where the user {upgrades plugin, doesn't upgrade plugin, cruds plugin} x {upgrades LRR, downgrades LRR, recreates LRR, drops database, etc.}, in terms of how this file should/could be interpreted.

yeah a plugin repo would essentially be a package manager, although a MVP wouldn't really need all the safety checks and could just be some server code that downloads plugins and keep tracks of which version you have installed.

Docker installs would really just need an extra bind mount on the custom plugin folder, which is pretty much what you need to do already if you're uploading plugins manually through the webUI's current (limited) support.

The metadata.json could live on the plugin repo and be updated by GH actions whenever plugins get added/updated to it.