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

docs: capture exploration — plugin marketplace (note, research question, Phase 34)

Browse Source
This commit is contained in:
Jakub Zych
2026-10-29 11:51:12 +01:00
parent b651a67356
commit 4449066fa6
4 changed files with 70 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

44
.planning/notes/2026-10-29-plugin-marketplace.md Normal file
View File

@@ -0,0 +1,44 @@
# Decision: Plugin marketplace on summercms.io and `summer plugin:install`
**Date:** 2026-10-29
**Status:** Accepted (exploration)
**Context:** `/msd-explore` session on summercms.io/marketplace, modelled on octobercms.com/marketplace
## Scope of v1
- The marketplace lists the public Golem15 plugins (`sm-*-plugin` repos that stay public). No paid plugins and no developer registration: Golem15 publishes every listing.
- Its job is browsing plugins and getting the install command, nothing more.
## Decisions
### Listing data: facts in the repo, presentation on summercms.io
- Each plugin repo carries a `plugin.yaml` manifest next to `plugin.go`: plugin ID, module path, name, description, required framework version, required plugins. The README and git tags (`vX.Y.Z`) complete the facts.
- summercms.io ingests the manifest, README and tags when a plugin is tagged. The hook is the existing `scripts/changelog-post.py publish … --repo ../sm-<name>-plugin` step or a webhook.
- Presentation fields (category, featured flag, screenshots, icon, sort order) are edited in the summercms.io admin, in the `golem15.summercms` site plugin.
- Reason: install-critical data (module path, versions, requirements) cannot drift from the repo, while marketing details change without a plugin release. A repo manifest also leaves room for third-party submissions later (submit a repo URL).
### `summer plugin:install`
The form of the argument decides where the plugin comes from:
| Argument | Lookup | Default install mode | Override |
|----------|--------|----------------------|----------|
| Plugin ID, e.g. `golem15.journal` | summercms.io registry API: module path, versions, requirements | Go module (`require` in `go.mod`, `go mod download`) | `--source`: git submodule checkout at `plugins/<vendor>/<name>`, as `plugin:add` does today |
| Git URL, e.g. `git@github.com:acme/sm-servers-plugin.git` | None. summercms.io is never contacted. ID and requirements come from the repo's `plugin.yaml`, module path from its `go.mod` | Git submodule checkout, which reuses the SSH access the user already has | `--module` (see the open research question on private modules) |
- Git URLs cover closed or private plugins from repositories the user has access to.
- Both modes end with the same registration that `plugin:add` does (`summer.yaml`, `go.mod`, `go.work` where applicable), then `summer build`.
- Precondition: public plugin repos on git.golem15.com fetch anonymously (HTTPS clone and `?go-get=1` meta). Confirmed as the intent for public plugins on 2026-10-29.
### Admin "Plugins" screen (read-only)
- **Installed** tab: the activated plugins from `backpack.App`, with version and description, and updates available compared against the registry.
- **Marketplace** tab: searches the summercms.io registry and shows `summer plugin:install <id>` with a copy button. There is no install button.
- The running binary never installs plugins. Plugins are compiled in; runtime loading stays rejected (`why-go-not-scala.md`, `.planning/research/FEATURES.md` anti-features). Queued installs and dev-mode live installs were considered and dropped as unnecessary for v1.
## Out of scope for v1
- Paid plugins, licensing, developer accounts and submissions.
- Themes in the marketplace.
- Installing from the admin panel.