Statamic Extended Section Laravel Package

Getting Started

Start by pulling the addon in through Composer from your Statamic project root:

composer require appswithlove/statamic-extended-section

Statamic addons register their service provider via package discovery, so in most installs there is nothing to publish and no config file to copy. The first thing to check after install is whether a new fieldtype or a set of blueprint options appears in the control panel — open an existing blueprint (or create a throwaway one) and look at the fieldtype list for anything prefixed with the addon name, and inspect the available field settings on a section.

The first real use case is almost always the same: you have a long publish form and the stock section fieldtype is too plain. You want a section that behaves differently — conditionally shown, styled, or grouped differently — without rewriting the whole blueprint. Drop a section field into your blueprint YAML, point its options at the addon, and start wrapping the fields you want grouped.

sections:
  main:
    display: Content
    fields:
      - handle: settings_section
        field:
          type: <addon section handle>
          display: Settings
          # addon-specific options here
      - handle: my_toggle
        field:
          type: toggle
      - handle: details
        field:
          type: textarea

Read the addon's README and src/ directory before configuring — with a package this small (few stars, single maintainer agency) the source is the documentation, and the field settings you can pass are defined there rather than in prose docs.

Implementation Patterns

Wrap-and-group in blueprints. The bread-and-butter pattern is treating the extended section as a container. Put the section field before the fields it should affect, then nest or list those fields beneath it in the blueprint. This keeps the publish form readable without splitting content across tabs.

Conditional display. The most common reason to reach for a section addon is showing or hiding a block of fields based on another field's value (e.g. only show "SEO overrides" when a toggle is on). Configure the condition in the section's field settings and reference sibling field handles. Keep the referenced field above the section in the blueprint so it evaluates predictably.

Reusable fieldset composition. Define the extended section once in a partial/fieldset YAML and include it across multiple blueprints. This is where a section addon earns its keep in day-to-day work — the grouping and display behavior travel with the fieldset instead of being re-declared.

Integration with Grid and Bard. Sections inside Grid/Bard sub-fieldsets behave differently from top-level ones because the condition scope is the row/set, not the whole entry. Test any conditional logic inside a Grid row before assuming it works — scoping is the usual failure point.

Blade-side access is unchanged. Sections are a control-panel construct; in Antlers/Blade you still access the underlying fields by handle as normal. Don't expect the section field itself to render — it's organizational.

Deployment workflow. Commit the composer.json/composer.lock change, run php artisan vendor:publish only if the README says assets/config are needed, and add the standard php artisan statamic:stache:clear + php artisan cache:clear to your deploy script so blueprint changes are picked up.

Gotchas and Tips

Treat it as low-support software. Four stars and zero dependents means you are effectively the QA team. Pin the version in composer.json, read the changelog for the 2026-03-06 release before bumping, and be ready to vendor or fork it — the codebase is small enough that a one-file patch is realistic if you hit a bug.

Version-pin against your Statamic major. Statamic's fieldtype APIs and CP asset pipeline changed across v3/v4/v5. Confirm the addon's composer.json constraints match your installed Statamic version before debugging phantom issues; a mismatch often manifests as a blank or non-rendering section rather than an error.

Field handles in conditions are case- and scope-sensitive. A condition pointing at seo_enabled won't resolve if the actual handle is seo-enable or if the field lives in a different tab/section. When a section refuses to show, dump the entry's data or log the values in the CP to confirm the handle and its resolved value.

Publish the views before theming. If the addon ships Blade views, publish them (php artisan vendor:publish --tag=...) and edit the published copies rather than the vendor ones, or your customizations vanish on the next composer update.

Cache invalidation after blueprint edits. Statamic caches blueprints and the stache. A section that "stopped working" after a YAML edit is usually a stale cache — clear stache and config cache, then hard-refresh the CP (browser caching of CP JS is also a common red herring).

Check the CP build. If the addon includes Vite/JS assets, verify they were built and are being served (look for 404s in the browser network tab when opening a publish form). Statamic addons that bundle CP JS are the ones most likely to break silently on upgrade.

Extension points are thin. With a package this small, expect the cleanest extension path to be overriding the published view or extending the fieldtype class in your own addon that depends on this one — not a rich event/hook surface. Plan customizations accordingly.

Watch the opportunity score, not just the stars. A 7.2 score with a high opportunity component suggests an under-served niche. That's good if you need the feature and are comfortable maintaining a small dependency; it's a warning if you were hoping for a battle-tested, actively-supported package. Budget time to read the source and possibly contribute fixes upstream.