Vie Bundle Laravel Package

Product Decisions This Supports

• Closing an inline-editing evaluation without spending a sprint. If a stakeholder or roadmap item proposes click-to-edit, RDFa-annotated content authoring on a PHP stack, liip/vie-bundle is the canonical reference implementation — and its archived, self-deprecated state is itself the answer. It supports a "no" with evidence rather than opinion.
• Build vs. buy on the authoring layer. The deprecation chain (VIE → LiipVieBundle → SymfonyCmfCreateBundle, itself dormant) is evidence that semantic inline editing never sustained a commercial ecosystem. That biases the decision toward buying a headless CMS or adopting a mature editor component instead of building a bespoke semantic editing layer.
• Dependency governance policy. A concrete test case for a written rule: no archived, deprecated, or zero-dependent packages in the production graph. 32 stars, 0 dependents, archived, and self-deprecated is a textbook citation for architecture review guidelines.
• Platform direction. This is a Symfony bundle, not a Laravel package — no service provider, no config publish path, no auto-discovery, no Eloquent adapter. Its existence only in the Symfony world reinforces a Laravel-first platform decision if the team is already on Laravel.
• Roadmap sequencing. If content authoring appears anywhere on the roadmap, this redirects priority toward headless CMS integration or a maintained editor component (TipTap/ProseMirror, Lexical, Editor.js) over any attempt to revive the IKS/VIE/Create.js lineage.
• Modernization budget argument. A cautionary data point for executives: betting content strategy on a niche, academic-origin standard (RDFa inline editing) leaves abandoned infrastructure and no upgrade path.

When to Consider This Package

Consider it only as archaeology, never for adoption:

• Reading the source to understand how RDFa/Create.js editing was integrated server-side, when migrating a legacy Symfony CMF or PHPCR installation and reverse-engineering existing behavior.
• As a historical reference in a post-mortem or standards write-up on semantic content editing.
• As a screening example when training a team — or a tool — to spot unmaintained dependencies.

Look elsewhere immediately when:

• Any production use case exists. Archived + deprecated + zero dependents means no security patching, no PHP/Symfony compatibility work, and no support path.
• You are on Laravel. Adopting it means porting a Symfony 2-era bundle off an abandoned PHPCR/Jackalope persistence stack — strictly worse than starting from a supported option.
• You need content authoring now. Realistic alternatives: a headless CMS (Strapi, Payload, Contentful, Storyblok), an API-driven admin with a JS editor (TipTap, Lexical, Editor.js) on top of Laravel or API Platform, or a Laravel-native CMS such as Statamic or Twill. For Laravel admin panels, Filament plus a rich-text field covers most of what VIE promised, with active maintenance.
• You need RDFa/semantic markup specifically. Treat that as a data-modeling requirement (schema.org, JSON-LD output) rather than a reason to adopt an editing framework.

One caveat to flag in the write-up: the declared successor, SymfonyCmfCreateBundle, is itself effectively dormant. "Deprecated in favor of X" does not mean X is a safe landing spot — verify maintenance before recommending it as a migration target.

How to Pitch It (Stakeholders)

Recommendation: do not adopt. Close the evaluation.

liip/vie-bundle is a 32-star, archived Symfony bundle that its own maintainer marked deprecated in favor of SymfonyCmfCreateBundle. It has zero dependents — no downstream project exercises it, no one files or fixes issues, and no one will patch it when a PHP or Symfony release breaks it. It is also not a Laravel package: it has no Laravel integration surface, so any use on our stack would require a port of abandoned code.

The strategic read matters more than the code. The entire VIE / Create.js / RDFa inline-editing approach failed to attract a sustaining ecosystem, and its designated successor is itself dormant. That is a strong signal not to invest engineering time in semantic inline editing as a differentiator.

What we do instead: pick a supported authoring path — a headless CMS if content is a first-class product surface, or a maintained editor component (TipTap/Lexical/Editor.js) embedded in our existing admin (Filament on Laravel) if we only need rich-text and media authoring. Either is lower risk and lower total cost than adopting or porting this bundle.

Ask: zero engineering budget for this package; a small spike (1–2 days) to confirm the chosen editor/CMS direction against our content model, including whether schema.org/JSON-LD output can be generated independently of the authoring tool. That decouples the semantic-markup requirement from the editor choice and removes the only argument anyone could make for this bundle.