Datetimepicker Bundle Laravel Package

Getting Started

Before you composer require webridge/datetimepicker-bundle, understand what you are installing: this is a Symfony bundle, not a Laravel package. There is no service provider, no facade, no config/datetimepicker.php. The we-bridge/DatetimepickerBundle wraps a client-side datetime picker into a Symfony FormType (DateTimePickerType / DatePickerType), registering Twig form themes and an asset include. If you are in a Laravel codebase, the package will not autoload into your app in any usable way — the classes extend Symfony\Component\Form\AbstractType and register through Bundle/DependencyInjection conventions.

Minimal steps if you are in Symfony:

1. composer require webridge/datetimepicker-bundle (last tagged release 2015-02-11, so pin it and expect to resolve old symfony/form constraints).
2. Register Webridge\DatetimepickerBundle\WebridgeDatetimepickerBundle in app/AppKernel.php (Symfony 2/3 era) or config/bundles.php (newer, if it happens to resolve).
3. Confirm the bundle's assets (JS/CSS for the picker) are published/served — check Resources/public and the bundle's Twig form theme block.
4. Use DateTimePickerType in a form and render it; the picker initializes from the form theme's JS.

First use case: a form field where users need to pick a date/time with a calendar widget instead of free-typing — e.g. an "event starts at" field — using the bundle's provided form type rather than hand-rolling <input type="datetime-local"> plus JS.

For Laravel developers specifically: treat this repo as reference material, not a dependency. The valuable part is the small amount of glue between the JS picker and the form type — read Form/Type/DateTimePickerType.php and the Twig theme to see the option names and widget config it exposes, then reproduce that with a Blade component + a modern picker (Flatpickr, Tempus Dominus, or native datetime-local). You will save more time than trying to bridge Symfony Forms into Laravel.

Implementation Patterns

The bundle is thin, so patterns revolve around the form type rather than the bundle itself.

• Type-based usage (primary pattern). Add DateTimePickerType::class to a Symfony form builder. Pass options through the 'picker_options' (or similarly named array in the type) so JS-level config — format, min/max date, locale, time stepping — flows from PHP into the widget. This is the intended integration: keep configuration in the form class, not scattered in templates.
• Form theme override. The bundle ships a Twig block that renders the wrapping markup and the initialization script. Override that block in templates/form/datetimepicker.html.twig (or your app's form theme) to adjust markup, add classes, or swap the JS bootstrap — this is the sanctioned extension point.
• Reusable field preset. For repeated needs (e.g. "published at", "starts at", "ends at"), subclass or wrap the provided type into a project-specific App\...\PublishedAtType that sets sensible defaults, so every form gets identical picker behavior and formatting.
• Validation belongs outside the picker. The widget only affects input UX; keep constraints (NotBlank, DateTime, GreaterThan) on the entity/DTO. The type should map to a DateTime PHP value — verify it doesn't silently coerce.
• Asset delivery. Include the bundle's JS/CSS once in your base layout (or via Assetic/Webpack depending on Symfony generation). If you're on a newer asset pipeline, copy Resources/public contents into your pipeline and stop relying on the bundle's asset helper.
• Extraction to Laravel. If you only want the behavior: a Blade component wrapping a hidden text input, a JSON-encoded options attribute, and a small JS initializer mirroring the bundle's theme script. This is a ~30-line port and avoids the dependency entirely.

Gotchas and Tips

• It is a Symfony bundle — this is the headline gotcha. Do not plan a Laravel integration around it. No providers entry, no published config, no Artisan commands, no Laravel service container bindings.
• Age. Last release 2015-02-11, zero stars, zero dependents. Expect Composer to complain about symfony/form, symfony/framework-bundle, and PHP constraints. You will likely need --ignore-platform-reqs, symfony/phpunit-bridge style conflict resolution, or a fork. Pin to a commit and vendor it via a path repository if you must use it.
• Zero support surface. No issues, no dependents, no recent commits mean you are the maintainer. Budget time to read the source — it is small, which helps, but there is no community to lean on for a version-compat fix.
• JS dependency is implicit. The bundle's theme references a datetimepicker library that is not clearly vendored. Check Resources/public and the Twig theme for the expected global ($('#id').datetimepicker(...) or similar). If the referenced plugin version is ancient, you will hit jQuery/Bootstrap compatibility issues. Consider swapping the JS but keeping the PHP type as a thin adapter.
• Locale/format mismatches. Server-side DateTime parsing versus the client-side format string is the most common bug class: a picker set to MM/DD/YYYY feeding a PHP format expecting d/m/Y produces silent wrong dates or validation failures. Drive both from one config value and test the round trip (submit, hydrate entity, re-render).
• Timezone handling is not solved for you. The type maps a naive string to DateTime; if you store UTC, convert explicitly in the form PRE_SUBMIT/POST_SUBMIT or in a DTO transformer. Do not assume the picker sends timezone info.
• Form theme registration is easy to miss. If the widget renders as a plain text input with no calendar, the form theme block was not loaded — register it in twig.form_themes or {% form_theme form 'bundle:Form:datetimepicker.html.twig' %}.
• Extension points are limited but real. Overriding the type (subclass), overriding the Twig form theme block, and swapping the JS initializer are the three legitimate hooks. Anything deeper (custom rendering, multi-input ranges) means copying the type into your app and evolving it there.
• Decision tip. If you are evaluating this for a Laravel app, the correct outcome is almost always: skim the PHP type for option names, skim the Twig theme for the JS call, then build a Blade + Flatpickr/Tempus Dominus component and skip the dependency. Reserve actual use for a maintenance Symfony 2/3 project already on the picker.