Mjr Theme Integration Bundle Laravel Package

Product Decisions This Supports

• Roadmap: admin/back-office theming strategy. This package is a useful negative data point. It wires the MJR theme — an ExtJS admin front end — into a Symfony bundle pipeline. Any roadmap line assuming "we'll theme the admin by pulling in MJR" is a dead end: it binds the product to ExtJS (commercial Sencha licensing, niche 4/5-era skills) and to a Symfony generation that ended around 2016. The roadmap should instead commit to a maintained UI layer (Inertia/Vue, Livewire, Filament, Nova, or a bespoke design-token system).
• Build vs. buy vs. reuse. Reuse is off the table on evidence: 0 stars, 0 dependents, composite score 0, last release 2016-06-10, repo marked [READ-ONLY], and it is a split mirror of a Modera monorepo rather than the source of truth. No community, no upgrade path across PHP 7/8, no security backport route, no maintainer to escalate to. That pushes the decision firmly to build (or buy a maintained product).
• Feature scoping for "custom branding" / white-label requests. When a stakeholder asks for a rebrandable admin, this package is the wrong answer. The assessment reframes the vague request into a concrete requirement — tokenized theming inside our own UI layer — so branding becomes configuration rather than a dependency hunt.
• Tech-radar and dependency-governance precedent. A canonical Hold / Avoid entry. It documents, in writing, the thresholds we now require before adding a dependency: maintained releases, real dependents, a supported-framework match, and a security-response path.
• Vendor and partnership due diligence. If anyone proposes Modera as a partner or a source of reusable components, this repo is a data point on their open-source maintenance posture. Frame the partnership conversation around their current commercial offering, not their archived 2016 bundles.
• Migration / exit planning for legacy estates. For any inherited system already on Modera MJR + ExtJS, this becomes a triage artifact: it names the theming layer as one of the coupling points to unwind and informs the cost model for migrating off ExtJS.

When to Consider This Package

Adopt only under a narrow, already-committed set of conditions:

• You are already running a Modera MJR-based Symfony application with an ExtJS admin front end, and you need to wire that specific theme into an existing bundle configuration — maintenance, not new development.
• You are on a legacy PHP/Symfony generation consistent with the 2016 release window, and the work is strictly upkeep.
• You want it as reference material — reading how MJR theme integration was structured before reimplementing the concept on a supported stack.
• You are doing archaeology or a fork: the code is a starting point for something you will own and maintain outright, with eyes open about the lifetime cost.

Look elsewhere — which is almost always — when:

• You are on Laravel. Despite being catalogued as a Laravel/PHP package, this is a Symfony bundle (*Bundle naming, DependencyInjection extension, Twig inheritance, Assetic-era asset publishing). There is no service provider, no config/*.php publish tags, no Blade views. Treat the "Laravel" label as a cataloging artifact.
• You need a supported PHP runtime. Ten years without a release means no PHP 8.x compatibility work, no dependency updates, no CI signal. composer require will likely refuse; --ignore-platform-reqs only defers the failure to runtime.
• You need ExtJS licensing clarity. ExtJS is commercially licensed by Sencha; a free theming bundle does not remove the underlying licensing and redistribution obligations. Budget for it separately — or avoid ExtJS entirely.
• You need security response. No maintainer activity means no CVE triage. For anything touching an admin surface, that is disqualifying.
• You want a themeable admin panel now. A maintained UI kit or a design-token system in your own front end dominates on cost, hiring, and longevity.

How to Pitch It (Stakeholders)

Recommendation: do not adopt. This is a low-stakes "no," not a trade-off.

The package integrates a custom backend theme for Modera's MJR/ExtJS admin stack. It has zero stars, zero dependents, no release since June 2016, and a composite score of 0. There is no community, no maintenance commitment, and no path to running it safely on a current PHP stack. It is also a Symfony bundle, not a Laravel package, so it does not fit our primary PHP framework at all.

What this costs us if we say yes: an unsupported dependency sitting on an administrative surface, an ExtJS commercial licensing and hiring obligation, and a theming layer we would have to fork and permanently own within months. That is a build cost disguised as a buy.

What we do instead: treat "themeable admin" as a first-class product requirement and satisfy it inside our own UI layer — design tokens plus a component library on a maintained framework — so branding requests become configuration, not a dependency decision. If any part of the business genuinely runs Modera/ExtJS today, scope a migration off it rather than deepening the coupling; this assessment is the opening evidence for that business case.

Bottom line for engineering: no integration work, no spike, no evaluation license. At most, a half-day, timeboxed asset harvest if the theme itself has design value — but keep the bundle out of composer.json. Log it on the tech radar as Hold / Avoid with the reasoning above so the next person doesn't rediscover it.