Gustamic Laravel Package

Getting Started

This is a Statamic starter kit/theme for restaurant sites (menu pages, Restaurant Details, JSON-LD, analytics), verified against Statamic 6.35 / Laravel 13. Treat it as a starting point you fork into a project, not a runtime dependency you build around.

1. Install the package into a fresh Statamic 6 site via Composer, then run the installer. In v1.1.0 sample content installs by default even on non-interactive installs, so a --no-interaction run now gives you a populated site instead of an empty one.
2. Open the Control Panel and go to Restaurant Details. This is the single source of truth for name, address, opening hours, social profile URLs, and analytics IDs. Fill in the social profile URLs first — since v1.1.0 these are what populate JSON-LD sameAs.
3. Open the Menu page in the Pages tree and confirm its slug. Featured-menu and footer links now resolve to this entry rather than a hardcoded /menu, so the slug is yours to change.
4. Run your asset build and load the site. The first use case to exercise end-to-end is: edit a menu item, change the Menu page slug, and confirm the featured menu section and footer links still point at the renamed page.

Where to look first: the README (now includes a live demo link and image credits), the Restaurant Details fieldset, and the Antlers templates for the featured menu, footer, and JSON-LD partial. The demo is the fastest way to see intended layout before you start overriding.

Implementation Patterns

Let the entry drive navigation. Don't reintroduce hardcoded menu URLs in your own templates. Resolve the menu page once ({{ nav:pages }}, a route lookup, or an entry reference in the blueprint) and reuse it across the featured menu section and footer. The v1.1.0 change makes slug renames safe; hand-written /menu links in custom sections will silently break that guarantee.

Centralise structured data in Restaurant Details. JSON-LD is generated from CP fields, and sameAs is derived from the configured social profiles. Add or remove a profile in the CP rather than editing templates. When you need extra schema (e.g. hasMenu, priceRange), extend the JSON-LD partial and keep reading values from the same fieldset so editors have one place to update.

Treat analytics as configuration. Analytics values come from CP fields and are now script-safe encoded. Keep IDs in Restaurant Details, not hardcoded in layouts, so per-environment config stays out of templates and you avoid a stray </script> breaking the page.

Override, don't edit vendor files. Publish or copy the theme's views into resources/views and the fieldset/blueprints into resources/fieldsets and resources/blueprints before customising. That keeps upgrades to v1.x tractable — v1.1.0 touched templates, JSON-LD, and asset loading, all of which you'd otherwise have to re-merge by hand.

Gate sample content per environment. Since non-interactive installs now import sample content by default, make the installer step explicit in your deploy script. On staging it's useful; on production you want a clean content tree. Run the install step as a deliberate, environment-guarded command rather than letting it ride along with an automated composer install.

Verify output, not just the CP. After editor changes, check the rendered JSON-LD with a validator and confirm the analytics snippet still parses. Script-safe encoding is the kind of fix that only shows up when someone pastes unusual characters into a field.

Gotchas and Tips

• Non-interactive installs are no longer empty. This is the most likely surprise in v1.1.0. CI pipelines and provisioning scripts that relied on --no-interaction skipping sample content will now get demo pages, menu entries, and assets. Audit any automation that installs the kit before upgrading.
• Sample content and real content collide. Importing sample content into a site that already has entries can create duplicates or overwrite slugs. Always install into a fresh site or take a backup first.
• Slug renames are now safe — but only where the fix landed. The release covers the featured menu section and footer. If you've added custom menu links elsewhere, they still need to resolve via the entry, not a literal path.
• Empty social profiles mean missing sameAs. If JSON-LD validation complains about absent sameAs, the cause is an unfilled Restaurant Details field, not a template bug.
• Don't double-escape script values. The package now encodes JSON-LD and analytics output script-safely. If you wrap those values in |raw or your own json_encode in an override, you can undo the protection or produce visibly escaped output. Leave the encoding to the package and only adjust the surrounding markup.
• Font removal may shift your visual baseline. Bangers, Chewy, and the broken hardcoded preload are gone. If you had customised typography on top of the theme, check headings and any visual regression snapshots; re-add fonts deliberately in your own asset pipeline rather than restoring the old preload.
• Footer divider lines were removed to match the original design. Screenshots and design QA notes referencing them are now stale.
• Pin the Statamic/Laravel versions you test against. The release is verified on Statamic 6.35 / Laravel 13. Older Statamic 5 or Laravel 11 projects may work but aren't covered — check the JSON-LD and asset pipeline on your actual stack before committing.
• Debugging JSON-LD: view source rather than the rendered inspector, since the script tag contents are what validators and crawlers consume. A broken tag from an unescaped field was the exact failure mode v1.1.0 closed off.
• Extension points to prefer: Restaurant Details fieldset (add fields, keep templates generic), the JSON-LD partial (extra schema), and template overrides in your own views directory. Avoid editing the Composer-installed package — the next patch release will overwrite it.