Laravel Shortcodes Filament Laravel Package

Product Decisions This Supports

• Build vs. buy for content templating: The package offloads "who can change what appears on the page" from engineering to content editors. That's the core buy decision — not the shortcode parser (a few days of work) but the Filament admin surface, the attribute model, and the data-source picker that comes maintained.
• Feature: editor-managed dynamic content blocks. The new type field (Static vs. Dynamic) is the roadmap-relevant change. Static shortcodes are a contained, low-risk HTML templating feature you can ship to editors today. Dynamic shortcodes let a non-developer bind a block to a live database source — that unlocks campaign pages, product/event feeds, and promo modules without a deploy. Treat these as two separate rollout decisions with different risk profiles.
• Roadmap sequencing: Because the form only reveals the Dynamic Data Source section when selected, the simple path stays simple. Ship Static to all editors first, gate Dynamic behind a permission and a review of what tables/lookups are exposed.
• Scope boundary: This replaces ad-hoc Blade partials plus a CMS field, not your CMS. Don't plan content versioning, localization, or workflow on top of it.
• Maturity signal for the roadmap: v1.0.1 fixed a bug where every dynamic lookup returned nothing. If dynamic shortcodes were on your roadmap for this quarter, that feature was non-functional in v1.0.0 — re-baseline any demo or pilot built on it.
• Ops decisions this surfaces: dynamic lookups execute at render time. You now own a caching decision, an index-on-lookup-column decision, and an observability decision (see below) that the package does not make for you.

When to Consider This Package

Adopt when:

• You are already on Laravel + Filament; the value is almost entirely in the Filament resource, and it evaporates outside that stack.
• Non-technical or semi-technical editors need to author and edit repeating content snippets without engineering tickets.
• You want a bounded, auditable surface for "editor touches data" rather than giving editors raw query or template access.
• You can absorb a v1.x package with frequent patch releases and schema migrations on minor versions (this release adds a type column).
• You are willing to own caching and access control around dynamic data sources yourself.

Look elsewhere or defer when:

• You are not on Filament. Rebuilding the admin UI on Nova, a custom panel, or plain Blade negates the buy case.
• Content is developer-authored. If templates change on a release cadence, a Blade partial is cheaper and clearer than a database-driven shortcode registry.
• You need versioning, localization, approvals, or scheduled publishing. This is a rendering primitive, not a content platform.
• You need complex or user-parameterized queries. The dynamic model binds a lookup attribute to a data source; if your requirement is filtering, sorting, or pagination driven by the visitor, this will fight you.
• You cannot restrict who creates Dynamic shortcodes. Binding content to a live data source is a privilege, not a default.
• You need stable minor versions. The --force migration republish and the schema change on a 1.0.x patch means you should pin and stage upgrades, not float.

Two upgrade cautions worth deciding on before adoption:

1. Output behavior changed. Attributes with no value are no longer emitted in {{attr}} output, and shortcodes with missing/invalid/soft-deleted lookups now render nothing rather than broken placeholders. Both are correct, but both are silent. Any template relying on an empty attribute being present will change, and any missing lookup will fail invisibly.
2. Silent failure needs a counterweight. Add logging or an admin-visible indicator for shortcodes that render empty due to missing data, or editors will report "the block disappeared" with no diagnosable cause.

How to Pitch It (Stakeholders)

To executives: This lets content editors build and change repeating page modules — promo blocks, listings, campaign sections — from the admin panel instead of filing engineering tickets. The commercial case is lead time on campaign and content launches, not engineering hours saved. The caveat to state plainly: this is a young v1.x package, and the release we're evaluating fixed a defect that made its dynamic-data feature return nothing at all. We should adopt the low-risk static templating path now and pilot dynamic data sources behind a permission before committing to it on revenue-facing pages.

To engineering: Filament-native shortcode registry with two modes — Static (pure HTML templates) and Dynamic (bound to a database data source via a lookup attribute). v1.0.1 adds the type column, fixes the dynamic lookup reading attributes via the wrong method, makes missing/soft-deleted lookups fail closed instead of emitting raw {{db.*}} placeholders, stops emitting empty attributes, and adds a facade for IDE autocompletion. Requires a --force migration republish and php artisan migrate.

What we're asking for:

• Half a day: stage the migration, run the regression pass on existing templates (especially anything relying on empty attributes), then production.
• A caching layer and indexes on lookup columns before Dynamic goes live to editors — lookups run at render time.
• A permission gate on the Dynamic type in Filament, plus logging for empty-render cases.
• Version pinning. Don't float on ^1.0; treat minor releases as potentially schema-changing.