Laravel Shortcodes Laravel Package

Product Decisions This Supports

• Content authoring model (build vs. buy): This package is a candidate for the "who writes the content?" decision — it lets non-technical editors embed dynamic components ([video id="42"], [cta url="/pricing"]) inside stored rich text without a developer shipping a release. If your roadmap includes marketing pages, a blog, docs, email templates, or any editor-managed copy, this is the cheapest way to prototype that capability.
• Buy vs. build for a small parser: Shortcode parsing looks trivial and isn't — nested tags, self-closing tags, quoted attributes, escaping, and safe handling of unknown tags are all edge cases that generate bug reports. Adopting this package is a defensible "buy" (MIT, no cost) provided you accept it as a starting point to vendor or fork rather than a long-term dependency.
• CMS-lite vs. full CMS: This supports the decision to avoid pulling in Statamic/October/a headless CMS for one or two editor-managed surfaces. If shortcodes cover 80% of the need, you defer a much larger platform commitment.
• Email and notification templating: A frequent under-scoped use case — letting support/ops edit transactional email bodies with [order_id]-style tokens. This shifts template changes from engineering tickets to operations, which is a measurable support-cost lever.
• Stakeholder-visible tradeoff: It accelerates a feature (editor-driven dynamic content) at the cost of a maintenance tail. That is a roadmap sequencing decision, not just a technical one.

When to Consider This Package

Adopt when:

• You have stored, editor-authored content that needs a small set of developer-defined dynamic inserts, and you want the content to remain portable/readable as plain text.
• The content authors are semi-technical (marketing, support, docs) and a full WYSIWYG component system or headless CMS is over-scoped for the next two quarters.
• You can vendor the source into your repo — with 27 stars, one apparent maintainer, and a last release in January 2023, treat this as code you own, not a dependency you consume. Budget a few days to read the parser and write tests around the syntax you actually expose.
• Shortcode handlers stay fully under your control — the package only parses; you register each handler, so you can enforce escaping and an allowlist of tags.

Look elsewhere when:

• Content is developer-authored only — use Blade components or Blade::render and skip the abstraction entirely.
• You need rich, structured, nested content (reusable blocks, layouts, versioning, previews, multi-locale workflows). That's a CMS decision; shortcodes will buckle under it. Evaluate Statamic (Laravel-native) or a headless CMS.
• You need Markdown plus extensions — league/commonmark with custom extensions is better maintained, better specified, and has a real security posture.
• The content is untrusted end-user input. Rendering user-supplied shortcode syntax safely requires an allowlist, escaping discipline, and rate/abuse thinking; this package gives you none of that by default.
• Maintenance risk is unacceptable — e.g., a compliance-sensitive surface or a team with no PHP capacity to own a fork. The stale release cadence and low adoption signal are real; do not put this on a critical path without an owner.

How to Pitch It (Stakeholders)

To executives: This is a small, free, MIT-licensed library that lets non-engineers edit parts of the product's content — marketing pages, help articles, email templates — without filing engineering tickets. It buys us speed on a content-driven feature without committing to a CMS platform. The tradeoff: it is a low-adoption package last updated in early 2023, so we would copy the code into our repository and own it rather than depend on the author. Cost is roughly a few engineering days; the alternative (a full CMS or a bespoke editor) is weeks to months.

To engineering: Treat it as a parser we fork, not a dependency we install and forget. Scope it to an explicit allowlist of shortcodes, register handlers ourselves, escape all interpolated output, and add tests for nesting, unknown tags, and malformed attributes before it touches anything user-facing. If the requirement grows past flat inserts, we stop extending it and revisit the CMS decision.