golem15/summercms
4
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat(cabana): plugin updates and marketplace search on the Plugins screen

Browse Source 
- GET /plugins looks up each versioned plugin's releases through
  kiosk.Client and applies plugin:update's rule (NewestCompatible above
  the BaseVersion), with the update command and the framework a newer
  release needs
- GET /plugins/marketplace forwards q and category (validated like the
  registry), marks installed and incompatible plugins and returns the
  install command; ids outside the plugin ID shape are dropped
- 4 s per-call timeout, at most 4 lookups at once, in-process cache
  (searches 5 min, releases 15 min, failures 1 min); a failing registry
  gives status unavailable, an empty plugins.registry_url sends nothing
- SPA: update badges and Marketplace tab with copy buttons (clipboard
  fallback), hidden when the registry is disabled; no install button
- OpenAPI, SPA types, inventories, conformance case, en/pl strings, docs
This commit is contained in:
Jakub Zych
2026-10-29 19:20:14 +01:00
parent c4b1ac4076
commit 7e8a19399d
18 changed files with 1624 additions and 79 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
docs/plugins/marketplace.md
View File

@@ -182,7 +182,13 @@ Every registry call goes through `kiosk.Client`, which uses `fetchguard` with a
## Admin Plugins screen
The admin's Settings → System → Plugins screen shows administrators holding `backend.view_plugins` (`cabana.PermissionViewPlugins`) what the application was built with. Its Installed tab reads `party.Installed` through `GET <prefix>/api/v1/plugins` (`cabana.PluginsOverview`) and lists every plugin with its name, description, version and source. An application built before this metadata existed lists only the plugin IDs. The screen changes nothing: plugins are installed and updated with the commands above, followed by `summer build`. With `plugins.registry_url` set to an empty value the screen reports the registry as disabled. See [Admin SPA](../backend/admin-spa.md#plugins-screen).
The admin's Settings → System → Plugins screen shows administrators holding `backend.view_plugins` (`cabana.PermissionViewPlugins`) what the application was built with and what the registry offers. The screen changes nothing: plugins are installed and updated with the commands above, followed by `summer build` and a deploy of the new binary, and the screen shows those commands with a copy button. See [Admin SPA](../backend/admin-spa.md#plugins-screen).
The Installed tab reads `party.Installed` through `GET <prefix>/api/v1/plugins` (`cabana.PluginsOverview`) and lists every plugin with its name, description, version and source. An application built before this metadata existed lists only the plugin IDs. For each plugin with a version the server asks the registry for its releases and applies the rule `summer plugin:update` uses: the newest release whose framework minimum the built framework version satisfies (`kiosk.NewestCompatible`) is an update when it is newer than the installed version, and a submodule version such as `v0.1.1-3-gabc1234` compares by its base tag (`kiosk.BaseVersion`). Such a plugin gets an update badge and the command `summer plugin:update <id>`. A newer release that needs a newer framework is named with the framework version it needs. A plugin the registry does not list, and a plugin that is part of the application (no version), gets no badge.
The Marketplace tab searches the registry through `GET <prefix>/api/v1/plugins/marketplace?q=&category=` (`cabana.MarketplaceResponse`): the search text (at most 100 characters) and the category are passed on to the registry. Each result shows its name, description, newest version and icon, a marker when the application already has the plugin or when the built framework is too old for its newest release, and the command `summer plugin:install <id>` with a copy button. There is no install button.
The SPA never calls the registry: cabana does, through `kiosk.Client`, with a 4 second timeout per call, at most four version lookups at a time, and an in-process cache (searches for 5 minutes, a plugin's releases for 15 minutes, failures for 1 minute). When the registry does not answer in time or answers with an error, the Installed tab still lists every plugin, without update information, under a notice that the registry is unavailable, and the Marketplace tab shows the same notice. With `plugins.registry_url` set to an empty value no request leaves the process, the Marketplace tab and the update badges are hidden, and the Installed tab works as before.
## Registry API v1