Daisyui Form Bundle Laravel Package

Getting Started

This is a very low-adoption package (0 stars, 0 dependents), so treat the README as a starting hypothesis rather than documentation. Budget 30 minutes to read the bundle source before wiring it into anything real.

1. Install and register

composer require islesurlasorguetourisme/daisyui-form-bundle

There is almost certainly no Flex recipe, so check config/bundles.php. If the bundle isn't there, add it manually (adjust the class name to whatever the repo's *Bundle.php declares):

return [
    // ...
    IslesUrlAsOrguetourisme\DaisyUiFormBundle\DaisyUiFormBundle::class => ['all' => true],
];

If Composer refuses because there's no stable tag, pin dev-main and set "minimum-stability": "dev" with "prefer-stable": true in composer.json.

2. Make sure DaisyUI is actually loaded

The bundle only emits class names; it does not ship CSS. In a Tailwind v4 setup:

@import "tailwindcss";
@plugin "daisyui";

In Tailwind v3, plugins: [require("daisyui")] in tailwind.config.js. Confirm the DaisyUI major version — v5 removed *-bordered variants that older Symfony themes rely on (see Gotchas).

3. Register the form theme globally

# config/packages/twig.yaml
twig:
    form_themes:
        - '@DaisyUiForm/form/daisyui_layout.html.twig'

Verify the actual path by listing the bundle's templates/ directory — the @BundleName/form/... convention is likely but not guaranteed.

4. First use case

Start with one simple auto-generated form, not your whole app: a contact or registration form rendered with {{ form_start(form) }} {{ form_row(form.email) }} {{ form_end(form) }}. That exercises form_row, form_label, form_widget, form_errors, and form_help in one shot, which is where 90% of theme bugs live.

Where to look first

• templates/form/daisyui_layout.html.twig — this is the package. Everything else is plumbing.
• DependencyInjection/ — confirms whether there's config to set the default theme/version.
• README example output — compare against what your install actually renders.

Implementation Patterns

Global theme, per-field escape hatch

Set the theme once in twig.yaml, then override individual widgets where Symfony's generated markup fights DaisyUI:

{{ form_row(form.amount, {
    attr: { class: 'input input-bordered w-full' },
    row_attr: { class: 'form-control w-full' }
}) }}

Use row_attr for the wrapper (DaisyUI form-control + label structure) and attr for the <input> itself. These are different variables in Symfony's form_row block and mixing them up is the #1 source of "my classes do nothing."

Project-local override theme (recommended)

Don't fork the bundle. Create templates/form/daisyui_app.html.twig:

{% use '@DaisyUiForm/form/daisyui_layout.html.twig' %}

{% block checkbox_row %}
    {# DaisyUI toggle instead of a bare checkbox #}
    <div class="form-control">
        <label class="label cursor-pointer justify-start gap-3">
            {{ form_widget(form, { attr: { class: 'toggle toggle-primary' } }) }}
            <span class="label-text">{{ form.vars.label|trans }}</span>
        </label>
        {{ form_errors(form) }}
        {{ form_help(form) }}
    </div>
{% endblock %}

Register daisyui_app.html.twig before the bundle theme in form_themes — the first theme that defines a block wins, with Symfony's built-in form_div_layout.html.twig appended last as fallback.

Per-form theming for legacy pages

For one-off forms in an app that still uses Bootstrap elsewhere:

{% form_theme form 'form/daisyui_app.html.twig' %}

This is the safest migration path: adopt the theme form-by-form, keep the global config untouched until coverage is proven.

Field-type coverage checklist

Auto-generated forms hit more widget types than you think. Verify each explicitly, because themes usually cover text/textarea/choice and silently skip the rest:

• TextType, EmailType, PasswordType → input input-bordered
• TextareaType → textarea textarea-bordered
• ChoiceType collapsed → select select-bordered
• ChoiceType expanded → radio / checkbox inside a fieldset
• CheckboxType → checkbox or toggle
• FileType → file-input file-input-bordered
• MoneyType/NumberType → input with text-right
• CollectionType → data-prototype must survive intact for the JS add/remove logic
• HiddenType → must not get input input-bordered; override hidden_widget to render a bare <input type="hidden">
• Submit button → btn btn-primary, usually set via attr on $builder->add('save', SubmitType::class, ['attr' => ['class' => 'btn btn-primary']])

Buttons and actions

The theme can't know your intent, so keep button styling in the form type, not the theme. That keeps the theme reusable and makes A/B changes trivial without touching vendor code.

With LiveComponents / Turbo

The theme is pure Twig, so it re-renders correctly inside #[LiveProp] form objects — but remember form_errors only appears after a validation round-trip. Test the re-rendered state, not just first paint; that's where missing form_errors blocks in a custom theme show up.

Tailwind content scanning — do this or your styles vanish in production

Tailwind purges any class it can't find in a scanned file. Classes living in vendor/ Twig templates will be stripped in a production build:

// tailwind.config.js
content: [
  './templates/**/*.twig',
  './vendor/islesurlasorguetourisme/daisyui-form-bundle/templates/**/*.twig',
]

For Tailwind v4, @source "../../vendor/islesurlasorguetourisme/daisyui-form-bundle/templates"; in your CSS entrypoint. This works in dev (JIT sees the rendered HTML) and breaks in prod — a classic "looks fine locally" trap.

Gotchas and Tips

Vendor lock-in is the biggest risk. With 0 stars and 0 dependents, assume the package may never be updated. The bundle is essentially one Twig file. The pragmatic move on day two: copy daisyui_layout.html.twig into templates/form/, register it, and composer remove the dependency. You lose nothing and gain full control over every block. Do this before you build anything on top of it.

DaisyUI version drift is the most likely breakage. DaisyUI v5 dropped input-bordered, select-bordered, textarea-bordered, and btn-* semantics changed. A theme written against v4 will render unstyled-but-not-broken inputs on v5. Check daisyui in package.json and grep the bundle's Twig for -bordered before choosing a version.

Duplicate class attributes. Symfony's widget_attributes block emits class="{{ attr.class }}" if set. If the theme hardcodes class="input input-bordered" and calls widget_attributes, you get two class attributes and the browser honors only the first. The correct pattern in a theme block is:

{% set attr = attr|merge({ class: (attr.class|default('') ~ ' input input-bordered')|trim }) %}

If the bundle's file doesn't do this, that's your first patch (or your reason to copy it locally).

form_end renders leftovers. {{ form_end(form) }} outputs any fields not yet rendered, including _token. Without a hidden_widget override those hidden inputs inherit input styling and can produce stray visible boxes or layout gaps. Render {{ form_rest(form) }} explicitly, or confirm the theme handles hidden fields.

Expanded choice groups need fieldset/legend. Symfony renders expanded ChoiceType as a flat list of labels. DaisyUI expects them grouped. Override choice_widget_expanded early — retrofitting it after you have 20 forms is unpleasant.

Label/for/id alignment. DaisyUI's label wrapper pattern (label wrapping the input) conflicts with Symfony's sibling-label-plus-for output. If you switch to wrapping labels for the styling, make sure id and for still match and keep aria-describedby pointing at form_help/form_errors output. This is an accessibility regression that's easy to miss and hard to un-ship.

Error and help text styling is usually incomplete. Check that form_errors gets text-error / label-text-alt and form_help gets label-text-alt. Default Symfony output is a bare <ul> of <li> elements with no classes — visually invisible in a DaisyUI layout.

Theme precedence surprises. With multiple entries in twig.form_themes, override direction is order-sensitive and easy to get backwards. Verify empirically: add a {% block form_row %}<div data-test="override">… to your app theme and confirm it wins. Don't rely on memory.

Collection prototypes. If your add/remove JS clones data-prototype HTML, a theme change to collection_widget can break the selectors silently. Keep prototype markup stable and covered by at least one functional test.

Testing after every Symfony minor. Block names are stable (form_row, widget_attributes, choice_widget_*), but signature/var changes happen. Since the bundle has no test suite of its own, your app's tests are the only safety net. A cheap guard: a functional test that GETs each form page and asserts 200 plus a couple of expected classes.

Extension points. If the bundle exposes a Configuration class, check for default_theme / daisyui_version toggles before hand-editing templates — but given the project's size, assume the only extension point is Twig block overriding via {% use %}. That's sufficient and it's the pattern that survives regardless of whether the bundle is maintained.