Bootstrap Bundle Laravel Package

Getting Started

The package is a Symfony bundle wrapping Bootstrap assets and form themes. There is no maintained release line (0 stars, 0 dependents), so treat this as a "read the source before trusting it" dependency.

1. Install (assuming Packagist is still up — if not, add the repo as a VCS source):

   composer require rmzamora/bootstrap-bundle
   

2. Register the bundle. On Symfony 4+/5+ this is usually automatic via Flex; otherwise add it to config/bundles.php:

   Rmzamora\BootstrapBundle\RmzamoraBootstrapBundle::class => ['all' => true],
   

   On legacy Symfony 2/3 you'll have to add it to app/AppKernel.php manually.
3. Configure — create config/packages/rmzamora_bootstrap.yaml (or add to app/config/config.yml on older apps). Check Resources/config/ inside the vendor package for the actual tree name; bundles from this era usually expose rmzamora_bootstrap: as the root key.
4. First use case — the primary value is almost certainly the form theme. Wire it once and every form in the app renders with Bootstrap markup:

   twig:
       form_themes:
           - '@RmzamoraBootstrap/form/bootstrap_3_layout.html.twig'
   

   (Confirm the exact path with find vendor/rmzamora -name '*layout*'.)

Look first at:

• Resources/views/ — the templates you'll actually consume.
• DependencyInjection/Configuration.php — the real config schema.
• composer.json — symfony/* version constraints tell you instantly whether it supports your project.

Implementation Patterns

Global form theming. Register the layout in twig.form_themes so no per-form {% form_theme %} calls are needed. This is the lowest-friction usage and the one most teams actually want.

Per-form overrides. When only admin forms should use Bootstrap and public forms should use a custom design, apply the theme inline:

{% form_theme form '@RmzamoraBootstrap/form/bootstrap_3_layout.html.twig' %}
{{ form_start(form) }}

Base layout inheritance. Most bundles of this vintage ship a base.html.twig that pulls in Bootstrap CSS/JS via Assetic or assets. Either extend it in your app layout or copy the relevant <link>/<script> blocks into your own template. Copying is safer — it decouples you from the bundle's release cadence.

Asset pipeline integration. If you use Webpack Encore, do not rely on the bundle's bundled bootstrap.css. Install Bootstrap through npm and let Encore handle it; use the bundle only for the Twig templates. This is the cleanest split and the one you should default to.

Widget customization. Once the form theme is active, customize individual fields using the standard Bootstrap-friendly options:

$builder->add('active', CheckboxType::class, [
    'label_attr' => ['class' => 'form-check-label'],
    'attr'       => ['class' => 'form-check-input'],
]);

Because the theme supplies the surrounding form-group markup, you generally don't need to touch classes on the form row — just on the widget and label.

Migrating an existing app. Apply the theme project-wide, run the test suite, then grep for any {% form_theme ... custom.html.twig %} overrides and merge the bundle's form_div_layout.html.twig overrides into your custom ones — this is the step that most often breaks subtly (see Gotchas).

Gotchas and Tips

• Abandonment. With zero stars and zero dependents, assume no security patches or Symfony version bumps. Pin the version in composer.json and plan to vendor a fork if it becomes load-bearing. Check composer.json for symfony/symfony or symfony/form constraints — if it caps at ^3.0 or ^4.0, it will not install alongside modern Symfony without a fork.
• Assetic vs Encore. Bundles from this era frequently depend on symfony/assetic-bundle, which is itself abandoned and removed from Symfony 5+. If Assetic appears in composer.json, expect to strip that dependency or bypass the templates entirely and use your own asset pipeline.
• Form theme version mismatch. The templates are written for a specific Bootstrap major version (BS3 vs BS4 have incompatible grid class names: form-group/col-md-* vs form-group/form-control/invalid-feedback). Grep the layout for col-md- vs invalid-feedback to identify which version you're getting, and make sure your front-end matches.
• Silent theme precedence. Symfony applies the last registered form theme with highest priority. If your app already registers a theme in twig.yaml, adding this bundle's theme afterwards may silently shadow parts of your existing one. Verify with {{ form_row(form.name) }} output in the profiler.
• Cache clearing after install. Adding a bundle to bundles.php requires bin/console cache:clear; forgetting this produces confusing "bundle not found" errors from the Twig loader.
• Template path resolution. Bundle templates are referenced as @BundleName/path.html.twig (Symfony 4+) or BundleName:path.html.twig (Symfony 2/3). If you see "Template not found" errors, confirm the bundle's internal folder structure matches the alias you're using — this is a common failure when copying snippets from the README (which often predates the @ syntax).
• Extension points. The clean extension pattern is to copy the form theme into templates/form/, adjust as needed, and register your copy in twig.form_themes instead of the bundle's. This makes upgrades (or abandonment) painless and lets you strip the parts you don't need.
• Debugging. Use bin/console debug:twig to see all resolvable template paths, and the Symfony profiler's Form tab to see which theme rendered a given widget. If nothing renders, check bin/console debug:container --tag=twig.extension — some bundles register their form-theme Twig extensions conditionally on a config flag.
• Config quirks. Old bundles often expose a boolean like enabled: true under the root key; if the root key is missing, the bundle may still register the extension but silently skip the template path. Copy the block verbatim from the bundle's own Resources/config/test/ fixture rather than rewriting it.