madeyourday/contao-rocksolid-icon-picker
A Contao extension that adds an icon picker field for selecting icons in the backend, making it easy to assign icons to content elements and templates. Part of the RockSolid custom content elements toolkit, with documentation available in English and German.
Architecture fit. This is not a Laravel package. madeyourday/contao-rocksolid-icon-picker is a Contao CMS extension that registers a DCA (Data Container Array) field type for a visual icon picker in the Contao back end. Its integration surface is Contao's DCA configuration, back-end templates, and asset routing — none of which exist in a Laravel application. There is no service provider, no facade, no Blade view, no Eloquent contract. As a TPM, the correct framing is: this is a portfolio reference asset for Contao-based work, not a dependency a Laravel team should plan around. It only enters a Laravel roadmap if the org runs (or is acquiring) a Contao estate, or if a team is studying the pattern to reimplement as a Filament/Nova/Livewire field.
Integration feasibility. Composer installation is trivial, but the runtime value is zero outside Contao. Within a Contao stack, feasibility is high: it targets Contao 4.13/5.0 and Symfony 6, ships migrations of assets across recent releases (WOFF2 back-end loading in v2.1.2, dark theme in v2.1.1, blank-option and title-attribute fixes in v2.0.x), and has a stable release cadence. For a Laravel team, the realistic options are (a) extract the icon glyph assets and font files and rebuild the picker as a native field component, or (b) run Contao alongside Laravel via a bridge, which is a heavy architectural commitment for a single form widget.
Technical risk. Low risk if scoped to Contao. High risk if anyone proposes it as a Laravel dependency, because the codebase's assumptions (DCA hooks, TL_* config access, Contao asset paths such as web/, save-mode behavior) are not portable and would require a fork. Signals also argue for caution as a strategic bet: 7 stars, 0 dependents, single-vendor stewardship (RockSolid Themes), and a release date of 2026-08-31 that looks like a metadata artifact rather than verified activity. Maintenance is contingent on one commercial vendor continuing to support it.
Key questions.
Stack fit. Poor for a pure Laravel stack; strong for Contao. Map it accordingly: it belongs to the CMS layer, never the application layer. If the org runs a Laravel monolith, there is no clean seam — the package brings no Laravel-native extension points, and its value would be limited to the icon catalog and front-end CSS/font assets, which are consumable from any stack via a public directory or Vite pipeline. Treat the icon set as a design-system asset, not as code to be wired in.
Migration path. Three viable lanes, ordered by cost. First, asset extraction: copy the icon font files (including WOFF2) and glyph metadata into the Laravel asset pipeline, then author a thin Livewire or Alpine component that presents the same visual browse-and-select experience. This delivers the editor UX with no Contao coupling and is likely one to two weeks of work. Second, pattern reimplementation: use the package's field semantics — blank option only when non-mandatory, title attributes on icons, dark-theme parity — as an acceptance checklist for a native field. Third, Contao coexistence: if a Contao estate genuinely exists, run the extension there and bridge only the rendered icon identifier into Laravel through an API or shared data store; do not attempt to load Contao's DCA layer inside Laravel.
Compatibility. The one genuinely reusable compatibility concern is asset delivery: WOFF2 first, dark-theme CSS variables, and path handling that has historically broken on Windows and on paths prefixed web/. Any Laravel reimplementation should inherit those hard-won lessons rather than rediscover them. Everything else — Symfony 6 alignment, IE font-family fix, Apache 2.4 access protection — is Contao-specific and does not transfer.
Sequencing. Start with a discovery gate: confirm whether a Contao estate is in scope. If not, close the ticket and log the package as a design reference only. If yes, sequence as: (1) asset extraction and a Laravel-side proof of concept for the picker UI, (2) acceptance criteria derived from the release history, (3) data model and validation for the stored icon identifier, (4) accessibility and dark-mode pass, (5) decision review against building the equivalent natively. Do not sequence any step that assumes the Contao extension executes inside Laravel.
Maintenance. The maintenance burden differs sharply by lane. Inside Contao, updates flow through Composer and the vendor's release cadence; the historical changelog shows steady small fixes, which is a positive signal for an in-scope deployment. Inside Laravel, maintenance is entirely ours — any extracted asset set needs versioning, and any copied component needs an owner. The dangerous middle ground is a half-fork: partially vendored Contao logic that neither tracks upstream nor belongs to us. Avoid it.
Support. One commercial vendor, no visible community of scale, zero dependents in the ecosystem. For a TPM this means the escalation path is a support contract or nothing. Budget for that explicitly if the extension becomes load-bearing on a Contao property; do not assume community fixes will arrive for edge cases such as font path resolution or Apache access rules.
Scaling. The package scales as far as Contao does. There is no architectural concern at the picker level — it renders a bounded icon set into a form field. The scaling risk sits at the platform level: Contao's DCA and back-end rendering model is not designed for high-concurrency, API-first workloads, and a Laravel team adopting it as a subsystem inherits a monolith alongside a modern application. Keep the two lifecycles separate if both must exist.
Failure modes. The realistic failures are: (1) a team member reads "Composer package" and adds it to a Laravel composer.json, producing dead weight and confusing onboarding; (2) font assets fail to resolve due to path assumptions, causing blank icon rendering in the admin UI; (3) upstream goes quiet and a Contao property is left on an unpatchable version; (4) a custom fork drifts until neither upstream nor the fork is trustworthy. Each has a cheap mitigation — an explicit scope note, asset smoke tests, a support contract, and a no-fork policy respectively.
Ramp-up. For a Contao developer, the extension is a same-day onboarding: install, declare the DCA field, populate the icon set. For a Laravel developer, ramp-up is effectively the cost of learning enough Contao to conclude it is not theirs to use — better to short-circuit that and hand them the extracted assets plus the release-notes acceptance criteria. TPM action: document the package's actual role (Contao design reference, not a Laravel dependency) in the internal package registry so the next evaluation does not reopen the same question.
How can I help you explore Laravel packages today?