Groupings: author-declared plugin suites and mutual works-with links

[davidpesce]

Plugins relate to each other in ways softer than $plugin->dependencies (#20): an author ships a family of plugins designed as a set, or two plugins from different authors genuinely complement each other. The old moodle.org directory expressed this with plugin sets; camp currently has no way to say "these work well together", so admins reassemble that knowledge from forum posts and README links. Unlike dependencies (enforced by core) and disclosure labels (auditable facts about operation), a grouping is an unverifiable claim, so the design question is who may assert one and what keeps the surface honest.

Proposal: two author-declared mechanisms, no registry curation.

1. Suites (same maintainer). A listing.yml gains an optional suite: name. The site renders a suite strip on member pages and a suite index page, but only for plugins that share the suite name AND a verified maintainer. The claim system already proves ownership, so authors can only suite-group their own plugins: self-policing, no endorsement surface, no new governance. Because membership is proven through claimed maintainer identity, suites are Tier 1+ by construction; Tier 0 listings have no verified owner and cannot suite-group. Covers the most common real case (a family shipped as a set) and most of what Navigate to plugins by developer #2 (browse by developer) was after, with more intent behind it.

2. Works-with (cross-author, mutual). A listing.yml gains an optional works-with: list of components, each with an optional one-line reason. A link renders ONLY when both plugins declare each other; one-sided declarations are stored but never displayed. Mutuality is the whole guard: it turns the link into a maintainer handshake, kills the spam and free-riding failure modes (attaching your plugin to a popular one for discovery juice), and CI can verify it mechanically. Reason strings are untrusted listing content and get the usual sanitization. Composer's suggest is the ecosystem precedent for author-declared soft links.

Explicitly out of scope: registry-curated collections and "alternatives". A registry-published recommended stack is an endorsement, and "plugins that do the same job" is a market-share lever; both cut against commerce neutrality and would generate recurring board disputes. Curation is a storefront-layer activity: anyone can build recommended stacks on top of the registry data, per the RFC section 3 model.

Derivation synergy. Hard links already imply groupings without declarations: #20 dependencies and subplugin parent relationships (#16) surface families mechanically. The declared mechanisms only need to carry what those cannot see. If the old directory's plugin-sets data ever becomes available, it could seed suite declarations rather than starting cold.

Mechanics. Both fields live in the listing manifest (author-declared by design), validate against frankenstyle component names, and tolerate references to unlisted components (stored, not rendered; an unlisted works-with target is also a mild seeding signal, same as #20). Suite membership recomputes at publish from claimed maintainer identity, so a maintainer change that breaks the shared-maintainer condition silently drops the strip rather than showing a stale suite.

Open questions. Whether suite: needs a display name separate from the key; whether works-with mutuality should require the same release or tolerate manifest drift between the two sides; cap on works-with list length to keep the surface tidy.

[FMCorz]

I’m in favour of this. The suite concept could also be particularly useful for browsing: a single feature set may be implemented across several plugins, but search results should not be bloated with every satellite component. A frontend could present the suite as a single result while keeping its individual plugins accessible from the suite page.

That said, just grouping by suite may not be enough. If a plugin in a suite can always be considered the parent then the suite could be defined as suite:, and children can refer back to it in-suite-of:. Either requiring shared maintainer, or suite to include all components. This would let the parent provide additional details about the suite without needing a separate registry.

There is one relationship that I don’t think is covered, however. For instance, block_xp works with filter_shortcodes, and some optional features use it. Shortcodes should not need to declare or display a relationship back to XP, as it is a general-purpose plugin that can be used independently. It would also be inappropriate for XP to declare it as a hard dependency, since XP works without it.