Statamic Booking Laravel Package

Getting Started

This addon plugs into Statamic's Control Panel and leans on statamic-brand-context for its settings placement. The v1.7.0 release is a drop-in upgrade: no migration and no new config keys, so there is nothing to publish or backfill before you start using it.

First steps:

1. composer require the addon (and ensure statamic-brand-context is present — see the version note below).
2. Open the Control Panel and locate the addon's navigation entry. On brand-context 1.16+, the addon's settings appear as the "Einstellungen" sub-item beneath that entry, so configuration lives where you already work rather than in a separate Settings screen.
3. If the addon does not register a navigation of its own, its settings are grouped onto a shared "Addon-Suite" page under Settings. Check there if you can't find the entry.

A good first use case is simply confirming where the settings land in your CP: install, open the addon's nav entry, and verify the Einstellungen sub-item renders. That validates both the addon and your brand-context version in one pass.

Implementation Patterns

Version-aware settings placement. The new settingsNavParent() method returns [section, name] describing the addon's own CP navigation entry. The behaviour is version-gated:

• statamic-brand-context >= 1.16: settings render as the "Einstellungen" sub-item under your nav entry.
• Older brand-context: the method is ignored and the previous layout is retained.

Pin statamic-brand-context to ^1.16 (or higher) in composer.json if you want the nested settings layout to be deterministic across environments.

Keep nav registration and settingsNavParent() in sync. The [section, name] pair should mirror exactly what you register in your nav provider. Mismatches typically surface as settings appearing on the fallback "Addon-Suite" page instead of under your entry.

Addons without their own nav. If your addon doesn't declare navigation, don't fight the shared "Addon-Suite" page — treat it as the intended grouping and use it consistently across your addon family. This is also a sensible pattern for suite-style packages that want one consolidated settings area.

Day-to-day workflow. Settings changes are read through the normal Statamic config/settings pipeline, so the usual patterns apply: resolve settings in your service provider or via the brand-context API, inject them into views/middleware, and avoid caching resolved values across requests unless you're deliberately caching per-brand.

Gotchas and Tips

• Silent fallback on old brand-context. settingsNavParent() is ignored — not errored — on brand-context < 1.16. If a teammate reports "the settings are in the wrong place," check the installed brand-context version before debugging the addon.
• No migration, no config key. v1.7.0 is a clean upgrade. If you see failures after upgrading, they are almost certainly nav/version related, not data related.
• Cache clearing after nav changes. Statamic caches CP navigation; run php please cache:clear (or the equivalent) after changing nav registration or settingsNavParent() so the new sub-item appears.
• Naming drift. Because the method returns a positional [section, name] pair, a renamed nav entry silently breaks the parent link. Add a test or a lint check that asserts the returned pair matches your registered nav.
• Extension point. settingsNavParent() is the intended hook for controlling settings placement — override it in your addon rather than hardcoding routes or custom CP pages if you want to stay compatible with future brand-context releases.