Foundation6 Bundle Laravel Package

Getting Started

Establish what you're actually installing. frux/foundation6-bundle is a Symfony 2 bundle: a bundle class, a DI extension, a pile of Foundation 6 Sass/JS under Resources/public, and Twig form/ layout templates under Resources/views. Laravel has no bundle registry, no Assetic, and no Symfony Form component, so there is no code path where composer require frux/foundation6-bundle boots anything in a Laravel app. Your first decision is therefore a fork in the road:

1. Legacy Symfony 2/3 app (the intended home): install it and use it as shipped.
2. Laravel app (the common accidental case): treat the repo as reference material — harvest the Sass settings and form markup, then build the equivalent with foundation-sites from npm. Don't try to install it.

Where to look first, in this order:

• composer.json — the PHP and symfony/framework-bundle constraints answer "will this even resolve?" in ten seconds.
• DependencyInjection/ and the bundle class — the closest thing to a service provider; it tells you what config keys exist and whether it registers anything beyond the asset path.
• Resources/views/ — the form theme and layout partials. This is the only part with real transferable value.
• Resources/public/ — compiled CSS/JS versus Sass source. If only compiled CSS is shipped, you cannot theme it without pulling Foundation's sources yourself.
• Resources/config/ — service and routing definitions; usually near-empty for a bundle this thin, which is itself the answer to "does it do more than register two paths?"

Minimal legacy-Symfony setup:

// app/AppKernel.php
$bundles = [ /* ... */ new Frux\Foundation6Bundle\FruxFoundation6Bundle() ];

# app/config/config.yml
twig:
    form_themes: ['@FruxFoundation6/form/foundation_6_layout.html.twig']

Then bin/console assets:install --symlink and clear the cache.

Minimal Laravel equivalent (what you should really do):

npm i foundation-sites motion-ui

// resources/css/app.scss
@use "settings";                       // your copy of the bundle's settings partial
@use "foundation-sites/scss/foundation" with ($global-flexbox: true);
@include foundation-everything;

First use case: get one CRUD screen — a form with inputs, selects, an error state, and a submit button — rendering with Foundation markup. That exercises the form theme, the grid, and the JS initialization in one shot and is a fair proxy for whether the rest is worth doing.

Implementation Patterns

Asset inclusion. The bundle's whole premise is that you reference its public assets instead of copying vendor files. In its native habitat that means an Assetic block in your base layout:

{% stylesheets '@FruxFoundation6Bundle/Resources/public/css/foundation.css' %}
    <link rel="stylesheet" href="{{ asset_url }}">
{% endstylesheets %}

If your app has moved to Encore or Vite, that block is dead code — you must either assets:install the public dir and reference it directly, or import the Sass from node_modules and stop using the bundle's asset path entirely. Pick one; mixing the two is how you end up debugging "why is my override not applying" for an afternoon.

Form theme wiring is the highest-leverage pattern. On Symfony, one entry in twig.form_themes changes every form in the app at once. That's the day-to-day win: no per-feature markup work, no review cycles over input classes. If you're porting to Laravel, replicate the shape, not the file: one anonymous Blade component per control type, plus a wrapper that knows about $errors.

{{-- resources/views/components/form/input.blade.php --}}
@props(['name', 'label' => null, 'type' => 'text'])
<label @class(['is-invalid-label' => $errors->has($name)])>
    {{ $label ?? str($name)->headline() }}
    <input type="{{ $type }}" name="{{ $name }}" value="{{ old($name) }}"
           @class(['is-invalid-input' => $errors->has($name)]) {{ $attributes }}>
    @error($name)<span class="form-error is-visible">{{ $message }}</span>@enderror
</label>

Match the bundle's class names (is-invalid-input, form-error is-visible, help-text) exactly — they carry the Foundation styling, and preserving them keeps your components drop-in compatible with anything else using Foundation markup.

Own the settings partial. Foundation's _settings.scss is the customization surface; the bundle ships one, and depending on its copy verbatim is a trap. Copy it into resources/scss/settings.scss, override the variables you care about ($global-flexbox, $breakpoints, $primary-color, $form-spacing), and import it before Foundation. Then any future replacement of the bundle is a no-op for your design tokens.

JS initialization. Foundation 6 plugins are jQuery-based and opt-in via data- attributes. Initialize deliberately rather than globally, so a broken plugin on one page doesn't take out the rest:

import $ from 'jquery';
import 'foundation-sites';
$(document).foundation();

For Vite specifically, expose jQuery on window first, or Foundation's plugin registry will throw on load. If you're on Foundation 6.7+ with the plugin-API rewrite, use the import { Foundation } from 'foundation-sites' path instead and skip jQuery altogether.

Version pin, then vendor. The package has no maintenance signal, so "frux/foundation6-bundle": "dev-master" is unacceptable. Pin to a tag or commit SHA, or move it into packages/foundation6/ with a Composer path repository so the code sits in your repo and upgrades are a deliberate act.

Integration tip: keep the bundle at the edge. Whatever path you take, the bundle should touch only the asset pipeline and the form theme. The moment it starts owning layout templates, base blocks, or navigation markup, replacing it stops being a one-afternoon job.

Gotchas and Tips

Composer will refuse to resolve on a modern stack. A Symfony 2-era bundle constrains symfony/framework-bundle to ~2.3–2.8 and PHP to 5.x/7.x. --ignore-platform-reqs gets you past the solver and drags EOL Symfony components and unpatched CVEs into your tree — usually surfaced later by composer audit. If resolution fails, that's the package telling you the truth; believe it.

Twig 3 removed the Assetic tags. {% stylesheets %} and {% javascripts %} don't exist unless symfony/assetic-bundle is installed, and that bundle is itself abandoned. If you see "Unknown tag name stylesheets," you know which era the templates were written for.

Compiled-CSS-only kills theming. If Resources/public/css/ contains built CSS with no companion scss/, you cannot change a single Foundation variable through the bundle. The settings mentioned in the description are baked at build time. Confirm the presence of .scss files before assuming customization is available.

Import order errors are silent. Foundation's Sass uses !default, so if your settings partial is imported after foundation, every override is quietly ignored — no build error, just wrong output. Symptom: you change $primary-color and nothing happens. Fix: settings first, always.

Flexbox versus float grid. Foundation 6 ships both. If you expect the XY grid and get float behavior, $global-flexbox wasn't set before the Foundation import. This one produces genuinely confusing layout bugs at tablet breakpoints.

Bundle template overrides moved. On Symfony 3.4+ the override path is templates/bundles/FruxFoundation6Bundle/..., not the old app/Resources/FruxFoundation6Bundle/views/. Overriding the form theme at the wrong path fails silently — you keep getting the bundle version. Verify with bin/console debug:twig | grep foundation.

Asset cache is the default suspect. After installing the bundle, styling that looks half-applied is almost always a stale asset dump. assets:install --symlink && cache:clear resolves most "the CSS didn't load" reports before you start reading the source.

jQuery conflicts. If any part of your app already has jQuery at a different version, Foundation's plugins may bind to the wrong one. Isolate the import or pin jQuery globally rather than letting bundlers hoist two copies.

Laravel form requests don't map to Symfony form themes. On Laravel, $errors, old(), and @error are your data sources; there is no form_row/form_errors pipeline to hook into. Treat the Twig theme as a class-name dictionary and a layout reference, not a porting template.

Debug with the rendered output, not the source. Because the bundle is thin, most problems are integration problems. Inspect the final HTML for the expected is-invalid-input/form-error is-visible classes; their presence or absence tells you instantly whether the theme is wired or whether CSS is missing.

Extension points are few; plan accordingly. Expect at most: config keys for enabling/disabling asset registration, the template override path, and the settings partial. If you need more (say, per-form themes so one form doesn't inherit Foundation markup), you'll be forking. Fork into packages/ under source control rather than patching vendor/ — patched vendor directories survive exactly one composer update.

Budget the exit before you start. The replacement — foundation-sites from npm plus your own Blade or Twig partials — is a known quantity of a day or two. Knowing that up front is what makes adopting a zero-star, zero-dependent wrapper a defensible tactical choice rather than an unexamined liability.