Statamic Clientrooms Laravel Package

Getting Started

This release is a small but developer-visible change to how the addon places its Control Panel settings. Start by checking two things:

1. Which statamic-brand-context version you have. Run composer show (or inspect composer.lock) for the package providing brand context. On 1.16+ the addon’s settings appear as the sub-item “Einstellungen” under the addon’s own CP navigation entry. On older versions the previous layout is retained.
2. Where the addon registers settings. Look for settingsNavParent() in the addon’s service provider / addon class. It returns a [section, name] tuple pointing at the addon’s own CP nav entry, which is what brand-context uses to nest the settings page.

First use case: after upgrading, open the Control Panel and confirm the settings page is reachable in the expected place. If you run multiple addons from the same suite, check whether they should each declare their own settingsNavParent() or share the single “Addon-Suite” page under Settings.

No migration and no new config key are required, so upgrading is a composer update plus a visual check of the CP navigation.

Implementation Patterns

Declaring your own settings parent. If the addon owns a CP navigation entry, expose it so settings nest correctly:

public function settingsNavParent(): array
{
    return ['addons', 'my-addon']; // [section, name] of the addon's own nav entry
}

The exact section/name values must match the navigation entry the addon registers; brand-context resolves the tuple to that entry and appends the settings sub-item.

Sharing the suite page. Addons without their own CP navigation should not declare a parent. They fall through to the shared “Addon-Suite” page under Settings, which keeps related addon configuration in one place instead of scattering pages.

Version-aware behaviour. Because older brand-context versions ignore settingsNavParent(), you can ship the method unconditionally and let the host decide. This avoids version_compare branching in your addon and keeps the upgrade path non-breaking. If you need to assert the layout in tests, gate expectations on the brand-context version rather than on your own addon version.

Suite-level integration. When several addons in a suite are installed together, standardise on one of the two patterns: every addon declares its own parent (settings live next to each addon’s nav), or none do (one consolidated Addon-Suite page). Mixing the two produces a split settings experience, so decide per suite and document it.

Gotchas and Tips

• Old brand-context silently ignores the method. No error is raised; settings simply keep the previous layout. If the nesting doesn’t change after upgrading, check the brand-context version first, not the addon.
• The tuple must resolve. [section, name] has to match an existing CP navigation entry. A typo leaves the settings page orphaned or back on the shared page — verify the values against your nav registration.
• No new config or migration means nothing to backfill, but cached navigation can mask the change. Clear the CP/nav caches (and any Statamic caches) after deploying so the new sub-item appears.
• Label is fixed as “Einstellungen” in this layout. If your addon’s settings page has a different intended title, don’t fight the parent nav; the sub-item name comes from brand-context, not from your addon.
• Shared page is not opt-in. Omitting settingsNavParent() is the mechanism for joining “Addon-Suite”. If you later add your own nav entry, remember to declare the parent or your settings will stay on the shared page.
• Extension point to watch: settingsNavParent() is the only hook introduced here. Keep it side-effect free and cheap — it may be called during nav assembly.