Bootstrap Form Bundle Laravel Package

Getting Started

This is a Symfony2-era bundle that ships Twig form themes for Bootstrap markup. Treat it as a theme provider, not a form library — you still build forms with Symfony's Form component and only swap how they render.

Minimal steps:

1. Install (pin versions — see Gotchas):

   composer require vincet/bootstrap-form-bundle:dev-master
   

2. Register in app/AppKernel.php (Symfony 2/3 only):

   new Vincet\BootstrapFormBundle\VincetBootstrapFormBundle(),
   

   Confirm the exact bundle class name from the repo root — vendor/bundle naming is not perfectly consistent in this package.
3. Enable the theme in app/config/config.yml:

   twig:
       form_themes:
           - 'BootstrapFormBundle:Form:bootstrap.html.twig'
   

   Locate the actual theme path by reading Resources/views/Form/ in the bundle — look there first, it is the whole substance of the package.
4. First use case: take an existing $form = $this->createForm(...) in a controller and change nothing; only the template changes. Render it as a horizontal form:

   {{ form_start(form, {'attr': {'class': 'form-horizontal'}}) }}
       {{ form_widget(form) }}
       {{ form_end(form) }}
   

If Resources/views/Form/ is empty or minimal, the bundle is likely just glue over Symfony's built-in bootstrap_3_layout.html.twig — in that case skip the dependency entirely.

Implementation Patterns

Global theme vs. per-form theme. Set it once in config.yml for consistency, or scope it:

{% form_theme form 'BootstrapFormBundle:Form:bootstrap.html.twig' %}

Use the per-form form when only admin screens are Bootstrap-styled.

Horizontal forms. The main value of a bundle like this is label/control column widths. Pass layout options through standard Symfony form options and let the theme pick them up:

$builder->add('email', 'email', [
    'label_attr'  => ['class' => 'col-sm-2 control-label'],
    'attr'        => ['class' => 'form-control'],
]);

Keep attr classes in your form types (or a form type extension) rather than duplicating them in Twig.

Compose with Symfony's own theme. Extend the bundle's theme so you inherit its blocks and override only what you need:

{# app/Resources/views/Form/bootstrap_custom.html.twig #}
{% extends 'BootstrapFormBundle:Form:bootstrap.html.twig' %}

{% block form_group_class %}
    {{ parent() }}{% if errors|length %} has-error{% endif %}
{% endblock %}

This is the primary extension point — block overrides, not PHP.

Input groups and addons. Wrap the widget in Twig at call sites rather than expecting the form type to do it:

<div class="input-group">
    <span class="input-group-addon">@</span>
    {{ form_widget(form.username, {'attr': {'class': 'form-control'}}) }}
</div>

Buttons and actions. Render submit buttons with Bootstrap classes explicitly:

{{ form_widget(form.save, {'attr': {'class': 'btn btn-primary'}}) }}

Do not rely on the theme to invent button styling.

Reusable form types. Define an abstract BootstrapFormType in your app that applies form-control via a FormTypeExtension, and let the bundle's theme handle only structure. That keeps the theme replaceable.

Gotchas and Tips

• This is effectively abandoned. Symfony2/Twig 1.x idioms, no commits for years, 0 dependents, 8 stars. It will not run on Symfony 4+ or Twig 2/3 without porting. Before adopting, diff its theme against Symfony's native bootstrap_3_layout.html.twig — you can usually get the same result with form_themes: ['bootstrap_3_layout.html.twig'] and zero dependencies.
• Version constraints will fight you. dev-master against a modern composer.json typically requires --ignore-platform-reqs or explicit pins. If you must use it, fork it into your VCS and set a stable branch alias.
• Bootstrap 2 vs 3 markup. The bundle predates the BS2→BS3 break (controls/control-group vs form-group). Mismatched CSS produces silently wrong layouts rather than errors — check the generated HTML against your actual Bootstrap version.
• Theme precedence. form_themes entries are tried in order; the first one defining a block wins. A bundle-registered theme can be shadowed by an app-level theme or vice versa. When a block "isn't applying", dump the effective theme list and check ordering before editing anything.
• Cache. Twig caches compiled templates. After editing a theme or overriding a block, clear app/cache/{env} (or var/cache) — twig.debug does not always invalidate on template changes from vendor paths.
• Bundle registration order matters only if it overrides core form resources; if you see Unknown "form_group_class" block, the bundle is not registered or the theme path is wrong.
• Assets are not included. No jQuery, no Bootstrap CSS. You own the front-end stack; the bundle only emits classes.
• Debugging rendering: use {{ dump(form) }} with the profiler and {% debug %} on the Twig side; inspect which block is being called by temporarily adding a marker {# blockname #} to candidate blocks.
• Extension points, in preference order: (1) override Twig blocks in an app theme that extends the bundle theme; (2) register a FormTypeExtension to inject classes; (3) subclass the bundle's form types if it ships any. Avoid editing the vendor directory — fork if you need PHP-level changes, because upstream fixes are not coming.