Laravel Shortcodes Laravel Package

Product Decisions This Supports

• Build vs. buy for lightweight content templating. Shortcodes let non-technical authors embed dynamic components (product cards, CTAs, pricing tables, form embeds) inside stored content without a full CMS or page builder. Buying costs a composer require; building costs engineering time on parsing edge cases (self-closing vs. enclosing tags, attribute parsing, escaping, nesting) that this package already absorbs.
• Roadmap sequencing against framework upgrades. v3.0.0 is a compatibility release, not a feature release: it drops Laravel 11 and requires Laravel 12 or 13. The practical PM decision is not "adopt v3" but "when does our Laravel 11 → 12/13 upgrade happen?" — since the 2.x branch is now the only path for Laravel 11 teams, and it stops receiving updates alongside Laravel 11's security support.
• Supportability and lifecycle risk. A minor dependency that tracks upstream framework releases on the same cadence is a low-maintenance line item. A dependency that lags becomes a blocker on the framework upgrade critical path. This release is a positive signal on maintenance cadence, but it is a single-maintainer package — treat it as a candidate for vendoring or a thin internal wrapper if it ends up in the critical path.
• Scope boundary for the content platform. Decide explicitly whether shortcodes are the sanctioned extension point for author-facing content, or a stopgap. If shortcodes are the answer, the product question becomes "which shortcodes exist and who approves new ones?" — that's an editorial governance decision, not an engineering one, and it belongs in the roadmap before author adoption scales.
• Feature bets it unlocks cheaply. Personalized CTAs, locale-specific embeds, and campaign content variations authored per-market without a deploy. Useful for marketing-driven roadmap items that would otherwise need a CMS investment.

When to Consider This Package

Consider adoption when:

• Content is stored in the database or config and edited by non-developers who need to embed dynamic components, and a full CMS/page-builder is disproportionate to the need.
• You are on Laravel 12 or 13 on PHP 8.2–8.5. On Laravel 12, PHP 8.2–8.5 is supported; on Laravel 13, PHP 8.3–8.5.
• You want a small, single-purpose dependency rather than a platform commitment, and you are comfortable owning the editorial conventions around it.
• You can absorb the small blast radius of a solo-maintainer package: low call volume, easy to fork or vendor.

Look elsewhere when:

• You are still on Laravel 11. Pin to the 2.x branch, but recognize that branch is frozen and effectively unsupported now that Laravel 11 is out of security support. If Laravel 11 is a long-term commitment, this package is a liability — vendor it or build the parser internally. Do not let the v3 release sit in the backlog as an untriaged "upgrade" item.
• You need rich-text authoring, block editing, previews, or revision history — that is a CMS decision, not a shortcode decision.
• You need general templating (Blade, Twig). Shortcodes are a syntax for author convenience, not an architecture.
• Content authors are developers. Shortcodes add an indirection layer with no payoff if the people writing content can already write Blade.

How to Pitch It (Stakeholders)

To executives: This is a small, low-cost library that lets marketing and content teams embed dynamic elements in site copy without engineering involvement or a CMS purchase. The v3.0.0 release contains no new product capability — it is a compatibility update that keeps the package aligned with supported Laravel versions. The only decision it forces is timing on our Laravel 11 → 12/13 upgrade; there is no user-facing change and no new spend.

To engineering: v3.0.0 raises the minimum to Laravel 12 and adds Laravel 13 support; Laravel 11 support is dropped and stays on the 2.x branch. No API-level breaking changes are documented beyond the version floor, so the upgrade is a dependency bump gated entirely on the framework upgrade. Two asks: (1) sequence this into the Laravel upgrade workstream rather than treating it as standalone work, and (2) since 2.x is now effectively frozen, flag any service still on Laravel 11 that depends on this package so it isn't silently stranded. If the package lands on a critical path, evaluate vendoring or wrapping it — single-maintainer risk is real but the surface area is small.