Shopify Laravel Package

Technical Evaluation

Architecture fit — This is a Statamic add-on (a Laravel package) that bridges a Statamic site to Shopify: catalog/product sync, order and customer ingestion, webhooks, and storefront/control-panel surfaces. It is not a general-purpose Laravel library, so fit is scoped to teams running Statamic 4/5 on Laravel 10/11. v8.0.0 replaces the underlying Shopify client with the official shopify/shopify-app-php package. Architecturally that is the right direction — it moves a bespoke HTTP/auth layer onto a vendor-maintained one — but it is a full replacement of the layer that handles credentials, request signing, and API transport, which is the riskiest part of an e-commerce integration.

Integration feasibility — Feasible for a standard deployment, but not a drop-in. The swap plausibly touches: how the API client/session is constructed, OAuth and session-token handling, webhook HMAC verification, config keys (config/shopify.php shape), and the namespaces of any classes the host app or custom add-ons extend. Whether it is a same-day upgrade or a multi-day project depends on how much custom code sits on top of the package's internals.

Technical risk — High-to-moderate. A major version bump combined with an SDK substitution is a textbook breaking change; semantic versioning here should be read literally. Specific risks:

• Auth model shift. Official Shopify SDKs assume the OAuth + session-token app model. If the previous implementation supported legacy custom-app API password/access-token flows, those installs may need re-authorization or reinstallation, and the config surface may no longer accept the old credentials.
• Dependency graph. shopify/shopify-app-php carries its own PHP and Guzzle/PSR constraints. Composer resolution against an existing Laravel/Statamic lockfile is a plausible blocker, especially with pinned Guzzle versions from other packages.
• Verification behavior. Webhook signature validation and request authentication implementations differ between SDKs; a mismatch here fails closed (401s) or, worse, fails open.
• Silent behavioral drift. Pagination/cursor semantics, rate-limit handling and retry behavior change with the transport layer — syncs may still "work" but with different throughput or partial-result characteristics.

Key questions

1. Is the v7 → v8 upgrade a config-only change, or does it require re-installing/re-authorizing the Shopify app for each store?
2. Are stored credentials (access tokens, API passwords) migrated automatically, or must they be reissued?
3. What are the exact PHP/Laravel/Statamic and shopify/shopify-app-php version constraints, and does the lockfile resolve cleanly?
4. Which public classes, config keys, events, and DB columns changed or were removed?
5. Is a multi-store / multi-connection setup still supported, and does each store hold its own session?
6. Is there a documented upgrade guide and a stated support window for the 7.x line?

Integration Approach

Stack fit — Assumes PHP 8.1+ (likely 8.2+ given the official SDK), Laravel 10/11, Statamic 4/5, and a queue worker for sync jobs. Confirm before committing; a PHP floor bump alone can cascade into infrastructure changes.

Migration path — Treat as a planned upgrade, not a patch:

1. Branch and pin statamic-rad-pack/shopify to 8.0.0 in a staging environment with a non-production Shopify store.
2. Run composer update statamic-rad-pack/shopify --with-dependencies and inspect the full dependency diff, not just the package line.
3. Republish/compare config; diff the v7 config against the v8 default and reconcile auth keys.
4. Exercise the full lifecycle: app install/OAuth, product sync, order webhook receipt, customer sync, and control-panel listing.
5. Only then promote, with 7.13.1 retained as a rollback pin in the lockfile.

Compatibility — Highest-risk areas are custom code extending package classes, custom webhook endpoints, and any stored credential format. Also check multi-site/multi-store installs and any cached config (config:cache) that would hold stale auth keys. Third-party add-ons depending on this package's internals may not yet declare v8 support.

Sequencing — Do the dependency resolution check first (cheap, can kill the project). Then auth/reinstall validation (this is where most teams get stuck). Then sync correctness, then throughput. Defer production cutover until webhook verification and at least one full product+order cycle have been observed end-to-end.

Operational Impact

Maintenance — Net positive long-term: the official SDK absorbs Shopify API version churn, which is otherwise a recurring bespoke maintenance tax. The trade-off is a new upstream release cadence you don't control, and a second vendor to track for security advisories.

Support — Expect a support spike at rollout: users hitting re-authorization prompts, stale-credential errors, and "my products stopped syncing" reports that are actually auth failures. Pre-write the reinstall/re-auth runbook and a customer-facing note before shipping. Internal support familiarity with the official Shopify app model (OAuth, session tokens, embedded app expectations) is a prerequisite, not a nice-to-have.

Scaling — Re-verify rate-limit behavior and concurrency under the new transport. If the SDK introduces stricter or differently-shaped throttling, large catalogs may sync slower or need batch-size retuning. Queue-backed syncs should be load-tested at realistic catalog size rather than assumed equivalent to v7.

Failure modes

• Expired or invalid session token → auth errors on API calls; distinguish from Shopify-side outages in monitoring.
• Webhook signature verification mismatch → dropped or 401'd webhooks, meaning orders silently missing; needs an alert on webhook failure rate, not just job failure.
• Composer conflict at deploy → build fails or, worse, resolves an unexpected transitive version; lock the graph and diff it.
• Partial credential migration → some stores work, others don't; verify per-store, not once.
• Cached config holding v7 keys → app boots but auth fails; clear and rebuild caches as a deploy step.

Ramp-up — Moderate. The package's own surface is small; the learning cost sits in the official Shopify app model and in the upgrade guide's gaps. Budget a day of engineering for the dependency + auth investigation, and a second for full-cycle validation in staging. If v8 ships without a migration guide, treat that absence itself as a risk signal and read the PR (#358) and CHANGELOG directly.