Skip to content

DOCS: Note that global_addons registration also gates module toggling - #20

Open
HrDelwar wants to merge 1 commit into
mainfrom
docs/global-addons-gates-module-status
Open

DOCS: Note that global_addons registration also gates module toggling#20
HrDelwar wants to merge 1 commit into
mainfrom
docs/global-addons-gates-module-status

Conversation

@HrDelwar

@HrDelwar HrDelwar commented Sep 8, 2026

Copy link
Copy Markdown
Collaborator

Summary

fluentform/global_addons is documented as a display filter — "you can use this
filter show global addons" — and its reference pins it to
AddOnModule::showFluentAddOns().

Both statements stop being true with fluentform/fluentform-dev#1174. The registry
build moves to AddOnModule::getRegisteredAddOns() so the module-status writer can
validate a submitted module_key against the same source the add-ons screen renders
from, which makes registration load-bearing beyond display: a key the filter does
not return is rejected when its status is saved.

Changes

  • Corrects the location reference: showFluentAddOns()getRegisteredAddOns(),
    and names both consumers (the screen and the status writer).
  • Adds a warning block telling add-on authors to register unconditionally, because
    registering conditionally makes the module un-toggleable.

Why the warning matters

A rejected key is never stored, so it cannot self-heal on a later attempt — an add-on
that registers only on admin screens, or only while a dependency is active, would
appear on the Add-on Modules screen (rendered in admin, where it is registered) yet
fail to toggle, permanently, with a generic error.

The documented example already registers unconditionally, and nothing in free or pro
gates its registration, so no shipped add-on is affected. This is written down so
third-party authors do not have to discover it from a support ticket.

Related

  • Plugin PR: fluentform/fluentform-dev#1174 (FF-SEC-46)
  • Merge this with or after the plugin PR — the location reference is only accurate
    once that ships.

The filter's documented location was AddOnModule::showFluentAddOns(). The
registry build moved to getRegisteredAddOns() so the module status writer can
validate a submitted module_key against the same source the add-ons screen
renders from.

That makes registration load-bearing beyond display: a key the filter does not
return is now rejected when its status is saved. Add-on authors need to know
that registering conditionally — only on admin screens, or only while a
dependency is active — makes the module un-toggleable, so the note spells it out
next to the existing example, which already registers unconditionally.
@cloudflare-workers-and-pages

Copy link
Copy Markdown

Deploying fluentform-developers with  Cloudflare Pages  Cloudflare Pages

Latest commit: 484a954
Status: ✅  Deploy successful!
Preview URL: https://a1afb539.fluentform-developers.pages.dev
Branch Preview URL: https://docs-global-addons-gates-mod.fluentform-developers.pages.dev

View logs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant