Table Widget Laravel Package

Getting Started

Read the fine print first: this is not a Laravel package. friendsofvictoire/table-widget is a Symfony bundle (FriendsOfVictoire/WidgetTableBundle) that plugs into Victoire, a Symfony-based CMS. There is no service provider, no facade, no Blade views, and no config/table-widget.php. A Laravel developer cannot composer require this into an artisan-driven app and expect it to boot.

Minimal steps to actually see it work:

1. Stand up a Symfony 2.x/3.x + Victoire application (the 2016-10-06 release predates Symfony 4; expect AppKernel, not Flex).
2. composer require friendsofvictoire/table-widget in that project.
3. Register the bundle in AppKernel::registerBundles() and run the Victoire widget discovery/asset commands (assets:install, assetic:dump in that era).
4. Open a Victoire page in the backend editor, add the Table widget from the widget palette, fill in rows/columns through its form, and render the page.

Where to look first: the bundle's Resources/views/ for the Twig templates (the actual rendering contract), the form type that defines what an editor can enter, and the Widget model class that declares the widget name and default attributes. Those three files tell you everything about the data shape and HTML output.

First real use case: a marketing/CMS page where a non-technical editor needs to drop in a small data table (pricing tiers, spec sheets, opening hours) without touching templates. That is the entire scope of this bundle.

Laravel verdict: treat this as a reference implementation, not a dependency. The idea — an editor-configurable table widget with a fixed data schema and a server-rendered template — ports cleanly to Laravel as a Blade component plus a JSON column or a table_widgets table.

Implementation Patterns

If you are genuinely in Victoire (Symfony):

• Subclass, don't fork. Extend the widget class and override the Twig template path so your project owns markup. Re-register the widget under a new name rather than editing vendor code — a 2016 bundle will never see another release.
• Template override via bundle inheritance ({% extends '@FriendsOfVictoireWidgetTable/...' %} or the Symfony bundle-override path in app/Resources/) is the sanctioned extension point. All styling decisions belong there.
• Widget data is stored per-widget-instance, typically as attributes on the Victoire Widget entity, so editors get independent tables per page. Do not try to share one table definition across pages — there is no shared-table concept.
• Compose with Victoire layout slots: put the table inside a column widget rather than fighting its width with CSS.

If you are porting the idea to Laravel (the realistic path):

// app/View/Components/DataTable.php
class DataTable extends Component
{
    public function __construct(
        public array $columns,
        public array $rows,
        public bool $striped = true,
    ) {}
}

• Store the widget payload as a json column (tables.schema) or a translatable JSON field; validate with a FormRequest so editors can't submit ragged rows.
• Render server-side with Blade and escape every cell by default — CMS table widgets are a classic stored-XSS vector if a cell is marked {!! !!}.
• Keep an edit surface (Filament/Nova/plain CRUD) separate from the render surface; that mirrors Victoire's editor/renderer split and keeps the Blade component dumb.
• Cache rendered fragments (Cache::remember("table:{$id}")) and bust on save — tables on CMS pages are read-heavy and change rarely.

Integration tip: if you must consume Victoire-rendered HTML from a Laravel app, do it over HTTP and treat the output as untrusted markup (sanitize with a whitelist) rather than trying to reimplement the widget.

Gotchas and Tips

• Abandoned since 2016, 1 star, 0 dependents. Pin nothing to it. Assume no security patches, no PHP 8 compatibility, no Symfony 4+ support, and no maintainer response. Audit before any production use.
• Era-locked dependencies. Expect symfony/symfony ~2.7|~3.0, Assetic for assets, and possibly twig/twig ^1.x. Composer will fight you on any modern PHP; --ignore-platform-reqs is a trap, not a fix.
• No Laravel bridge exists and none is coming. If your team is Laravel-first, budget a day to rebuild this as a Blade component rather than a week wrestling Symfony into your stack.
• Widget registration is implicit. Victoire discovers widgets by convention; if the widget doesn't appear in the editor palette, check bundle registration, cache clear, and asset compilation in that order — the failure is silent.
• Template resolution surprises. With bundle inheritance, a stale compiled template in var/cache will mask your override. Always cache:clear after touching Twig paths.
• Escaping and markup. Table cells frequently allow rich text in CMS widgets. Verify what the form type permits; wrap output through a sanitizer (HTMLPurifier or a Laravel sanitizer) before rendering as HTML.
• Responsive behavior is not included. A 2016 table widget renders a plain <table>. Plan a wrapper with overflow-x:auto or a stacked-card breakpoint yourself.
• Translations: if the widget supports per-locale values, confirm how Victoire's locale fallback interacts with your content; missing translations usually render empty cells rather than falling back.
• Debugging: there are essentially no tests in the bundle. When output looks wrong, dump the widget's attribute array in the template ({{ dump(widget) }} with Twig debug on) — that array is the API.
• Extension points that actually exist: the form type (what editors can enter), the Twig template (markup), and the widget class (name/defaults). Anything beyond those three means forking an unmaintained repo.