Scdatetimepicker Bundle Laravel Package

Getting Started

Minimal install path for a Symfony app (this is not a Laravel package; in Laravel you would use Carbon/Blade plus a JS picker instead):

1. Require the bundle via Composer. As of v4.0.2, pin the major line and verify the exact tag in composer.json:

   composer require mwsimple/scdatetimepicker-bundle:^4.0
   

2. Register it in config/bundles.php (Symfony Flex may do this automatically for older versions; the bundle predates Flex conventions, so verify):

   return [
       // ...
       MWSimple\SCDatetimepickerBundle\SCDatetimepickerBundle::class => ['all' => true],
   ];
   

3. Install the front-end assets. This bundle wraps the classic Bootstrap 3 / Eonasdan bootstrap-datetimepicker JavaScript and expects jQuery + Moment.js to already be present on the page. Publish or copy the bundle's Resources/public assets into your public/ directory (or run bin/console assets:install), then include them in your base layout:

   <link rel="stylesheet" href="{{ asset('bundles/scdatetimepicker/css/bootstrap-datetimepicker.min.css') }}">
   <script src="{{ asset('bundles/scdatetimepicker/js/bootstrap-datetimepicker.min.js') }}"></script>
   

4. Where to look first: open Form/Type/ for the provided field type(s), Resources/views/ for the Twig widget templates, and DependencyInjection/ for the (usually minimal) configuration tree. The README is short; the source is the documentation.

First use case — drop the type into an existing Symfony form and render it with the bundle's form theme:

use MWSimple\SCDatetimepickerBundle\Form\Type\DatetimepickerType;

$builder->add('publishedAt', DatetimepickerType::class, [
    'label' => 'Publish date',
    'widget' => 'single_text',
    'format' => 'yyyy-MM-dd HH:mm',
]);

Then in the template, render the field and let the bundled widget initialize the picker.

Implementation Patterns

Treat it as a DateTimeType with a JS layer on top. The bundle's field type extends Symfony's core datetime type and only changes rendering/attributes. That means all the standard DateTimeType options (widget, format, input, with_minutes, with_seconds, html5, model_timezone, view_timezone) still apply. Constrain the field with normal validators (NotBlank, DateTime, custom ranges) — the picker UI is not your validation layer.

Option passing to the JS widget. Typical pattern is to pass picker configuration through the form type's attr array so the widget template emits it as data-* attributes:

$builder->add('startsAt', DatetimepickerType::class, [
    'attr' => [
        'data-format'       => 'YYYY-MM-DD HH:mm',
        'data-side-by-side' => true,
        'data-min-date'     => '2025-01-01',
        'data-locale'       => 'de',
    ],
]);

Check the bundle's template to confirm the exact attribute names it reads — this is the single most important thing to verify before wiring it across a project.

Form theme registration. Register the bundle's theme globally in config/packages/twig.yaml:

twig:
    form_themes:
        - '@SCDatetimepicker/Form/fields.html.twig'

If you only want it on specific forms, use {% form_theme form '@SCDatetimepicker/...' %} in the template instead. Global registration is easiest but is the one line that silently breaks if you rename or override the template path.

Date range fields. For "from/to" pairs, instantiate two picker fields and link them client-side with your own small jQuery snippet (dp.change handler setting minDate/maxDate on the counterpart). The bundle does not provide linked-range logic, so this is app-side code either way.

Integrating with an existing asset pipeline. If you use Webpack Encore, prefer importing bootstrap-datetimepicker from npm and only using this bundle for the form type and Twig widget. Mixing Encore-managed jQuery with a global jQuery loaded from Resources/public is a common source of "picker is not a function" errors.

Localization. Pass the Symfony locale into the widget and load the matching Moment locale file (moment/locale/de.js etc.). The bundle does not auto-load Moment locales; do it in your layout based on app.request.locale.

Upgrade note for v4.0.2. This release includes a jquery_layout view fix (PR #13) that affects parent views using the bundle, plus dependency bumps for symfony/http-foundation to 7.1.7 and twig/twig to 3.14.1. If you extend or override the bundle's jQuery layout partial, re-test every form that uses it after upgrading.

Gotchas and Tips

• v4.0.2 is a maintenance release, not a feature release. The meaningful change is the jquery_layout view fix, which can affect any parent view/template that includes the bundle's jQuery layout. The rest is Dependabot noise. Upgrade if you are already on v4.x and use that layout; otherwise do not expect new picker features.
• This is a small, low-traffic package. Pin an exact version ("mwsimple/scdatetimepicker-bundle": "4.0.2" or ^4.0) and be prepared to fork. Do not assume security fixes will land; review the JS it ships if your app is exposed publicly.
• PHP format vs. Moment format strings. Symfony uses ICU/PHP date formats (yyyy-MM-dd HH:mm) in format, while the picker uses Moment tokens (YYYY-MM-DD HH:mm). The bundle does not translate between them reliably — you often have to keep both in sync manually (format for PHP, data-format for the picker). Mismatches produce "field shows one date, saves another" bugs.
• Twig/Symfony compatibility is now a v4.x concern. v4.0.2 bumps twig/twig to 3.14.1 and symfony/http-foundation to 7.1.7. Verify the bundle's composer constraints against your app before upgrading. The "Twig 3" compatibility story is true for the v4 line; do not assume the same for older tags.
• Timezone drift. The picker is browser-local; Symfony's model_timezone may be UTC. Always set model_timezone/view_timezone explicitly on the form field and confirm what is stored vs. displayed. This is the #1 source of off-by-hours bugs with any datetime picker.
• Bootstrap version lock-in. The bundled JS is for Bootstrap 3. If your app is on Bootstrap 4/5, the picker styling and popup positioning will misbehave. Either scope the CSS to a wrapper, or switch the JS to Tempus Dominus (the successor) while keeping this bundle only for the form type.
• Asset publishing is not automatic. assets:install must be re-run after upgrades, and in containerized deploys the bundle's Resources/public files must be copied into the image build step — a classic "works locally, 404 in prod" failure. This is especially relevant after a v4.0.2 upgrade if the view fix changes asset assumptions.
• Debugging the widget: open the rendered HTML and check the data-* attributes and the onload init script. If the picker doesn't appear, check in this order: jQuery loaded once and before the plugin, Moment loaded, plugin JS loaded, and no Encore/global jQuery duplication. console.log(typeof $.fn.datetimepicker) in the browser is the fastest diagnostic.
• Extension points: override the bundle's Twig template from your own templates/bundles/SCDatetimepickerBundle/ directory (standard Symfony bundle override resolution), or subclass the form type and register it as a service to add your own defaults. Both are low-friction; there is no service-level configuration to speak of.
• When to skip it entirely. If you are starting a new Symfony project, using DateTimeType with HTML5 datetime-local input plus a modern JS picker (Tempus Dominus, Flatpickr, or a Stimulus controller) is less coupled, easier to upgrade, and avoids carrying an unmaintained Bootstrap 3 asset dependency. This bundle earns its place only in legacy Bootstrap 3 / Twig-upgrade contexts, and v4.0.2 does not change that.