Backend Module Bundle Laravel Package

Getting Started

First, a framework reality check. Despite being evaluated here by a Laravel developer, this is a Symfony bundle (Symfony 2.8–3.x era), not a Laravel package. There is no service provider, no config/*.php, no facade. If you are working in a Laravel codebase you cannot install this — read it as a reference implementation of a "browse and install packages from the admin panel" feature and port the idea, not the code.

If you genuinely are on a Modera/Symfony backend, the minimal path is:

1. composer require modera/backend-module-bundle (expect dependency conflicts — see Gotchas).
2. Register new Modera\BackendModuleBundle\ModeraBackendModuleBundle() in AppKernel.
3. Import the bundle routing (Resources/config/routing.xml) under your backend prefix — by convention /backend — so the module browser lands at something like /backend/modules.
4. Register the section in the backend menu via the bundle's menu provider (it hooks into modera_backend's menu compilation, so the "Modules" item appears in the left nav automatically once the routing + menu tag are wired).
5. Clear the cache and log in as a backend user.

Where to look first, in this order:

• Resources/config/services.xml — the actual surface area. Service IDs and constructor arguments tell you far more than the README.
• Controller/ — the HTTP entry points (list, detail, install/uninstall actions).
• Whatever ModuleManager/ModuleRepository-style service backs the controller — that is the single unit you would ever reuse standalone.
• Resources/translations/ — confirms it is designed to be embedded in a localized admin, and gives you the vocabulary (installed / available / update).

First use case: as an admin, open the Modules section, see a catalog of installable Modera modules pulled from a remote/configured source, and click Install to have the bundle added to the project. That is the whole feature. Everything else is chrome.

Implementation Patterns

Inject the manager, not the controller. The only reusable seam is the service that knows "what modules exist" and "what is installed". If you are adapting this for your own stack, keep that boundary: your admin controller should ask a service for a list, never shell out to Composer itself.

• Catalog + installed = two lists, merged in the UI. Expect the pattern getAvailableModules() vs getInstalledModules(), with the view diffing them to decide which button to render. Replicate this split; it keeps the "installed" side cheap (filesystem / composer.lock read) and the "available" side cacheable (remote fetch).
• Menu-as-service. The nav entry is contributed via a tag/compiler pass rather than hardcoded in a template. If you copy this pattern into Laravel, the equivalent is a NavigationService that collects items from registered "modules" and renders them in a Blade partial — do not edit the layout.
• Permission gate on every action. The install action should be behind a distinct role/permission from plain "view modules", otherwise every backend user can mutate composer.json. Wire the permission check in the controller and the menu provider (hide the item if unauthorized), not just the template.
• Config-driven source. Point the module source (remote registry URL, or a local JSON manifest) at config so staging can use a mirror and tests can use a fixture file. This is also your only sane testing hook.
• Install as an out-of-band operation. The 2016 implementation is synchronous; the modern, correct pattern is: controller enqueues a job, job runs composer require, UI polls status. If you keep the synchronous path, at minimum wrap it with an explicit timeout and a lock so two admins cannot install concurrently.
• Post-install lifecycle. Any working implementation must do: install → regenerate autoload → clear cache → (for Symfony) warmup, and for asset-bearing bundles, dump assets. Model this as a small state machine, because partial failure here is the normal case, not the exception.
• Laravel translation of the same feature: an Admin\PackageController + PackageRegistry (reads a manifest or Packagist API) + InstallPackage queued job running composer require via Process, status persisted in a package_installs table, UI polling a status endpoint. Same shape, none of this bundle's code.

Gotchas and Tips

• Archived since 2016 — treat it as dead source. No Symfony 4/5/6 support, no PHP 8, no security maintenance for a decade. Installing it into a modern project will not resolve. Vendor it into app/ as read-only reference if you want to study it.
• It is not standalone. It expects the full Modera backend stack (backend-bundle, security-bundle, translations-bundle, backend tools) plus the Sencha/ExtJS-flavored backend UI. There is no useful subset you can compose into an unrelated app without rewriting it.
• A web UI that runs Composer is remote code execution, by design. If you ever rebuild this: require an existing authenticated admin session, a dedicated permission, an IP allowlist or VPN, and never enable it in production. Audit-log every install with the user, the package, and the version.
• Synchronous Composer runs time out. Web-server max_execution_time, PHP memory limits, and proxy timeouts will kill a real install mid-write, leaving composer.json/vendor inconsistent. Always run installs from a CLI worker or queue with a lock file.
• Autoload is cached in the running FPM process. Even after a successful install, new classes are not visible until the worker restarts or opcache is invalidated; users report "installed but class not found" almost every time. Plan a reload step.
• Route and menu name collisions under /backend. If your app already uses modules as a path segment, you will silently shadow or be shadowed. Rename the prefix rather than debug the symptom.
• Config key and translation domain quirks. Modera bundles of this vintage use bundle-prefixed config keys (modera_backend_module.*) and their own translation domain; overriding strings means adding files to app/Resources/ModeraBackendModuleBundle/translations/, not editing vendor files.
• Debugging entry points: the bundle logs little. Start with the Symfony profiler on the list action (it will show the remote fetch and its timing), then var/logs/, then the module manager service directly via a one-off console command — reproducing outside HTTP is much faster than clicking through the UI.
• Extension points, such as they are: override the module manager service definition (decorate it) to add filtering or a private registry; override the controller only if you must, since the route definitions reference it by service id. Both are fragile against the archived dependencies — prefer wrapping.
• Verdict for day-to-day use: zero direct leverage. Its only value is as a circa-2016 case study of an admin package manager, and as a warning list of everything that makes such a feature dangerous.