Widget Bundle Laravel Package

Product Decisions This Supports

First, a scope correction that itself is a PM decision: despite the brief labeling this a "Laravel/PHP package," evgeniy-it/widget-bundle is a Symfony bundle. If the product runs on Laravel, this package is not a candidate at all — it cannot be installed or bootstrapped without Symfony's bundle kernel. That single fact should kill it from a Laravel backlog in under five minutes.

Assuming a Symfony context, the package is a reference implementation of a content-authoring pattern, not a production dependency. It supports these decisions:

• Content model: inline shortcodes vs. structured blocks. The [[widget_name? &setting=value]] syntax (a ModX-snippet / WordPress-shortcode clone) lets editors embed dynamic fragments inside free-text body copy. This is a real fork in the road: shortcodes buy editor flexibility and cheap retrofitting into existing WYSIWYG fields; block editors buy structure, validation, and better authoring UX but require a content migration. Evaluating this package forces that decision to be made explicitly rather than by accident.
• Decoupling editorial changes from deploys. The core product value — an editor inserts a product card, CTA, pricing table, or live example without a developer shipping code — maps directly to a measurable roadmap goal: reduce content changes requiring an engineering release to near zero.
• Build vs. buy, resolved toward build. With 0 stars, 0 dependents, a single 2017 release, and no test suite or security review visible, this is not "buy." But the surface area is genuinely small (a shortcode parser plus a Twig filter, with nested-widget support and array/assoc-array argument parsing). That makes it a cheap in-house build with this repo as the written spec — roughly a 2–3 week spike for one backend engineer — rather than an expensive from-scratch design exercise.
• Roadmap use cases it validates: reusable marketing blocks inside landing pages, embedded live examples in documentation, parameterized email/newsletter templating, multi-tenant or per-brand content fragments, and CMS migration where legacy snippet markup must keep rendering.
• Rendering-safety strategy. Arbitrary shortcodes in user- or editor-supplied content are an injection surface. The package's own answer is a Twig filter, which pushes the decision of whether to sandbox rendering (Twig SandboxExtension) into the security review — a decision worth surfacing early regardless of which library wins.

When to Consider This Package

Consider it (narrowly):

• You maintain a legacy Symfony 2.x/3.x application already using ModX-style snippet syntax and need a compatible parser rather than a rewrite.
• You want a MIT-licensed, small-footprint reference implementation to fork or reimplement, and you have accepted ownership of that fork on day one. The permissive license makes this legally clean.
• You need nested widget resolution and typed arguments (&settingArray=[1,2,3], `&settingAssocArray=`{'k':'v'}) and want a working example of that parsing grammar before writing your own.

Adoption criteria to check before any commitment:

• Declared PHP and Symfony version constraints vs. your runtime (a 2017 bundle will almost certainly not install cleanly on Symfony 5/6/7 — expect composer require to fail or require --ignore-platform-reqs, which is itself a red flag).
• Who owns maintenance, and what the fork-and-patch budget is (assume 100%).
• Whether output escaping and user-supplied content are handled; whether the shortcode grammar can be abused for template injection.
• Caching behavior for rendered widgets, and cost when a page contains dozens of nested fragments.
• Test coverage — none is evident.

Look elsewhere when:

• You are on modern Symfony — prefer a small Twig runtime extension you own, or Twig's template_from_string with a sandbox, over an abandoned 2017 bundle.
• You are on Laravel — evaluate thunderer/shortcode or webwizo/laravel-shortcodes, or Blade components; this bundle is inapplicable.
• Security or compliance matters (multi-tenant, UGC, regulated content) — use a maintained, audited parser or sandbox aggressively; do not inherit a nine-year-dormant dependency.
• You actually want structured authoring — a block editor (Gutenberg-style) or Symfony UX components is the better long-term answer than regex-driven shortcodes.
• You need vendor support, SLAs, or a CVE response path — none exist here.

How to Pitch It (Stakeholders)

To executives (one paragraph): The idea here is worth adopting; the package is not. It lets editors drop dynamic content — product cards, CTAs, pricing tables — directly into page copy without an engineering release, which is the kind of change that removes a recurring tax on the content team. But the artifact itself has one release from January 2017, zero known dependents, zero community, and no visible tests or security review, and it targets Symfony rather than our stack. Adopting it means owning a fork from day one. Recommendation: do not adopt; fund a short internal build using this repo as the specification. Estimated at two to three engineer-weeks, after which we own the code outright and the maintenance risk disappears.

To engineering: Treat this as a design document, not a dependency. The valuable parts to reuse conceptually are the argument grammar (&key=value``, plus JSON-ish array and associative-array arguments), recursive/nested widget resolution, a template-override mechanism, and a single Twig filter as the render entry point. The parts to discard are the code itself and its 2017 platform constraints. Non-negotiables in our version: explicit PHP/Symfony version support, unit tests around the parser (nesting, escaping, malformed input, backtick edge cases), output escaping by default, sandboxed template rendering, and a cache layer keyed on widget + arguments. Keep the grammar compatible with ModX/WordPress-style shortcodes so migrated content renders unchanged.

To the content/editorial team: You get a documented shortcode any editor can type, with a widget library and a preview path, instead of filing a ticket.

Success measures: number of content changes shipped without a deploy (target: near 100% of widget-level edits), time-to-first-widget for a new editor, count of distinct widgets reused across pages, and zero rendering regressions in the shortcode parser's test suite.