Plugin
Plugins extend fylr with custom data types, custom API endpoints, custom frontend snippets and callbacks into fylr's own API calls.
Last updated
Plugins extend fylr with custom data types, custom API endpoints, custom frontend snippets and callbacks into fylr's own API calls.
Plugins extend fylr through a callback system that runs plugin programs in the file-worker tool chain. A plugin is a manifest.yml plus an arbitrary tree of resource files; it can add:
Extensions — custom HTTP API endpoints under the plugin's base URL.
Callbacks — hooks fylr runs during its own API calls (db pre-save, transitions, collection uploads, export, export transport).
Custom data types — new field types.
Frontend snippets — JavaScript / CSS loaded into the web frontend.
Base-config additions — extra configuration parameters (for example a plugin user).
fylr must be told to load a plugin in fylr.yml — either an individual plugin or a directory of plugins. Plugins may be packed into a .zip file; fylr serves the resources from within the ZIP, unpacking files on the fly.
A plugin program is run by the execserver: fylr streams the program its input on STDIN, passes the context as the %info.json% argument, and reads the result from STDOUT. The exec map in the manifest wires this up, and is the same for extensions and callbacks.
Because callbacks run server-side, they can call back into the fylr API using short-lived tokens fylr hands them.
manifest.yml — the plugin descriptor: keys, the exec map, URL replacements.
Extensions — add custom API endpoints.
Callbacks — hook into db saves, transitions, collection uploads and export.
Custom Data — add custom data types.
Plugin Conventions and Standards — build, naming, localization.
Packaging and Release — the ZIP structure and GitHub release workflow.
Administrators install and enable plugins in the Plugin Manager; the /api/v1/plugin endpoint manages them over the API.
Last updated