Bootstrap Bundle Laravel Package

Getting Started

Confirm you actually need it. zikula/bootstrap-bundle is a Zikula 2.x-era Symfony bundle whose job is to wire the Bootstrap 3 frontend framework (CSS/JS assets, form themes, Twig helpers/macros) into a Zikula application. It has been archived since 2017, has zero dependents, and is not installed standalone in most setups — it usually arrives transitively with zikula/core 2.x. Before doing anything, check whether it is already present:

composer show zikula/bootstrap-bundle
grep -R "BootstrapBundle" app/config app/AppKernel.php src/ 2>/dev/null

Version constraints are the gate. It targets Symfony 3.x and PHP 5.5–7.1-era code. Do not try to pull it into a Symfony 4+/PHP 8 project; the bundle class, its extension, and the bundled templates will not survive the upgrade. Verify with composer why zikula/bootstrap-bundle and composer outdated.

Registration (only if absent). In a Symfony 3 / Zikula 2 app, add the bundle to the kernel’s registerBundles():

// app/AppKernel.php
$bundles = [
    // ...
    new Zikula\Bundle\BootstrapBundle\ZikulaBootstrapBundle(),
];

Then clear caches (bin/console cache:clear) and confirm the bundle extension is picked up with bin/console debug:container --parameter=bootstrap or by grepping debug:config output.

Where to look first, in order:

1. composer.json — the exact symfony/* and zikula/core constraints define what you can safely combine it with.
2. DependencyInjection/ — the extension class exposes the config tree (asset paths, form theme toggles, version).
3. Resources/views/ — this is where the actual value lives: the Bootstrap form theme(s) and any Twig macros.
4. Resources/public/ — bundled CSS/JS; check whether assets are real files or references to a CDN.

First use case: render a Symfony form with Bootstrap 3 markup instead of the default div-soup. Enable the form theme globally:

# app/config/config.yml
twig:
    form_themes:
        - 'bootstrap_3_layout.html.twig'

or, if the bundle ships its own theme, reference it by bundle path:

twig:
    form_themes:
        - '@ZikulaBootstrap/Form/bootstrap_3_layout.html.twig'

Render the form normally — {{ form_start(form) }}{{ form_widget(form) }}{{ form_end(form) }} — and inspect the HTML output for form-group, control-label, and help-block classes. That is the fastest signal that the bundle is actually active.

Implementation Patterns

Global form theme vs. per-form. Prefer the global twig.form_themes entry so every module form is consistent. For one-off admin forms that must keep the default theme, use the form_theme tag inside the specific template:

{% form_theme form 'ZikulaBootstrapBundle:Form:bootstrap_3_layout.html.twig' %}

Asset inclusion. Zikula 2 templates typically use the core asset helpers rather than raw <link>/<script> tags. Bootstrap CSS/JS should be included once, in your theme’s base layout, not per-module:

{% block stylesheets %}
    {{ parent() }}
    <link rel="stylesheet" href="{{ asset('bundles/zikulabootstrap/css/bootstrap.min.css') }}">
{% endblock %}

{% block javascripts %}
    {{ parent() }}
    <script src="{{ asset('bundles/zikulabootstrap/js/bootstrap.min.js') }}"></script>
{% endblock %}

Note the bundles/<lowercased-bundle-name>/ asset path — that is the Symfony convention and a common source of 404s if you guess the name wrong. Verify the actual directory with ls web/bundles/ after assets:install.

Template override instead of fork. Zikula resolves templates through the theme → module → bundle fallback chain. Rather than patching vendor code (which you will lose on the next composer update), override the specific template in your theme:

src/themes/MyTheme/Resources/ZikulaBootstrapBundle/views/Form/bootstrap_3_layout.html.twig

Then confirm which file won:

bin/console debug:twig --filter=form_widget
bin/console lint:twig src/themes/MyTheme

Module integration pattern. Inside a Zikula module’s templates, lean on Bootstrap grid classes for layout and keep module-specific CSS in the module’s own Resources/public/css/. This keeps the Bootstrap bundle as a pure dependency rather than a dumping ground for styling.

Config-driven asset toggles. If the bundle’s extension exposes options (CDN vs. local, version pinning), set them in app/config/config.yml under the bundle key rather than hard-coding URLs in templates:

zikula_bootstrap:
    use_cdn: false
    version: "3.3.7"

Read the extension class first — do not assume these keys exist; the config tree may be empty or have different names.

Upgrade path when (not if) you outgrow it. The functionality is essentially duplicated by symfony/twig-bridge’s built-in bootstrap_3_layout.html.twig and by Zikula’s own Bootstrap-based theme. Migrating means: drop the bundle from AppKernel, point form_themes at the Twig Bridge theme, and move the bundled CSS/JS into your theme. Test form rendering and any JavaScript-dependent components (dropdowns, modals, tooltips) as a single change set.

Gotchas and Tips

It is archived and unsupported. No security patches, no Symfony 4/5/6 compatibility, no PHP 8 support. Treat it as frozen vendor code in a legacy application. If you are starting anything new, do not adopt it — use a maintained Bootstrap theme or a modern Symfony bundle.

Bootstrap 3 only. The templates and JS assume Bootstrap 3 class names (col-md-*, panel, glyphicon). Dropping Bootstrap 4/5 CSS on top of these templates produces subtly broken forms rather than obvious errors. Check the bundled asset version before assuming.

jQuery is a hard dependency. Bootstrap 3’s JS requires jQuery, loaded before bootstrap.min.js. A common failure is everything rendering fine but dropdowns/modals silently doing nothing — check the browser console for $ is not defined and verify script order in the base layout.

Duplicate form-theme definitions are silent. If both symfony/twig-bridge and this bundle register bootstrap_3_layout.html.twig, whichever is listed later in form_themes wins. Debug by temporarily rendering {{ form_widget(form) }} for a trivial field and diffing the output, or by using an explicit @Bundle/... path to remove ambiguity.

Asset install is a separate step. composer require/update does not populate web/bundles/. Run bin/console assets:install --symlink web (or hard-copy in production) and then bin/console assetic:dump if the project still uses Assetic — a 2017-era Zikula app very likely does.

Cache invalidation after template overrides. Twig caches compiled templates aggressively. After adding or moving an override, run bin/console cache:clear in the correct environment (--env=prod included). Missing this is the number-one cause of “my override isn’t being picked up.”

Kernel/extension naming mismatches on newer PHP. PSR-4 autoloading plus the old getName() convention can throw notices on PHP 7.2+. If the bundle fails to register, check composer.json’s autoload block against the actual namespace of the bundle class — a stale mapping is a frequent cause of a class-not-found during kernel boot.

Extension points are narrow. The realistic customization surface is (a) the config tree in DependencyInjection/Configuration.php, (b) Twig template overrides, and (c) replacing the form theme wholesale. There is no maintained plugin API — do not design an architecture that depends on overriding bundle internals.

Debugging checklist when a form looks wrong:

1. bin/console debug:twig — confirm the theme path resolves.
2. bin/console lint:twig — catch template syntax errors early.
3. Inspect rendered HTML for Bootstrap 3 classes.
4. Check the browser network tab for 404s on bundles/zikulabootstrap/*.
5. Verify cache was cleared in the correct env.

Pin it in composer.lock and document the version. Since nothing will ever be released again, record the exact commit/version you are running so a future maintainer can reproduce the environment.