Foundation Bundle Laravel Package

Getting Started

Install it the way the bundle was designed to be installed in 2016: a Symfony 2.8/3.x application with composer.json requiring php >=5.5, Doctrine ORM, and the companion Modera bundles (modera/main-bundle, modera/backend-*). Registration happens in app/AppKernel.php:

new Modera\FoundationBundle\ModeraFoundationBundle(),

There is no Flex recipe and no auto-configuration, so plan on manually editing app/config/config.yml, app/config/routing.yml, and the bundle's own Resources/config/*.yml. The first place to look after composer install is the Module namespace (Modera\FoundationBundle\Module\AbstractModule and the module manager) — that is the bundle's central abstraction and almost everything else (routing, translations, container extensions, ExtJS UI registration) hangs off it.

A sensible first use case is to build one small feature module and prove the wiring works end-to-end:

1. Create Acme\DemoBundle\Module\DemoModule extending AbstractModule.
2. Implement getId(), getContainerExtension(), and getVersion(), then register the module in the application's module list (typically app/config/modules.yml or the module manager service).
3. Expose one service to the front-end via the bundle's ServiceContainer (a ServiceDefinition with an id, class, and config), because that is the mechanism Modera's ExtJS admin consumes server-side services.
4. Call your endpoint from the ExtJS side using the generated JS class.

If you just need Doctrine helpers or the functional-test base class, you can pull those in without adopting the module system — but the bundle is opinionated, and fighting the module/ServiceContainer split usually costs more than following it.

Implementation Patterns

Module-per-feature. Every meaningful unit of work — a CRUD screen, a settings panel, a reporting tool — becomes a Module subclass. The module owns its container extension (DependencyInjection/*Extension.php), its routes (Resources/config/routing.yml), its translations (Resources/translations/messages.*.yml), and its UI contribution. The day-to-day pattern is: add a module, register it, let it self-register its extension and routes. Keep the module class thin; put real logic in services.

ServiceContainer as the server/UI contract. This is the bundle's distinguishing trick. Instead of hand-writing JS controllers that call arbitrary URLs, you declare service definitions in config; the bundle compiles them into a JS class that knows how to invoke the corresponding server-side service. A typical definition looks broadly like:

modera_foundation:
    service_container:
        services:
            acme.demo.orders:
                class: Acme\DemoBundle\Service\OrdersService
                config:
                    jsClass: Acme.Demo.OrdersService

Treat it like a public API: the id is a contract, and changing it breaks the JS consumer. Version your own services when you can, and keep the config block small and stable.

Doctrine conventions. The bundle ships entity/manager helpers (timestampable/blameable style listeners, mapping utilities, a decorated EntityManager). Use the provided base entity traits and listener config rather than rolling your own — the admin UI and audit tooling assume those columns exist. When you add mappings, follow the bundle's XML/YAML convention, because the annotation reader path is configured specifically for Symfony 2.x/3.x.

ExtJS integration. Modera's front-end is ExtJS. The bundle provides base UI classes (grid/panel/window scaffolding, CRUD proxy wiring). Extend them via Ext class overrides in your module's Resources/public/js, and register the override in the module so it is loaded with the bundle's build. Do not modify vendor JS; always extend.

Testing. Extend Modera\FoundationBundle\Testing\AbstractFunctionalTestCase for functional tests. It boots a kernel, wires the test container, and gives you helpers for fixtures and DB setup. Use it as-is for anything touching modules or the ServiceContainer; plain KernelTestCase will not exercise the module boot path and will hide integration failures.

Translation. Reuse the bundle's translatable trait/trait conventions for entity-backed translations. If you invent a parallel scheme, the admin translation editor will not see your records.

Gotchas and Tips

• Age and framework drift. Last release June 2016, Symfony 2/3 era. It implements Bundle::getName()-style APIs and container-aware patterns that Symfony 4+ removed outright. Do not try to install this on modern Symfony; if you need the ideas, port them rather than fight the composer constraints.
• PHP 8 incompatibility. Expect create_function-era code, each(), missing type hints, and deprecation noise. If you must run it, pin PHP 7.x and accept the deprecation log.
• ExtJS is a hard dependency. The bundle is not a headless library. If you are building a Vue/React front-end, the ServiceContainer's value collapses to "a DI alias with extra steps," and you should evaluate whether you actually want the module system at all.
• Directory-layout assumptions. Module registration, asset publishing (Resources/public), and the ExtJS build assume a classic Symfony app/ + web/ skeleton. bin/console-only, src/-first layouts cause silent discovery failures.
• ServiceContainer caching. Service definitions are compiled into the container and into generated JS. If a service is "missing" on the front-end, run cache:clear and then check the generated JS bundle; a stale asset is the usual culprit.
• Debugging module boot. If routes or translations from a module disappear, check module registration order — modules are resolved in config order, and getRequiredModules() failures manifest as a blank/missing UI rather than a thrown exception.
• Testing needs a real DB. AbstractFunctionalTestCase assumes a reachable database and often a fixtures loader. Wire it to SQLite in-memory in CI, or you will get flaky local-vs-CI behavior.
• Extension points. The intended customization seams are (a) subclassing AbstractModule, (b) overriding services via a compiler pass in your own bundle, and (c) ExtJS class overrides. Monkey-patching vendor code is the path to an unmaintainable fork — the community around this bundle is tiny (2 stars, no dependents), so upstream fixes will not arrive.
• Budget for fork ownership. With no dependents and a 2016 release cadence, assume you own the maintenance. Fork it, pin the commit, and document every local patch; do not expect security fixes for underlying dependencies either.