Amazium Bundle Laravel Package

Getting Started

This is a Symfony2 bundle, not a Laravel package. It exists to provide Twig form themes that render Symfony Form component markup using the Amazium CSS framework. There is no service provider, no Blade directives, and no config/app.php registration path. If you are working in a Laravel codebase, the practical starting point is to treat this repository as reference markup, not as a dependency.

Minimal steps if you are actually in a legacy Symfony2 app:

1. composer require hobnob/amazium-bundle (expect PHP 5.x constraints and old Symfony versions; latest tag is v0.0.10).
2. Register the bundle in app/AppKernel.php:

   new Hobnob\AmaziumLayoutBundle\HobnobAmaziumLayoutBundle(),
   

3. Wire the form theme in app/config/config.yml:

   twig:
       form_themes:
           - 'HobnobAmaziumLayoutBundle:Form:fields.html.twig'
   

4. Include Amazium CSS (the bundle does not ship a modern asset pipeline; you will likely reference a CDN or copy the CSS into web/).
5. Render your first form: a simple contact or login form via $this->createFormBuilder() and form_start / form_row / form_end in Twig.

Where to look first:

• Resources/views/Form/*.html.twig — the actual value of the package. These are the block overrides (form_row, form_widget, form_label, form_errors, etc.).
• DependencyInjection/ — confirms there is almost no runtime wiring; this is a view-layer bundle.
• README.md — likely sparse, so read the Twig blocks directly to understand expected markup.

First real use case: rendering a Symfony form with Amazium grid classes (grid, col, form-field) instead of default Symfony markup, without hand-writing every field.

For a Laravel developer, the first use case is different: extract the Amazium class conventions from the Twig blocks and reproduce them as Blade components or partials. For example, a resources/views/components/form/row.blade.php that emits the same wrapper/error/help structure.

Implementation Patterns

Global theme, then targeted overrides. Apply the bundle theme globally in config.yml, then override individual blocks in your app's own form theme that extends it. This keeps Amazium defaults for most fields while letting you customize specific types (e.g., checkboxes, file inputs).

{# app/Resources/views/form/amazium_overrides.html.twig #}
{% extends 'HobnobAmaziumLayoutBundle:Form:fields.html.twig' %}

{% block checkbox_row %}
    {# custom Amazium switch markup #}
{% endblock %}

Per-form theming. When you only want Amazium styling on public-facing forms:

{% form_theme contactForm 'HobnobAmaziumLayoutBundle:Form:fields.html.twig' %}
{{ form_start(contactForm) }}
    {{ form_row(contactForm.name) }}
    {{ form_row(contactForm.email) }}
    {{ form_row(contactForm.message) }}
{{ form_end(contactForm) }}

Custom form types with block prefixes. If you create a MoneyType or AddressType, give it getBlockPrefix() and add a matching block in your theme. This is the cleanest extension point and the pattern the bundle is designed around.

Layout integration. Amazium is a grid framework; the bundle's form blocks assume a grid container. Wrap forms in the expected Amazium layout structure (<div class="grid">, column classes) rather than dropping form_start into an arbitrary container, or the emitted classes will not align.

Asset handling. Do not expect the bundle to publish or compile Amazium assets. In Symfony2 you would add the CSS to web/css/ and reference it from your base layout; in Laravel you would npm install a CSS copy or vendor the stylesheet and import it through Vite/Mix.

Porting to Laravel (the realistic day-to-day pattern). Since Laravel does not use Symfony forms by default:

• Copy the Amazium markup structure from the Twig blocks into Blade partials.
• Build a small set of Blade components: x-form.row, x-form.label, x-form.error, x-form.input, x-form.select.
• Keep the class names identical to what the Twig blocks emit so existing Amazium CSS works unchanged — including the extra label that v0.0.10 added to the error block if you are porting from that tag.
• If you genuinely need Symfony forms inside Laravel (rare), you would have to bridge the Form component and Twig manually — not worth it for a styling bundle.

Validation and errors. The theme handles form_errors, but error placement depends on your layout. Verify that Amazium's error/help classes are applied consistently in your override blocks; otherwise errors render unstyled. Since v0.0.10 the error block emits an additional label alongside the error list, so any form_errors override you wrote against an earlier tag may need to be re-checked (or widened to account for the extra element) rather than blindly extending.

Gotchas and Tips

• Symfony2 is end-of-life. This bundle targets an abandoned framework branch. Composer resolution against modern PHP/Symfony will fail or require extensive config.platform hacks. Do not introduce it into a new project.
• Amazium itself is effectively abandoned. The CSS framework has not been maintained for years. Budget for replacing it with a maintained framework rather than building new UI on it.
• No Laravel compatibility layer. There is no service provider, no facade, no Blade integration. Any "Laravel usage" is really a manual port of markup.
• Maintenance is patch-level only. The 2015-era bundle is no longer a single frozen tag — v0.0.10 is a late 0.0.x patch ("Adds additional label to errors") — but it remains pre-1.0, with no issue triage, no security policy, and no upgrade guide. Treat version bumps as silent markup changes, not as guarantees.
• Error markup changed in v0.0.10. The rendered error region now includes an extra label. If you style errors with CSS/JS selectors assuming the old structure (e.g. .error:first-child, direct-child selectors, or a fixed DOM shape), re-test after upgrading. If you override form_errors, copy the current block into your own theme before editing so the extra label is preserved.
• Form theme not applying? In Symfony2 the common causes are: the twig.form_themes key is misspelled or nested incorrectly in config.yml, the bundle is not registered in AppKernel, or a local {% form_theme %} call overrides the global one. Clear the cache (app/console cache:clear) after config changes — required after any tag upgrade.
• Block name mismatches. Symfony form theme block names changed across versions (e.g., *_widget vs. legacy naming). If fields render unstyled, check that the block names in the bundle match your Symfony minor version.
• Template resolution. HobnobAmaziumLayoutBundle:Form:fields.html.twig uses the old colon notation. In newer Symfony/Twig setups, use @HobnobAmaziumLayout/Form/fields.html.twig if the bundle were ever upgraded — it has not been.
• Debugging Twig blocks. Use app/console twig:debug (if available in your version) or temporarily dump the resolved template with {{ dump(_self) }} to confirm which theme is winning.
• Extension point to lean on: getBlockPrefix() on custom form types plus a matching block in your app-level theme. This is more maintainable than monkey-patching the bundle's templates directly.
• Do not edit vendor templates. Copy the blocks into app/Resources/views/Form/ and extend, so Composer updates do not clobber your changes. This matters more now that 0.0.x patches can land and alter previously stable blocks.
• Pin the version. If you inherit an app rendering forms with this bundle, pin the exact tag ("hobnob/amazium-bundle": "0.0.9" or 0.0.10) and commit the lockfile; an unpinned ^0.0 range can silently change your error markup.
• Security/compliance. Run composer audit if you inherit an app using this; transitive Symfony 2.x dependencies will almost certainly flag. Plan a migration off both the bundle and Symfony2.
• Recommendation for a Laravel team: skip the package entirely. Read the Twig blocks for the Amazium class conventions, then implement equivalent Blade components against a maintained CSS framework. The only defensible reason to install this is maintaining an existing Symfony2 application where the forms already depend on it.