Core Laravel Package

Product Decisions This Supports

• Build vs. buy the theming layer (Contao only). This is not a Laravel package — it is a Contao CMS bundle. Framed correctly, the decision it informs is: do we hand-roll a SCSS build + design-token layer, or adopt a pre-built, backend-configurable one? ThemeManager bundles an scssphp-based compiler, CSS versioning, dynamic background-image generation, and icon-font management, which is genuinely weeks of build work replaced by composer require.
• Who owns visual change. The core value prop is "fully configurable system eliminating the need for knowing or writing CSS" — colors, breakpoints, spacing, backgrounds, and icon fonts are edited in the Contao backend. That is a resourcing decision: moving routine design tweaks from the developer backlog to editors/content admins, which shortens client feedback loops and lowers cost-per-change on retainer work.
• Scope and quoting for Contao delivery work. Grid system, default styles for nearly all Contao components, extra content elements (wrappers, text/image/icon/list), and StyleManager-driven per-component options let you standardize a reusable baseline across client sites instead of rebuilding layout primitives each engagement.
• Performance budget. ~55.8 kB minified / ~11.4 kB gzipped framework CSS is a defensible number when justifying "no Tailwind/custom framework" to a performance-sensitive stakeholder.
• Practice/roadmap standardization. Deciding whether ThemeManager becomes your default Contao theme stack — and therefore whether you invest in internal onboarding docs, because upstream documentation is German-only and marked WIP.

When to Consider This Package

Consider it when all of the following hold:

• The stack is Contao 4.13 or ^5.3 on PHP ^8.1+ (note the inconsistency: the 2.4.0 release bumps to PHP ^8.3 and unlocks doctrine/dbal ^4.3, while the README still advertises PHP ^8.1 — verify against your actual runtime before committing).
• Non-technical editors genuinely need to change design without a developer in the loop; that is the only compelling reason to accept the coupling.
• You accept AGPL-3.0. Fine for client-hosted sites where you are not distributing a derivative product; a hard blocker if ThemeManager would be embedded in a proprietary or distributed product, or in a SaaS where you are unwilling to offer source to network users. Get legal sign-off early — this is the single most likely deal-killer.
• You accept a vendor cluster: it depends on oveleon/contao-component-style-manager, contao-theme-compiler-bundle, contao-config-driver-bundle, plus madeyourday/contao-rocksolid-custom-elements and rocksolid-icon-picker. Roughly five third-party bundles become part of your critical path, and version constraints are pinned to Contao patch releases.

Look elsewhere when:

• The stack is Laravel, Symfony standalone, or anything non-Contao — there is no transferable value here.
• You need headless/API-first or theme portability across CMSs; this is tightly bound to Contao templates and the backend.
• You need enterprise support, English documentation, or a broad contributor base. 6 stars, 0 dependents, one maintaining agency, German WIP docs is a real bus-factor and onboarding risk, not a cosmetic one.
• You are already on v1 — upstream explicitly says upgrading v1 → v2 is not recommended, so treat that as a migration project, not a bump.
• You require low template-maintenance overhead: releases repeatedly patch Contao's form_wrapper template to track Contao 5.3.10/5.3.11 changes, meaning Contao upgrades can require ThemeManager upgrades in lockstep.

How to Pitch It (Stakeholders)

To executives: This is a Contao-specific theming layer that lets editors change colors, spacing, layouts, and backgrounds from the CMS backend instead of filing developer tickets — cutting cost-per-design-change and time-to-launch on Contao builds, with a small CSS footprint (~11 kB gzipped). The tradeoffs are material: it is AGPL-3.0 licensed (a blocker if we ever distribute or host this as a product), it is maintained by a single agency with a small community (6 stars, no known dependents) and German-only documentation, and it pulls in several related third-party bundles. Recommendation: pilot on one non-critical Contao project, confirm the PHP/Contao version fit and get legal sign-off on AGPL, then decide on standardization.

To engineering: Adopt via composer require contao-thememanager/core, run schema updates, expect the oveleon/rocksolid bundle set as dependencies and pinned Contao version constraints. It ships strict types, PHP attributes, and DBAL 4 fixes, and releases are actively maintained (2.4.4, with Doctrine DBAL 4 migration fixes contributed externally). Watch: template overrides track Contao patch releases, so treat Contao upgrades and ThemeManager upgrades as one unit of work; confirm the PHP minimum (README says ^8.1, recent releases require ^8.3); and budget time for internal docs since upstream guidance is German and incomplete.