Tailwind Fieldtype Laravel Package

Getting Started

This is the Statamic 6 / Tailwind 4 compatible line, currently in beta. Treat it as a deliberate upgrade target rather than a drop-in patch.

Minimal setup:

composer require krakero/tailwind-fieldtype:^3.0@beta

Then:

1. Read CHANGELOG.md and UPGRADE.md before touching an existing site. The beta is explicitly scoped to Statamic 6 + Tailwind 4, so check those constraints against your app first.
2. Confirm the fieldtype handle and configuration options in the package README, then add the field to a blueprint or fieldset.
3. Clear caches after install and after config changes:

php artisan config:clear
php artisan view:clear
php artisan statamic:stache:clear

First use case: add the field to a page or collection blueprint so editors can choose Tailwind utility classes in the Control Panel, then render the saved value in your Antlers or Blade template and confirm the classes appear in the compiled Tailwind 4 CSS. That last step is the real smoke test — the field saving a value is only half the job.

Where to look first:

• UPGRADE.md for breaking changes from the 2.x line.
• Package config and README for the exact fieldtype handle, available options, and any publishable assets.
• Your Tailwind 4 CSS entrypoint, because class discovery is the most common integration failure point.

Implementation Patterns

Blueprint-first reuse. Define the field once in a reusable fieldset and include it across collections. This keeps editor experience consistent and avoids drift between sections of the site.

# resources/fieldsets/tailwind_classes.yaml
title: Tailwind Classes
fields:
  -
    handle: tailwind_classes
    field:
      type: tailwind # verify exact handle in the package README
      display: Tailwind Classes

Render with a fallback. Never assume the field is populated:

<div class="{{ tailwind_classes ?? 'p-4' }}">
    {{ content }}
</div>

<div class="{{ $page->tailwind_classes ?: 'p-4' }}">
    {{ $content }}
</div>

Pair with structured content. The fieldtype is most useful alongside Bard/Replicator sets, where each set can carry its own utility classes. Keep the allowed class vocabulary narrow per set so editors do not turn every block into a snowflake.

Use defaults for new entries. Set a sensible default in the blueprint so new pages render correctly before an editor touches the field. This reduces “blank page” support tickets during rollout.

Integration with Tailwind 4. Tailwind 4 uses CSS-first configuration and automatic content detection. If your class values live in YAML/content rather than source templates, verify they are being discovered. You may need explicit @source directives or an inline safelist for dynamic class values:

@import "tailwindcss";

@source "../../resources/views";
/* Add explicit sources or inline safelist entries for stored class values */

Upgrade workflow. Create a branch, upgrade Statamic and Tailwind first, then install the beta fieldtype. Exercise every blueprint that uses the field, rebuild CSS, and compare the generated stylesheet before and after. Do not combine the fieldtype upgrade with unrelated template refactors.

Gotchas and Tips

• Beta semantics matter. ^3.0@beta can resolve to a different beta over time. Pin the exact version in composer.lock and avoid unattended updates in production until a stable 3.x is available.
• Statamic 6 + Tailwind 4 only. Do not install this beta on a Statamic 5 or Tailwind 3 project. If you need to stay on the older stack, stay on the 2.x line.
• Dynamic classes may not be generated. Tailwind only emits classes it can find. Classes stored in content are not always scanned. If styles are missing, inspect the field value in the entry YAML, then check the compiled CSS for the class. Add an explicit source or safelist if needed.
• Whitespace and escaping. Render class strings raw, not HTML-escaped, and trim stray whitespace. Multiple spaces are harmless in HTML but make debugging and diffing harder.
• Cache layers stack up. A changed fieldtype config or published view may require config:clear, view:clear, and statamic:stache:clear. Also rebuild front-end assets; stale compiled CSS is frequently mistaken for a fieldtype bug.
• Editor guardrails. If the field allows free-text classes, editors can introduce arbitrary utilities that break layout or bypass your design system. Prefer constrained options or validation where the package supports it.
• Upgrade regressions are likely in field rendering, not storage. Check whether saved values still render identically. Compare CP field UI, saved YAML, and front-end output separately to isolate whether the issue is the fieldtype, the template, or Tailwind generation.
• Extension points to inspect. Look for publishable config, publishable views, and validation hooks. Overriding the fieldtype view is usually preferable to forking the package if you need CP tweaks.
• Debugging checklist: confirm package version with composer show krakero/tailwind-fieldtype; confirm field handle matches the blueprint; inspect saved entry data; check compiled CSS for the class; clear caches and rebuild assets; then reproduce on a clean entry.
• Have a rollback plan. Because this is a beta, keep the previous lockfile and a tested downgrade path. Read UPGRADE.md for any data or config migrations before rolling forward.