Multiple Inheritance Bundle Laravel Package

Getting Started

• Know what you're adopting. This is a Symfony 2.x bundle (last active around the Symfony 2.3–2.8 era). It works around Symfony's hard limit of one parent per bundle (Bundle::getParent() returns a single class) by letting several child bundles share/consume one or more parent bundles' resources (templates, translations, routes, DI config). It is archived, 5 stars, and has no dependents — treat it as legacy code you maintain, not a dependency you expect fixes from.
• Install: composer require megogo/multiple-inheritance-bundle. Pin the version in composer.json ("megogo/multiple-inheritance-bundle": "dev-master" or a tagged release) since there will be no upstream patches. Verify the composer.json of the bundle for its symfony/symfony constraint before installing; it will not resolve cleanly against Symfony 3+.
• Register the bundle in app/AppKernel.php::registerBundles(). Register it before the bundles that use it, and register parent bundles before children.
• First place to look: the bundle's own Bundle class and README. The integration point is the class you extend (or interface you implement) for your child bundle — it lets you declare multiple parents instead of Symfony's single getParent(). Read the compiler pass / kernel hook in the bundle source to understand when the parent chain is resolved (before or after registerBundles).
• First use case: you have AdminBundle and FrontendBundle that both need the same layout templates, form themes, translations, and a handful of shared services currently living in BaseBundle. With vanilla Symfony you can only pick one parent. Use this bundle to declare BaseBundle (plus any second parent) once and let both child bundles inherit from it.

Implementation Patterns

• Shared base bundle pattern (most common). Create BaseBundle holding layouts, macros, common translations, and shared services. Each child bundle declares its parent(s) via the bundle's multi-parent mechanism instead of overriding getParent(). You then delete the duplicated Resources/views/ trees from the children.
• Override chain, not copy chain. For each overridden template/resource, confirm the resolution order the bundle installs. Typically the child's own Resources/ wins, then parents in declaration order. Keep a one-line comment in each override header documenting which parent it shadows — this is the only documentation you'll get.
• Layering by environment. A frequent practical use: BaseBundle → ApiBundle and BaseBundle → WebBundle, with a third DebugBundle parent added only in dev. Keep such conditional registration in AppKernel guarded by $this->getEnvironment(), and clear the cache when switching environments.
• DI config merging. If parents expose services.yml/config.yml, remember Symfony's Extension::load() convention: later-loaded config overrides earlier for scalars, but arrays/parameters merge per Symfony's rules. Prefer explicit parameter namespacing (base.foo, admin.foo) over relying on implicit merge order.
• Routing. Parent route files should use unique route names or an imported prefix (/base, /admin). Test with app/console router:debug after wiring; duplicate route names silently shadow.
• Translations. Parent translation domains are shared; use domain suffixes (messages, admin, base) rather than per-bundle catalogs to avoid collisions.
• Migration from getParent(). Introduce the bundle by keeping existing single-parent behavior first (declare one parent through the new mechanism), confirm nothing breaks, then add the second parent. This isolates "did the bundle break my app?" from "did my second parent break my app?"
• Wrap it. Since it's unmaintained, put the dependency behind your own thin AppBaseBundle so a future replacement (composer symfony/asset-style manual includes, or a custom kernel Bundle subclass) only touches one file.

Gotchas and Tips

• Symfony version lock. Bundle inheritance was deprecated in Symfony 3.x and removed in 4.x. This bundle's kernel/bundle-resolution hooks are tied to 2.x internals (Kernel::registerBundles, Bundle::getParent). Do not attempt to upgrade a project that depends on it; plan the rewrite instead.
• Resolution order is the whole game. Whether "first declared parent wins" or "last declared wins" determines every override you write. Verify it once with a throwaway template in each parent, then document the result at the top of AppKernel.
• Cache is your enemy. Parent-chain changes, new parents, and config merges are cached. After any registration change run app/console cache:clear --env=dev (and --env=prod if you deploy) before debugging — half of "it's not inheriting" reports are stale cache.
• Debugging toolbox: app/console container:debug <service> for service visibility, router:debug for routes, debug:translation <locale> for catalog merging, and a raw var_dump($this->getBundles()) inside a controller to see the resolved bundle list and order. Also check app/cache/dev/appDevDebugProjectContainer.xml to see which resource paths actually got registered.
• Bundle registration ordering. Parents must be present when the child is resolved. If a parent is conditionally registered (e.g., dev-only), guard children too, or you'll get a "bundle not found"-style failure only in one environment.
• Extension points: if the bundle's provided base class isn't enough, look for its compiler pass — it's the sanctioned place to add custom merge behavior. Forking the bundle and patching the pass is realistic given the archive status; vendor the fork or use a repositories VCS entry.
• Testing. Add a functional test that boots the kernel and asserts a known parent template resolves for each child; this catches ordering regressions when someone edits AppKernel. Keep it in a suite that CI runs, because nobody upstream will tell you when it breaks.
• Security and support. Archived, ~zero adoption means no CVEs will be filed and no security fixes will land. Audit the code once (it's small), and don't expose its config to untrusted input.
• Exit plan. Budget for removal. The realistic replacement is consolidating shared assets into one bundle with explicit Twig includes and explicit service imports — more verbose, but future-proof against Symfony 4+.