Mjr Theme Integration Bundle Laravel Package

Getting Started

Read the repo before touching Composer. The single most important first step is confirming what you already suspect from the name: modera/mjr-theme-integration-bundle is a Symfony bundle, not a Laravel package. It registers through DependencyInjection/*Extension.php and a *Bundle class, not a ServiceProvider. composer require against a Laravel app will not give you a working integration, and against a modern PHP 8 runtime it will likely fail resolution outright.

Clone it read-only and inventory three directories before writing a line of code:

• Resources/ — this is the substance. Look for public/ (compiled theme JS/CSS), Twig layout partials, and any SCSS source. This is the only part plausibly reusable.
• DependencyInjection/ — the config tree. This tells you which theme settings were exposed (logo path, asset base, color knobs). You will re-express these as a Laravel config file.
• composer.json — the exact 2016-era constraint set (php >=5.5, Symfony 2.8/3.x siblings). This is your compatibility red flag, not a shopping list.

First use case: salvage the theme, reject the bundle. A concrete first task is to copy the theme assets out of Resources/public into your own resources/ tree, render them through Vite/Mix, and wrap them in a Blade layout. That gives you a visually working admin shell in an afternoon without a single line of the bundle's PHP. Everything else in the package is container glue you will rewrite idiomatically anyway.

Decide early what you actually want from the repo: theme SCSS/JS, layout templates, or the config wiring. Only the first two survive the port; treat the third as a spec, not code.

Implementation Patterns

Extract, don't depend. The dominant pattern is a one-time harvest, not an ongoing dependency. Do not add the bundle to composer.json — an abandoned package in your lockfile becomes an upgrade deadlock the next time you touch PHP or Laravel versions. Copy assets in, commit them, and own them.

Re-home the config as a Laravel config file. The bundle's Configuration.php tree maps cleanly onto a config/mjr-theme.php file plus an .env-driven override for the values that vary per environment (asset base URL, brand strings). This is the "theme settings exposed via bundle configuration" feature, expressed the Laravel way. Keep it flat and documented; do not build a nested settings service for five keys.

Wrap the layout in Blade. The bundle publishes Twig partials for the admin chrome. Port the markup into a single Blade layout (resources/views/layouts/mjr.blade.php) with a @yield/component boundary for content. This isolates the ExtJS surface from your main application front end. Run the theme's SCSS through your existing build pipeline — do not resurrect Assetic-era conventions.

Mount behind a route prefix. Serve the admin UI from its own route group and layout so its asset bundle and ExtJS runtime do not contaminate the public-facing app. A dedicated Admin route group with its own middleware and layout is the clean boundary. This is the single most important integration tip: containment.

Use it as reference material when ExtJS is already in play. If you inherit a Modera MJR/Symfony estate, read this bundle to see how theming was wired so you can identify and unwind the coupling point during migration. That is a legitimate day-to-day use — as triage documentation, not as a runtime dependency.

Gotchas and Tips

It will not install into Laravel. Stop trying. No service provider, no Laravel package manifest, no config/*.php publish tags, no Blade. Any "integration" is a port. Budget accordingly and skip the composer require spike entirely.

--ignore-platform-reqs is a trap, not a workaround. If Composer refuses the 2016 constraints, forcing it only defers the failure to runtime — deprecated each(), dynamic properties, and removed Symfony APIs fail silently until the exact admin code path loads. Silent runtime breakage on an admin screen is worse than a hard install failure.

The repo is likely a stale read-only split. Treat published assets as a snapshot of unknown vintage relative to the upstream Modera monorepo. If you copy assets out, record where they came from and how old they are, or you will have asset-publish drift you cannot diff against anything.

You cannot patch upstream. No maintainer activity, no issue triage, no security response, no release since 2016. Plan every future PHP or framework bump as your problem. This is why the extract-and-own pattern beats the dependency pattern: at least your fork lives in your repo where you can fix it.

ExtJS licensing is the deal-breaker to check first. The theme bundle is free; the ExtJS runtime it targets is a commercially licensed Sencha product, and the licensing and community-edition terms have changed materially since 2016. Confirm licensing before spending engineering days on asset extraction — a "no" here kills the effort regardless of technical merit.

There are no meaningful extension points. "Minimal service wiring with no core overrides" means there is nothing to hook into — no events, no strategy classes. Do not look for a customization seam; there isn't one, and that is by design. The only leverage is the assets.

Skill scarcity is a real cost. ExtJS 4/5-era patterns (Ext.define, the class system, layout managers) are a niche skillset. If no one on the team has it, the first admin UI incident is an unbounded research task. Factor code review and hiring into the "is this worth keeping" decision, not just the extraction effort.

Set an explicit decision gate. After the spike, ask whether carrying the ExtJS runtime forward is cheaper than rebuilding the admin surface on a maintained UI stack (Inertia/Vue, Livewire, Filament, Nova, or your own design-token component library). Stakeholder branding requests are better satisfied as configuration in your own UI layer than as a dependency on an archived one. Log this package on the tech radar as Hold/Avoid with that reasoning so the next developer does not rediscover it.