- Is friendsofvictoire/text-widget actually a Laravel package?
- No. Despite being catalogued as a Laravel package, the repository FriendsOfVictoire/WidgetTextBundle is a Symfony bundle built to register itself with the Victoire CMS widget manager. It depends on Symfony's Bundle base class, a DependencyInjection extension, Doctrine ORM entities, and Twig templates, none of which have a Laravel equivalent. There is no service provider, facade, or config file that a Laravel application could consume.
- Can I install friendsofvictoire/text-widget with Composer in a Laravel app?
- In practice, no. A current Laravel application runs PHP 8.2+ with Symfony 7 components, while this bundle pins Symfony 2.x/3.x-era dependencies alongside Twig and Doctrine ORM 2.x. Composer will almost certainly fail on PHP and symfony/* constraint conflicts before any code runs. A throwaway composer require in a scratch branch is the cheapest way to confirm the conflict for yourself.
- Which Laravel versions does this text widget support?
- None officially. The package was never built for Laravel and has no documented Laravel version support, tests, or CI against any Laravel release. Treat any claim of Laravel compatibility as unverified until you see an actual service provider and a passing test suite.
- What is the text widget actually designed for?
- It renders a title and rich-text body block inside a Victoire CMS page-builder slot. The feature surface is a commodity content primitive: a heading, a body, and safe or raw HTML output. Victoire itself has been inactive for years, so the bundle exists to serve a dormant CMS rather than a maintained ecosystem.
- Is friendsofvictoire/text-widget safe to use in production?
- It carries structural risk rather than a single fixable bug. Upstream is dormant, its dependency pins sit on Symfony 2.x/3.x and Doctrine ORM 2.x branches that are past end-of-life and outside security support, and any CVE in that chain becomes yours permanently. With zero stars, zero dependents, and no downstream validation, there is no production evidence to benchmark against.
- How do I add a text widget to a Laravel dashboard without this package?
- Build it natively, which is roughly one engineer-day of work. A typical implementation is an Eloquent model and migration for fields like id, locale, title, body, and position, plus a Blade component for rendering and an admin form field in Filament, Nova, or Twill. That gives you escaped output by default, optional HTML rendering, and zero dependency inheritance.
- Does the package support dynamic values, closures, or safe HTML output?
- The project description advertises a fluent API, dynamic values and closures, escaped output by default, and optional HTML rendering. Those are reasonable requirements for a dashboard text widget, but they are also trivial to implement in a native Blade component. Nothing in that feature list justifies importing a Symfony bundle and its container contracts.
- Should I fork the bundle or port it to Laravel?
- Neither is recommended. Integrating it would require a second container, a Doctrine connection, and a Twig rendering path inside Laravel, and the only deliverable is a worse version of a one-day native build. A permanent fork of an end-of-life Symfony bundle is an unbounded maintenance obligation. The only asset worth reusing is the Twig templates as a design and field-name specification, subject to the licence terms.
- What are the best alternatives for dashboard text widgets in Laravel?
- Use whatever admin panel you already standardise on, such as Filament, Nova, or Twill, and add a simple text field or custom widget class. A plain Blade partial with a view component covers headings, notes, and helper content without any third-party dependency. If you need rich text, pair it with an editor package that is actively maintained for your Laravel version.
- I have legacy Victoire content. How should I handle it?
- Treat it as a data migration project, not a Composer dependency. Inventory the stored title and body fields, map them to a native text_widgets table with locale and position columns, and migrate the content once. That preserves the data without inheriting an unsupported Symfony runtime, and it lets you retire the legacy system on your own schedule.