Weave Code
Vie Bundle Laravel Package
liip/vie-bundle
Symfony bundle that integrates VIE.js and Create.js for in-place, semantic editing of RDFa-annotated content. It provides server-side support for loading and persisting editable resources, so front-end editors can work directly with your application's data.
[DEPRECATED] in favor of SymfonyCmfCreateBundle
Frequently asked questions about Vie Bundle
- What is liip/vie-bundle and what does it do?
- It is a Symfony 2-era bundle that wires the VIE.js and Create.js in-place semantic editing stack to a PHP backend through CreatePHP, RDFa/JSON-LD mapping, and typically PHPCR-ODM/Jackalope persistence. It exposes RDFa-annotated content so VIE-based clients can discover, edit, and persist entities through a Symfony backend. It is not a Laravel package and provides no Laravel integration.
- Can I install liip/vie-bundle in a Laravel application with Composer?
- Direct composer require is effectively non-viable. Dependency resolution will collide with the symfony components Laravel pins, such as http-foundation, console, finder, process, and var-dumper, and the transitive tree including CreatePHP, PHPCR, Jackalope, and Midgard RDFa is uniformly abandoned. A modern PHP 8.x install will likely need --ignore-platform-reqs at best and will still hit PHP 5.x-era type and deprecation failures.
- Does liip/vie-bundle support Laravel 10 or Laravel 11?
- No. The bundle has no service provider, no package auto-discovery, no publishable config, no facade, and no Eloquent or Query Builder adapter. It targets Symfony 2 configuration and a PHPCR/JCR content repository rather than Laravel's relational database model. There is no supported Laravel version.
- Is liip/vie-bundle still maintained?
- No. The repository is explicitly marked DEPRECATED in favor of SymfonyCmfCreateBundle, and that successor is also dormant. Archived repositories receive no advisories and no patches, so a CVE in the transitive tree has no remediation path except your own fork. The client-side VIE and Create.js libraries are independently abandoned as well.
- What are the alternatives to liip/vie-bundle for in-place editing in Laravel?
- There is no maintained drop-in replacement for Laravel. The realistic option is to reimplement a thin Laravel-native equivalent using a ContentController, Form Requests, a Policy layer, and API Resources that accept a JSON write payload and persist to a normalized content_resources/content_attributes schema or a JSON column. Pair that backend with a modern maintained editor rather than VIE or Create.js.
- Can I use liip/vie-bundle with Eloquent models?
- No. The bundle assumes a content repository such as PHPCR/JCR rather than a relational database, and its mapping layer targets VIE entities through CreatePHP. There is no Eloquent or Query Builder adapter, and the PHPCR persistence model does not translate to Laravel. You would have to build your own mapping and persistence layer.
- How do I integrate VIE.js or Create.js with a Laravel backend?
- Treat the bundle as a design blueprint rather than a dependency. The salvageable assets are the JSON write payload shape, the RDFa-to-type mapping conventions, and the edit-session semantics of loading a resource, editing in place, and sending it back with PUT. Those translate cleanly into Laravel controllers with Form Requests, Policies, and API Resources. Because the VIE/Create.js client stack is itself defunct, plan for a modern editor on the front end.
- Does liip/vie-bundle work with PHP 8?
- Not realistically. A modern PHP 8.x install will likely require --ignore-platform-reqs at best and will still encounter PHP 5.x-era type and deprecation failures. The dependency tree, including CreatePHP/CreateBundle, PHPCR, Jackalope, and Midgard RDFa, is uniformly abandoned.
- Is liip/vie-bundle safe for production use?
- No. It is unmaintained and archived, with zero dependents on Packagist, which means zero community validation and no shared bug surface. Its security posture is unmaintained, so advisories are not issued and patches are not available. Adopting it creates an orphaned subsystem risk rather than a normal dependency decision.
- Should I fork liip/vie-bundle or reimplement it in Laravel?
- Reimplement it. Forking is a full internal-product commitment for a feature most teams no longer want, and the client-side contract is independently abandoned, so even a flawless backend port leaves a browser-compatibility gap. The design-reference path is moderate and cheap, while the fork path is poor and expensive. If you have an existing Symfony CMF/PHPCR estate that must interoperate, the recommendation flips, but for greenfield Laravel build native.
Weaver
How can I help you explore Laravel packages today?