Flob Foundation Bundle Laravel Package

Getting Started

flob-foundation-bundle is a Symfony 2.x era bundle that wires Zurb Foundation (5.x generation) into a Symfony app: a Foundation form theme, Twig extensions that emit Foundation component markup, a few services, and console commands for asset installation. It is archived and last released in 2016, so treat it as a reference implementation you may need to fork rather than a dependency you can pull into a current project.

Minimal steps to evaluate it:

1. Install into a Symfony 2.8 sandbox first. Do not try it on Symfony 3+/4+ before checking compatibility — the bundle predates Twig 2 (Twig_Extension, getName()), and the container/extension APIs it targets were removed afterwards. A throwaway symfony/framework-standard-edition:~2.8 VM or Docker image is the fastest way to see what it actually does.
2. Read the README and the tree in this order: Resources/views/ (the form theme + component partials), Twig/ (the extension classes — this is the real API surface), DependencyInjection/Configuration.php (the exact flob_foundation: keys), Command/ (the asset commands), then Resources/public/ (which Foundation version is vendored).
3. Register the bundle in app/AppKernel.php and import its routing only if the README says it exposes routes (most of these bundles are templates + Twig only).
4. Confirm the config namespace with bin/console config:dump-reference flob_foundation and the Twig callables with bin/console debug:twig | grep -i foundation. Do this before writing any markup — function names in bundles like this are not guessable (foundation_tabs vs flob_tabs etc.).
5. First use case: the form theme. Point twig.form_themes (or a single {% form_theme %}) at the bundle's layout and render one form with a text field, a checkbox, a radio group, and an expanded choice. If the output carries Foundation classes (row, columns, switch, callout, help-text), you know the version alignment is right. Everything else in the bundle is a convenience on top of that.

Implementation Patterns

Form theme as the primary integration point. The highest-value piece day-to-day is the Foundation form theme. Use it globally when the whole app is Foundation:

# app/config/config.yml (Symfony 2.x)
twig:
    form_themes:
        - 'FlobFoundationBundle:Form:foundation_layout.html.twig'

…and per-form when you're migrating incrementally:

{% form_theme form 'FlobFoundationBundle:Form:foundation_layout.html.twig' %}

Extend rather than copy: {% use %} the bundle theme into your own app/Resources/views/form/foundation_custom.html.twig, then override only checkbox_row / radio_row (for switch classes) or form_errors (for callout alert + data-abide attributes). This keeps upstream block fixes available — relevant even for an archived bundle, since you'll be patching it locally.

Twig extensions for components. The extension layer is where you should spend your reading time. Expect helpers that render a full Foundation widget (tabs, accordion, alerts with dismiss buttons, dropdown/drilldown menus, breadcrumbs, pagination) including the data-* hooks and ARIA attributes that Foundation's JS expects. Prefer these over hand-written markup for anything Foundation's JS auto-initializes — hand-rolled tabs are the classic source of "tabs work on page load but not after an AJAX render" bugs. Wrap them in your own small macros if you need consistent defaults across the app.

Menus (if KnpMenuBundle is wired in). Foundation bundles of this era often ship a KnpMenu renderer so your navbar markup stays consistent with the theme. If present, prefer it over a custom knp_menu.html.twig — the is-dropdown-submenu-parent / data-submenu-toggle attributes are easy to get wrong manually.

Services. Treat the bundle's services as thin adapters (asset paths, form/theme helpers). Inject them into your own services/controllers rather than calling $container->get(); and drive behavior from flob_foundation: config keys, not hard-coded paths, so a fork or a later Foundation upgrade doesn't require a grep across the codebase.

Asset pipeline. The bundle vendors Foundation assets for Assetic/assets:install-style publishing. Two patterns:

• Era-appropriate: enable the bundle's asset config, run bin/console assets:install --symlink web/, and reference the published paths. Wire the install command into composer.json's post-install-cmd/post-update-cmd and into your deploy script so it never drifts.
• Modern replacement: skip the bundle's assets entirely, npm install foundation-sites, and load Foundation through Webpack Encore. Keep only the form theme and Twig extensions (vendored into your app). This is the realistic path for any non-Symfony-2 project — the bundle's value is the markup generation, not the CSS delivery.

JS initialization. Always call $(document).foundation() (or the Foundation 6 equivalent) after your bundle-generated markup is in the DOM, and re-init the affected plugins after partial/AJAX renders. Bundle-rendered tabs, accordions, and dropdowns are inert until Foundation's JS sees them.

Gotchas and Tips

• Archived means frozen compatibility. Twig 2+ removed Twig_Extension and the mandatory getName(); Symfony 3+ changed bundle/container conventions. Install failures or fatal signature errors are the expected outcome outside Symfony 2.x. If you must use it, fork it and do a mechanical port (extend AbstractExtension / AbstractType, drop getName()), or extract just the templates — MIT license makes this clean.
• Foundation 5 vs 6 markup drift. The bundle's classes were written against Foundation 5 (small-12 columns, switch, panel). Loading Foundation 6+ CSS against that markup produces subtly broken layouts (grid direction, callout vs panel, menu alignment). Verify the vendored version in Resources/public/ before assuming it matches your package.json.
• Multiple form themes: last one wins for conflicting blocks. Register the bundle theme before your overrides in twig.form_themes, and always override via {% use %} / {{ parent() }} / {{ block('...') }} rather than copy-pasting whole blocks — copied blocks silently drop attr merging and required/aria-* handling.
• jQuery ordering. Foundation's JS depends on jQuery, and several bundle-era templates assume it's loaded in <head> before Foundation. A defer-ed jQuery plus an eager $(document).foundation() in an inline script is the usual "nothing initializes" failure.
• Config/cache quirks. After changing flob_foundation: keys or twig.form_themes, clear the cache (bin/console cache:clear) — form theme changes are especially easy to misdiagnose because the old compiled template is served until the cache is cleared.
• Discover the real API before coding. debug:twig (functions/filters), config:dump-reference flob_foundation (all keys), and bin/console list flob (command names) give you the ground truth in seconds. Guessing helper names in a 47-star 2016 bundle wastes more time than reading Twig/ directly.
• Debugging rendered markup: use {% dump %}/dump() on the form view to inspect which block is actually being hit, and twig:lint on your overrides — a bad block name in a Symfony 2 form theme fails silently by falling back to the base theme rather than erroring.
• Extension points to rely on: bundle template override path (app/Resources/FlobFoundationBundle/views/...), {% use %}-based form theme inheritance, and your own Twig macros wrapping the bundle's component helpers. Avoid patching vendor/ directly — you'll lose it on the next composer update, and there won't be a next release to fix it.
• Strategic tip: for a new build, budget a half-day to read the bundle and reimplement the form theme + component macros in your own templates/form/ and templates/components/. You keep the tested markup ideas, drop the Symfony-2 coupling, and avoid pinning your project to an abandoned dependency with zero dependents.