Date Picker Bundle Laravel Package

Getting Started

This bundle targets Symfony 2.x + SonataAdminBundle, not Laravel — there is no Laravel service provider, facade, or config/app.php hook. If you are working in a Laravel codebase you cannot install this via composer require without pulling in a full Symfony2 stack; treat the notes below as integration guidance for a Symfony2/Sonata context or as a reference for what you would need to replicate with a Laravel field (e.g. bootstrap-datepicker wired through a custom Blade component + FormRequest validation).

Minimal integration steps in its native environment:

1. Require the package:

   composer require stnw/date-picker-bundle
   

2. Register the bundle in app/AppKernel.php:

   new Stnw\DatePickerBundle\StnwDatePickerBundle(),
   

3. Publish the bundle's JS/CSS assets so the picker widget actually renders:

   php app/console assets:install web --symlink
   

4. Look first at Resources/config/services.xml (form-type registrations) and Form/Type/ for the two field types the bundle advertises: a date picker and a date-time picker.
5. First use case — replace Sonata Admin's default date widget on an entity field:

   protected function configureFormFields(FormMapper $formMapper)
   {
       $formMapper
           ->add('publishedAt', 'stnw_date_picker', [
               'format' => 'dd/MM/yyyy',
               'widget' => 'single_text',
           ]);
   }
   

Because the repository has zero stars and zero dependents, there is very little community documentation — the Form/Type/*.php files are your authoritative source for supported options.

Implementation Patterns

Plain Symfony form usage. The bundle exposes form types that subclass Symfony's DateType/DateTimeType and swap the rendered widget. In a normal form builder:

$builder->add('dueDate', 'stnw_date_picker', [
    'input'  => 'datetime',
    'format' => 'yyyy-MM-dd',
]);

Sonata Admin form mapper. Most real usage will be inside Admin classes. Keep the option array consistent with the underlying jQuery/bootstrap datepicker format tokens, not PHP's date() tokens — this is the single biggest source of bugs (see Gotchas).

Reusing the widget outside a form. If you need the picker on a non-Symfony page, you can render the bundle's Twig block directly ({% block stnw_date_picker_widget %}) as long as assets are published, then instantiate the JS plugin yourself with the same format string.

Datetime pairing. For the DateTime variant, bind a date picker plus a separate time selector rather than a combined widget — this keeps the database datetime value unambiguous and lets you apply a single timezone conversion in a form event listener:

$builder->addEventListener(FormEvents::PRE_SUBMIT, function (FormEvent $e) {
    $data = $e->getData();
    if (!empty($data['startsAt']['date'])) {
        $data['startsAt'] = $data['startsAt']['date'] . ' ' . ($data['startsAt']['time'] ?? '00:00');
        $e->setData($data);
    }
});

Reusable admin pattern. Wrap the type name and default format in a small base Admin class so every admin in the project shares the same date format and locale — changing the format in one place then propagates.

Migration tip if you move off the bundle. Both field types are thin wrappers. If you later standardize on sonata_type_date_picker (which Sonata ships natively in newer versions) or on Symfony's own DateType with a single_text widget, the data contract (\DateTime bound to the model) is unchanged — only the widget class and JS assets differ.

Gotchas and Tips

• Abandoned stack. This bundle predates Symfony 3 and was written for Symfony 2.x, which is end-of-life. Sonata Admin versions after ~3.x reorganised their date pickers, so pinning this bundle alongside a modern Sonata install will almost certainly produce form-type registration conflicts (The form type "stnw_date_picker" is not registered). Verify Symfony and Sonata versions before committing.
• Zero community signal. With 0 stars and 0 dependents there is no upstream support, no security patching, and no issue tracker activity to lean on. Budget time to fork and maintain it yourself, or to port the two form types into your own bundle.
• Format token mismatch. PHP's date('d/m/Y') and the JS datepicker's dd/mm/yyyy are not interchangeable. The format option is consumed by the JavaScript layer, while the model transformer uses PHP/ICU patterns. A mismatch silently produces inverted day/month values for ambiguous dates (e.g. 03/04/2024) — test with a day > 12 in both positions.
• Asset publishing is mandatory. Forgetting assets:install produces an unstyled native <input type="date"> or a plain text field. If the field "works" but has no calendar popup, this is the cause.
• Timezone drift. The picker runs in the browser's local timezone while storage is usually UTC. Apply conversion in a PRE_SUBMIT/POST_SUBMIT listener, not in the Twig template.
• widget option inheritance. Because the types extend core Symfony types, options like widget, input, and with_seconds are inherited — but some are silently ignored by the JS layer. Trust the type class over the docs.
• Locale. Bootstrap/jQuery datepickers need an explicit locale file loaded. The bundle does not ship every locale — load the extra datepicker.<locale>.js yourself or you get English month names in a non-English admin.
• Debugging tip. When a submitted date fails validation with "This value is not valid," dump $form->get('field')->getErrors(true) and the raw $_POST value — the transformer usually fails because the incoming string does not match the format option exactly, not because the date is wrong.
• Extension point. If you need to support Symfony 3+/4+ or a newer Sonata, the least invasive route is to copy Form/Type/DatePickerType.php into your own bundle, update the getParent() / service tag for the newer form-type registration (form.type tag with alias), and keep only the options you actually use.