Contact Plugin Laravel Package

Technical Evaluation

Architecture fit anomaly/contact-plugin is not a standalone Laravel package — it is an addon for the AnomalyLabs Streams Platform (the CMS framework lineage behind PyroCMS/Anomaly). In that ecosystem a "plugin" is a Twig extension provider registered through the addon service provider, so this package almost certainly contributes a Twig function that renders a contact form and a matching route/controller that validates input and dispatches mail through Laravel's Mail facade. That means it fits cleanly only if the target application already runs Streams Platform with a Twig-rendered front end. On a vanilla Laravel/Blade application it is not composable — adopting it means adopting the entire addon/CMS layer.

Integration feasibility Mechanically straightforward: composer require anomaly/contact-plugin, install the addon through the platform's artisan command surface, run migrations, publish views/config/language files, then drop the Twig function into a page. The real gate is the composer.json constraint against anomaly/streams-platform and, transitively, the Laravel major. Streams has historically tracked specific Laravel majors with lag, so on a modern Laravel (10/11/12) install this is likely to conflict or require --ignore-platform-reqs hacks that we should not accept in production.

Technical risk High, and mostly unknown-shaped rather than known-bad. Zero stars and zero dependents means no external evidence of a working install on any current version, no issue history to mine for failure modes, and no community triage. There is no visible test suite, no security disclosure path, and no stated spam mitigation (CAPTCHA, honeypot, rate limiting) — a public contact endpoint without those is an operational liability on day one. MIT license is fine, but the practical maintenance covenant is effectively "none."

Key questions

• What exact streams-platform / Laravel / PHP constraints does composer.json declare, and does it resolve cleanly without flag overrides?
• Does the submission path persist anything to the database, or is it fire-and-forget email? Where is the recipient list configured?
• Is mail sent synchronously in the request, or queued? Is there a ShouldQueue mailable?
• What abuse controls exist (CSRF is table stakes; honeypot/CAPTCHA/throttle are the real question)?
• Are there migrations that create stream slugs or tables that could collide with our existing schema?
• What is the view-overriding story — can we restyle without forking?
• Is output escaped in the provided templates, and is there any file-upload or header-injection surface in the mail composition?

Integration Approach

Stack fit Only viable where the stack is Anomaly/Streams Platform + Twig. If our estate is Blade-first Laravel, the honest recommendation is to skip this package and spend the same effort on a small first-party form (a mailable, a form request, a controller, and a Blade partial) — roughly a day of work, fully owned, no CMS coupling.

Migration path Assume this is replacing something: a hand-rolled contact controller, a third-party form SaaS, or nothing at all. Install into staging first, run the addon in parallel with the incumbent, and compare captured submissions and delivered mail across a week of real traffic before swapping the Twig include into the production template. Keep the old route mounted but disabled behind a feature flag until the cutover is confirmed.

Compatibility Pin the addon and anomaly/streams-platform to exact versions in composer.lock; do not allow floating constraints. Validate on the same PHP minor as production. If resolution against our Laravel major fails, treat that as a stop signal rather than forcing it — a patched dependency tree in a CMS addon is how you get a Friday-night incident.

Sequencing

1. Spike (0.5 day): clone into a throwaway Streams install on our target Laravel/PHP; confirm composer resolution and that the Twig function renders.
2. Version lock: record the resolved constraint set; decide fork-and-pin vs. vendor-and-pin.
3. Staging install: artisan addon install, migrations, publish assets, seed config (recipient, from-address, subject/template).
4. Mail plumbing: wire the mailer/transport, verify SPF/DKIM alignment on the sending domain, confirm queue vs. sync behaviour under load.
5. Abuse controls: add honeypot + throttle middleware or a CAPTCHA at the route layer — do not assume the package provides it.
6. Accessibility and UX pass: labels, error states, success/failure messaging, mobile layout.
7. Parallel run → cutover: feature-flag the swap; monitor delivery and error rates for one release cycle.
8. Rollback: documented path — remove Twig include, restore prior route, leave tables in place (do not roll back migrations on a live DB).

Operational Impact

Maintenance Treat this as vendored source we own, not a dependency we consume. Budget a fork in our org, a pinned lockfile entry, and a standing ticket to review it each time we bump Laravel or Streams. With zero dependents there will be no upstream pressure to keep it current, so drift is guaranteed and the fork is the only realistic mitigation.

Support No community, no issue history, no visible SLA. Escalation is limited to the vendor (small team) or ourselves. For a contact form — a low-complexity, high-visibility feature — that asymmetry argues for owning the code outright.

Scaling Load is negligible: one form submission is one request, one validation pass, one mail job, optionally one insert. The only scaling concern is mail throughput and third-party SMTP latency if sending is synchronous — a slow relay would hold PHP workers and degrade the whole site under a spam burst. Force the mailable onto a queue and add a rate limit per IP.

Failure modes

• Silent mail failure — submissions accepted, nothing delivered, no alerting. Mitigate with a sentry/log alert on mailable exceptions and a synthetic weekly probe.
• Deliverability collapse — misconfigured From: or missing DKIM/SPF sends everything to spam; users assume the form works.
• Dependency drift — a composer update of Streams changes the Twig function signature or plugin registration contract and the form 500s on the page.
• Slug/migration collision — the addon's stream definitions clash with existing ones during install.
• Spam flood — no built-in abuse control means a bot hitting the endpoint generates unbounded mail volume and potential blocklisting of our sending domain.
• Template regression — a view override silently drops server-side validation or escaping.

Ramp-up A Laravel developer can read this codebase in half a day; the Twig function and controller are small. The real ramp is Streams Platform literacy — addons, streams, assignments, and the admin UI's configuration surface — which is roughly 3–5 days to genuine productivity, and that cost lands on whoever inherits the site, not just on this project. Plan for at least two people to hold that context, and write the runbook (config location, recipient change procedure, rollback) as a deliverable of the integration, not an afterthought.