Tab Widget Laravel Package

Product Decisions This Supports

• Build vs. buy for a tabbed content block in a CMS editor. This bundle is a reference implementation of a "tabs" content widget (tab labels + panels) exposed through the Victoire CMS widget/block system. It answers "what does this capability actually cost?" — the answer is a template, a form type for tab collection, and persistence: roughly a 1–3 day in-house build, not a multi-week initiative.
• Dependency adoption vs. pattern borrowing. With 2 stars, 0 dependents, and no release since August 2016, the decision this package best supports is "read it, don't depend on it." It is valuable as a spec, not as a dependency.
• Roadmap signal for CMS widget catalogs. If a team is on Victoire CMS, this flags that the widget ecosystem is stale; budget for in-house widget work rather than shopping the catalog.
• Framework fit triage. Despite being catalogued as a Laravel/PHP package, this is a Symfony bundle for Victoire CMS. For a Laravel product it supports only a "pattern reference" decision, not an adoption decision — that mismatch alone should remove it from a vendor evaluation shortlist.
• Scope calibration for accessibility and i18n work. Reviewing the widget exposes what it does not cover (ARIA roles, keyboard navigation, translatable tab labels), which is the real incremental scope in any tabbed-content feature.

When to Consider This Package

Consider inspecting or adopting it only when all of the following hold:

• You are running Victoire CMS on Symfony and need static tabs content authored today with zero customization.
• You are willing to fork and vendor the code, audit it for compatibility with your PHP/Symfony version, and own all patching.
• Your requirement is purely presentational tabs — no data binding, permissions, editorial workflow, analytics, or experimentation hooks.

Look elsewhere — strongly recommended — when:

• You are on Laravel. This is not your ecosystem; a Blade component with Alpine or Livewire covers the same ground and stays in your stack.
• You need a maintained dependency. Zero dependents and a nine-year-old release means no community, no security response, no upgrade path.
• You need accessible tabs (ARIA tablist/tab/tabpanel semantics, arrow-key navigation, focus management) or CMS-agnostic reuse across products.
• Tabs must bind to your own content model, support personalization, A/B variants, or analytics instrumentation — build in-house against your schema.
• Procurement or security review is in play. An unmaintained 2016 bundle will not clear a modern third-party risk assessment, and the cost of shepherding it through exceeds the cost of writing it.

How to Pitch It (Stakeholders)

To executives: This is a small, single-purpose tab widget from an unmaintained 2016 Symfony CMS add-on ecosystem — two stars, zero downstream users, no release in nine years. It is not a strategic dependency and carries avoidable maintenance and security risk. Recommendation: do not adopt; use it only as a design reference. The capability customers actually want — authoring tabbed content — is a commodity UI pattern we can build in-house on our own stack in days, with no new vendor obligation.

To engineering: Read it for the shape of a tabs widget (widget definition, form type, template), then implement natively. If we are on Victoire, fork, pin, and own it. If we are on Laravel, this does not apply — ship a Blade or Livewire component with proper ARIA semantics and test coverage. Either path ends with no new third-party dependency.