Appearance Module Laravel Package

Technical Evaluation

What it actually is. anomaly/appearance-module is not a general-purpose Laravel theming library. It is an addon for the Anomaly Streams Platform (the PyroCMS lineage) that supplies the control-panel "Appearance" area — the admin UI and service layer for editing theme layouts, partials, and assets in place.

Architecture fit. The module assumes it is being loaded by the Streams addon kernel: an AddonServiceProvider subclass, Streams' route/asset/view registration, and admin screens composed from Streams' form and table builders. There is no standalone service provider contract, no publishable config, and no Blade-level API. In a vanilla Laravel application it is inert — it will not boot, and its admin routes have no host to attach to.

Integration feasibility. Composer-installable in principle, but only inside a matching Streams installation. It carries a hard transitive dependency on anomaly/streams-platform and anomaly/theme-module, plus anomaly/users-module for the auth gating that makes the editor safe. On a modern Laravel (10/11) codebase, expect an unresolvable constraint conflict before you get to a first boot.

Technical risk. Four concerns dominate:

1. Abandonment signal. 1 star, 0 dependents, no visible community patch flow. The namespace has since migrated to pyrocms/* upstream, which strongly suggests this package is a legacy alias rather than an actively maintained line.
2. Security surface. Functionally, this module is a remote file editor for theme source. Any CSRF gap, path-traversal flaw, or permission-check regression is remote code execution, not a cosmetic bug. It must sit behind a policy gate and admin-only middleware without exception.
3. Version drift. Streams internals change without strict semver discipline; minor upstream bumps have historically broken admin addons.
4. No test/CI signal at this star count — assume none and plan to write your own smoke tests.

Key questions to resolve before committing:

• Are we already running Streams/PyroCMS, or is this a greenfield Laravel app? (If the latter, the answer is almost certainly "rebuild the capability.")
• What is the real requirement — "let marketing edit theme templates" or "swap between themes"? These have very different implementations, and only the first resembles this module.
• Is arbitrary file editing genuinely required, or would a curated allowlist of editable variables satisfy the stakeholder?
• What is our PHP/Laravel target, and does the pinned Streams version support it?
• Who owns upgrades and security patches for a fork, and is that person identifiable by name?

Integration Approach

Stack fit. Binary: Streams/PyroCMS yes, everything else no. Do not attempt to graft it onto a standard Laravel app — the effort to stand up Streams purely to host this module exceeds the effort to build the feature.

Three paths, ranked:

• A — Adopt (only if already on Streams). composer require anomaly/appearance-module, register the addon, ensure the theme directory is writable by the web user, seed the admin permission. Roughly 1–2 days including verification. Low cost, but inherits all the maintenance risk above.
• B — Adopt Streams first, then this module. Effectively a platform migration. 3–6+ months, unjustifiable unless there is an independent strategic reason to move onto PyroCMS. Not recommended on the strength of this package.
• C — Rebuild the capability in Laravel (recommended default). Split the requirement in two: theme resolution via a maintained package (laravel-theme / themes/*) or a simple config-driven view namespace, and theme customization via a DB-backed theme_settings table rendered into a cached CSS variable sheet or named Blade slots. If raw template editing is truly mandated, wrap a maintained file manager behind a policy gate and an allowlisted directory, and log every write. This is 1–3 weeks of work and produces something the team can actually own.

Compatibility checks. Verify the composer constraint matrix against our PHP and Laravel versions first — this is the usual fail-fast point. Check whether the module ships migrations (it largely does not, which simplifies rollback) and whether its assets are published or served from the package.

Sequencing. (1) Confirm stack and version matrix; (2) timeboxed spike in a throwaway Streams instance — half a day; (3) security review of every file-write path; (4) make the build-vs-adopt call; (5) if adopted, pin an exact version, vendor-fork it, and gate the feature behind a flag and an explicit permission; (6) if rebuilt, ship the settings-backed version first and defer raw editing until there is a demonstrated need.

Operational Impact

Maintenance. Effectively self-maintained. With 1 star and 0 dependents there is no community patch pipeline to lean on — budget for a fork on day one, and treat any upstream commit as untrusted until reviewed. PHP and Laravel major upgrades will require manual porting, likely by someone reading Streams internals.

Support. No vendor, no SLA, sparse documentation. Internal knowledge will concentrate in whoever does the spike, which is a bus-factor risk worth naming explicitly.

Scaling. Throughput is a non-issue — theme editing is a low-QPS admin activity. The real scaling concern is cache coherency: an edit must bust view and asset caches, and on multi-node deployments a local filesystem write shows up on exactly one node. This requires shared storage for the theme directory or a deploy-time sync hook, plus explicit cache invalidation. Containerized environments with read-only root filesystems will fail outright unless the theme path is a mounted volume.

Failure modes to plan for:

• Composer constraint conflict blocking unrelated dependency upgrades across the application.
• Admin UI breakage after an upstream platform patch, discovered by an editor rather than by CI.
• A malformed template saved through the UI taking down the public site — there is no sandbox or preview gate.
• Stored XSS via unescaped partials; path traversal or symlink abuse on the write path.
• Stale cached views after edits, generating "my change didn't work" support load.
• Disk growth from unversioned edits with no revision history or rollback.

Ramp-up. A Laravel developer can operate the module in under a day. Owning it means absorbing Streams addon conventions — provider lifecycle, asset registration, admin form builders — realistically 1–2 weeks with thin public material to learn from. Weigh that against the 1–3 weeks for path C, which leaves the team with skills that transfer to the rest of the codebase.