Mailerlite Laravel Package

Technical Evaluation

Architecture fit. siterig/statamic-mailerlite is a Statamic addon rather than a general-purpose Laravel package, which matters for scoping: it is only relevant if the target application runs Statamic (v4/v5) on top of Laravel. Architecturally it follows the standard Statamic addon contract — a service provider registering config, an API client wrapper around MailerLite's REST API, and Antler/Blade-facing tags (typically a subscribe form tag and subscriber lookup). That is a low-friction fit inside a Laravel service container and does not introduce a parallel configuration or caching paradigm.

Integration feasibility. Expected path is composer require siterig/statamic-mailerlite, publish config, set a MailerLite API token in .env, and consume tags in templates. This is a well-trodden pattern and should be deliverable inside a single sprint.

Technical risk. The v2.0.1 release is a patch containing "package update and vulnerability fixes" plus documentation. Three risks are material and are not resolvable from the release notes alone:

1. Unidentified security exposure. "Vulnerability fixes" is unnamed — no CVE, no advisory link, no indication of whether the vulnerable code was in this addon, in the MailerLite SDK, or in a transitive dependency (Guzzle, symfony/*). The blast radius differs enormously between those cases. If it is a transitive dependency, composer update alone may resolve it without adopting this release.
2. Maintainer concentration. A single-maintainer repository with a small release surface. The v2.0.0 → v2.0.1 patch cadence suggests reactive rather than scheduled maintenance.
3. Version coupling. Statamic has aggressive major-version turnover; addons frequently lag. The v2 major bump implies a prior breaking change (likely Statamic 4/5 or MailerLite API versioning) whose specifics we cannot confirm from a patch note.

Confidence in this assessment is low-to-moderate — it is derived from release notes only, with no composer.json, no diff, and no advisory record.

Key questions.

• Which CVE/advisory does the vulnerability fix address, and is it exploitable in our intended configuration?
• What are the exact composer.json constraints for statamic/cms, laravel/framework, and PHP?
• Does v2 target MailerLite API v2 or v3, and is the older surface deprecated?
• Is the addon actively maintained — commits in the last 6 months, issues triaged?
• Does it ship webhook support (bounce/unsubscribe sync), or is it write-only?
• What does v2.0.0's breaking change set contain, in case we must start from v1?

Integration Approach

Stack fit. Target a Laravel 10/11 + Statamic 4/5 runtime on PHP 8.1+. The package is additive — it does not touch the Eloquent layer, queue configuration, or auth. It slots in alongside existing mail infrastructure, so it should not collide with laravel/mail transports (this is list management, not transactional sending).

Migration path. Two distinct cases:

• Already on v2.0.0 — this is a drop-in patch. Run composer update siterig/statamic-mailerlite, verify the lockfile picks up the patched dependency tree, and clear Statamic's cache (php artisan statamic:stache:clear). No template or config changes expected, but the README was touched in the same release, so diff the config reference.
• On v1.x or greenfield — treat v2 as a new integration, not an upgrade. Read the v2.0.0 changelog before committing; the major bump almost certainly carries config key or tag-signature changes.

Compatibility. Verify the resolved dependency graph in a throwaway branch before merging. Specifically confirm the patched transitive dependency version is actually selected — Composer will happily keep an older locked version if constraints elsewhere pin it. composer why-not on the affected package is the fast check.

Sequencing.

1. Confirm the advisory identity and severity; determine whether a direct dependency override fixes it without this release.
2. Branch, bump, run composer update, inspect composer.lock diff.
3. Smoke-test in staging: form submission creates a MailerLite subscriber; API failure path renders an error; config cache builds cleanly.
4. Security review of the diff, given the vulnerability framing.
5. Canary to production, then full rollout.

Pin to ^2.0.1 rather than ^2.0 so the security fix is a floor, not a hope.

Operational Impact

Maintenance. Expect to own the dependency yourself. A solo-maintainer addon with ad-hoc releases means Statamic upgrades may outpace the addon. Budget a recurring check each Statamic minor release and each Composer audit cycle (composer audit in CI will surface this class of issue early — recommend adding it if not present). Forks should be anticipated; keep the integration surface thin (config + templates, no forked source) so a swap is cheap.

Support. GitHub issues only, no SLA, no commercial backing apparent. Escalation path is your own engineers. Document the internal owner explicitly.

Scaling. The binding constraint is MailerLite's API rate limit, not the addon or PHP. Any subscriber-sync or bulk operation should run through queued jobs with backoff and idempotency keys, not synchronous request-time calls. Cache subscriber-status lookups — templates that hit the API per render will degrade badly under traffic. Form endpoints are bot targets: pair with honeypot/rate limiting at the edge.

Failure modes.

• Token expiry or rotation — silent failure on subscribe forms unless errors are surfaced. Add monitoring on submission failure rate.
• MailerLite outage or rate-limit 429 — decide now between fail-open (log and continue) and fail-closed (show error to user). For newsletter opt-in, fail-open with a queued retry is usually correct.
• Unpatched transitive dependency — the current scenario; mitigated by composer audit in CI.
• Statamic major upgrade — addon incompatibility surfaces as a broken service provider at boot, taking the whole app down. Pin Statamic and the addon together in the lockfile.
• Compliance — subscriber PII and consent records flow to a third-party processor. Confirm a DPA with MailerLite and that consent capture meets GDPR/CAN-SPAM requirements; the addon will not handle this for you.

Ramp-up. Low for anyone already fluent in Statamic — roughly half a day to publish config, wire tags, and validate a submission. Add a day if queue-based sync and error handling are in scope. Engineers without Statamic experience should budget for Antlers syntax and the Stache caching model, which are the actual learning curve, not this package.