Statamic Bard Text Color Laravel Package

Getting Started

• Require the addon via Composer and confirm your app is already on Statamic 6 / Laravel 11+ before pulling this release; v6.0.1 exists specifically to align the addon with the Statamic 6 runtime, so installing it on a Statamic 5 site will not resolve.
• Statamic addons are auto-discovered through their service provider — after composer require, run php artisan statamic:install (or vendor:publish for the addon's config/tag assets) and clear caches (php artisan cache:clear && php artisan view:clear && php artisan config:clear).
• First place to look is the addon's config/*.php (published to config/) and its service provider — that tells you which tags, modifiers, fieldtypes, or Blade directives it registers.
• First use case: drop the addon's Antlers tag or Blade component into a single template/partial and verify output in a local environment before rolling it across layouts. Confirm it renders in both Antlers and Blade if the addon supports both.

Implementation Patterns

• Antlers-first usage: most Statamic addons expose functionality as a tag (e.g. {{ my_addon ... }}) or modifier ({{ value | my_modifier }}). Use these inside templates and partials rather than reaching for PHP, so Live Preview and the CP's template editor keep working.
• Blade parity: where the addon ships a Blade directive/component, pair it with @php sparingly; prefer passing data through the view composer or the addon's own facade so caching and augmentation behave consistently.
• Fieldtype integration: if the addon provides a fieldtype, add it to a blueprint in the CP, then read the value in templates via the standard augmented value — don't query the raw YAML directly.
• Service container / facade usage: resolve the addon's classes from the container (constructor injection or app(...)) instead of new, so config overrides and test fakes apply.
• Caching: wrap expensive tag output in Statamic's {{ cache }} tag or the addon's own cache config; remember Statamic's static caching and the addon's cache can interact — invalidate both when content changes.
• Multisite: test the addon against a second site/locale early; tags and fieldtypes often need explicit site handling.
• Events & hooks: hook into Statamic events (EntrySaved, TermSaved, etc.) in your own listener when you need side effects, rather than modifying the addon's source.

Gotchas and Tips

• Statamic 6 is the compatibility gate. v6.0.1 is a compatibility release, not a feature release — expect API alignment rather than new behaviour. Pin statamic/cms to ^6.0 and check the addon's composer.json constraints before upgrading an existing site.
• Upgrade path: upgrade Statamic to 6 first, run migrations (php artisan migrate), then update the addon. Mixing versions mid-upgrade is the most common source of "class not found" and signature-mismatch errors.
• Clear everything after upgrade: config, view, route, and application caches — plus php artisan statamic:stache:warm if the Stache behaves oddly. Stale Stache is a frequent red herring.
• Publish config again: if you previously published the addon config, re-publish (back up your overrides first) — a major-version bump may add or rename keys, and missing keys fall back silently.
• Check the changelog beyond the headline: a "compatibility update" can carry transitive dependency bumps (Flysystem, Symfony, Laravel) that affect your own code. Run your test suite, not just a manual smoke test.
• Extension points: prefer the addon's documented events, config flags, and container bindings over subclassing internals; internal classes are the most likely to shift again in the next Statamic 6 patch.
• Debugging: enable APP_DEBUG, use php artisan statamic:stache:clear, and check the CP's utilities/updates screen. For tag issues, dd() inside a throwaway template is faster than chasing logs — then remove it before committing.