Statamic Insights Laravel Package

Getting Started

This release is a minor compatibility/UX change for the addon’s Control Panel settings navigation. There are no migrations and no new config keys, so the first step is simply to update the package and verify where its settings appear in the CP.

Minimal steps:

• Update the addon via Composer.
• Confirm the installed statamic-brand-context version if you use it.
• Clear caches as usual after a Composer update.
• Open the Control Panel and inspect the addon’s settings entry.
• With statamic-brand-context 1.16+, the addon’s settings should appear as the sub-item “Einstellungen” under its own CP navigation entry.
• With older brand-context versions, the method is ignored and the previous settings layout remains.

First use case: after upgrading, check whether the addon’s settings are now nested under its own navigation item as expected. If the addon has no CP navigation of its own, confirm that its settings appear via the shared “Addon-Suite” page under Settings.

Implementation Patterns

• Treat settingsNavParent() as a small integration contract between the addon and statamic-brand-context.
• The method should return [section, name] matching the addon’s existing Control Panel navigation entry.
• Keep the returned section/name aligned with the actual CP nav registration. If the navigation label or section is renamed, update both places together.
• Only declare settingsNavParent() when the addon actually has its own CP navigation entry. Addons without their own navigation should rely on the shared “Addon-Suite” settings page.
• No new config key needs publishing. Deployment is a normal Composer update plus cache clear.
• For projects supporting both older and newer brand-context versions, keep tests/documentation version-aware: older versions intentionally ignore the method, so the new sub-item placement is not guaranteed there.
• If you wrap or extend the addon, avoid duplicating the nav section/name in multiple places; derive both the CP nav registration and settingsNavParent() from the same source where practical.

Example shape, mirroring the addon’s own nav entry:

public function settingsNavParent(): array
{
    return ['my-addon', 'My Addon'];
}

Use the actual section and display name registered by the addon’s CP navigation.

Gotchas and Tips

• The return value is positional: [section, name]. Returning the wrong order or a non-matching nav entry can leave settings in an unexpected location.
• Older statamic-brand-context versions ignore the method by design. Do not treat the new “Einstellungen” sub-item as a hard requirement unless you constrain brand-context to 1.16+.
• If the addon has no CP navigation entry, do not add settingsNavParent() just to force placement; the shared “Addon-Suite” page is the intended fallback.
• Clear CP/navigation caches after upgrading if the settings entry does not move immediately. Also verify the current user has permission to see the relevant CP navigation and settings pages.
• There are no database or config migration steps, so deployment risk is low. The main verification is visual/CP navigation behavior.
• When debugging, compare three things: the addon’s registered CP nav section/name, the value returned by settingsNavParent(), and the installed statamic-brand-context version.
• Extension point: addon authors can override settingsNavParent() per addon to control where settings are nested, while relying on brand-context for the actual CP layout.