Date Widget Laravel Package

Getting Started

Reality check first: friendsofvictoire/date-widget is not a Laravel package. It is a Symfony bundle (FriendsOfVictoire\WidgetDateBundle) that plugs a "Date" widget into Victoire DCMS, an open-source Symfony CMS. It has no service provider, no facade, no config/date-widget.php, and no Laravel integration path. With 1 star, 0 dependents, and a last release of 2016-08-22, the honest day-to-day answer for a Laravel developer is: you will not be leveraging this as a dependency — you will be reading it as a reference implementation, or maintaining a legacy Symfony app that already has it installed.

Minimal install (legacy Symfony 2.8/3.x app only):

composer require friendsofvictoire/date-widget

// app/AppKernel.php
$bundles = [
    // ...
    new Victoire\Widget\DateBundle\VictoireWidgetDateBundle(),
];

bin/console cache:clear

Where to look first, in this order:

1. Widget/ — the widget entity class; this defines the fields the editor fills in (the actual date value, format, maybe a label) and the getWidgetName() identifier.
2. Resources/views/ — the Twig template that renders the widget on the front end. This is the file you will almost always override.
3. Resources/config/services.yml — the renderer service and its victoire.widget tag, which is what makes the widget discoverable in the backoffice.
4. DependencyInjection/ — usually near-empty for a widget bundle; don't expect meaningful config knobs.

First use case: after enabling the bundle and clearing cache, open the Victoire backoffice, edit a page, drag the "Date" widget into a slot, set the date and format, save, and confirm it renders on the front end. That end-to-end loop is the entire product.

Implementation Patterns

Understand the Victoire widget contract before touching anything. Every widget in this ecosystem is the same shape: an entity implementing the widget interface + a renderer service tagged victoire.widget + a Twig template. The Date widget is a thin instance of that pattern, so most "customization" is really template and entity work, not package configuration.

Pattern 1 — template override (the 90% case). Don't edit vendor files. Override the template from your app or from a project bundle:

{# app/Resources/VictoireWidgetDateBundle/views/widget.html.twig #}
<time datetime="{{ widget.date|date('Y-m-d') }}">
    {{ widget.date|date(widget.format|default('d/m/Y')) }}
</time>

Semantic <time> markup, an explicit datetime attribute for machines, and a human format that is configurable per-widget is the whole value-add here. If you need more than that, you're building a new widget, not configuring this one.

Pattern 2 — slot composition. Date widgets are rarely used alone. The realistic workflow is placing one in a header/footer slot alongside text widgets to render things like "Last updated: …" or an event date. Treat it as a leaf component in a slot tree, not as a data source.

Pattern 3 — decorate the renderer if you need logic. If the date must come from somewhere other than the editor (a repository, a "now" fallback), decorate the tagged renderer service rather than subclassing the entity:

# app/config/services.yml
services:
    app.widget.date_renderer:
        class: AppBundle\Widget\DateRenderer
        decorates: victoire_widget_date.renderer
        arguments: ['@app.widget.date_renderer.inner']

This keeps the backoffice form intact and the front-end output under your control.

Pattern 4 — the Laravel port (what you'll actually do). If you're on Laravel and like the idea, don't install the bundle — reimplement it in ~30 lines:

// app/View/Components/DateWidget.php
class DateWidget extends Component
{
    public function __construct(
        public ?Carbon $date = null,
        public string $format = 'd/m/Y',
    ) {}

    public function render()
    {
        return view('components.date-widget');
    }
}

Store date + format in a JSON column (mirroring the widget entity's fields), render with <x-date-widget :date="$page->meta['date']" />. That gives you the same editorial capability without dragging Symfony 3-era transitive dependencies into a modern Laravel app.

Integration tip: if you're maintaining the legacy Symfony app, pin the dependency and wrap it. Never let widget templates call date() with an implicit timezone — pass an explicit DateTimeInterface with the site's timezone into the template so output is deterministic across environments.

Gotchas and Tips

• Abandonment is the headline. Last release 2016, one star, zero dependents. Assume no compatibility with PHP 8.x or Symfony 4+ (Flex, autoconfiguration, AbstractController). composer require inside a modern Laravel or Symfony app will either fail resolution or pull a stale Symfony dependency tree you do not want.
• No Laravel story whatsoever. There is no service provider to auto-discover, no publishable config, no facade. Composer will happily install it into vendor/, but nothing will happen. Treat any attempt to "just require it" in Laravel as a dead end.
• Widget not appearing in the backoffice is almost always one of: bundle not registered in the kernel, cache not cleared, or the renderer service missing/losing its victoire.widget tag. Check bin/console debug:container --tag=victoire.widget.
• Template overrides silently not applying — Victoire/Symfony caches compiled Twig aggressively. Clear var/cache/dev and the app cache after any override; a stale override is indistinguishable from a wrong path.
• Formatting and timezone drift. The widget stores a date; whether it's a DateTime, a string, or a timestamp depends on the entity class — verify it before writing templates. Formatting via PHP date() uses the server timezone, not the editor's, so a date set as "today" can render as yesterday in UTC-offset environments.
• Don't hardcode the format in the template. If the widget exposes a format field, use it with a sane default (d/m/Y), otherwise every site using the bundle gets your locale assumptions.
• Extension points are narrow by design. You get: template override, renderer decoration, and (rarely) a new widget extending the entity. There is no event system here to hook into — expect to fork if you need behavior changes.
• Debugging recipe: {{ dump(widget) }} in the template (with the debug bundle enabled), then bin/console debug:container | grep -i date to confirm the service wiring, then check the Victoire slot configuration. That sequence resolves nearly every "nothing renders" report.
• Recommendation: do not add this as a dependency. Use it as a 20-minute read of how a minimal CMS widget is structured, then implement the pattern natively in your framework of choice. The idea survives; the code does not.