Wp Caper Laravel Package

Technical Evaluation

Architecture fit. alleyinteractive/wp-caper is a WordPress-side content query and extraction library (Caper\Query, Caper\Object, importer/CLI tooling), not a native Laravel package. It has no service provider, no facades, and no Laravel integration surface. Its architectural value to a Laravel estate is as the source-side half of a migration pipeline: it runs inside the WordPress runtime, produces normalized content, and a Laravel consumer (console command, queued job, or ingestion endpoint) persists it into Eloquent models. Treat it as an upstream data contract, not a dependency of the Laravel application.

v3.0.0 significance. The release note is a bare pointer to the changelog — no inline detail was supplied. A major version increment under semver is a strong signal of breaking changes: expect renamed or removed classes, changed query-builder signatures, altered importer interfaces, raised PHP/WordPress version floors, and dependency bumps (notably illuminate/collections, which is the most likely source of conflict with a modern Laravel app). Do not assume any of the existing 2.x call sites survive unchanged.

Integration feasibility. Feasible but indirect. Two viable patterns: (a) run Caper inside WordPress via WP-CLI and emit NDJSON/JSON to object storage, then ingest from a Laravel job; (b) expose a thin authenticated endpoint in WordPress that Laravel pulls from. Do not attempt to bootstrap WordPress inside a Laravel process — that path is fragile and unsupported.

Technical risk.

• Unverified changelog: the upgrade guide and breaking-change list are the single largest unknown and must be read before any estimate is credible.
• Silent content drift: a changed relationship traversal, meta normalization, or term ordering will not fail loudly — it will produce subtly wrong migrated records.
• PHP/WordPress floor changes may strand older but still-live WordPress installs in the estate.
• Dependency graph overlap with Laravel if both live in one monorepo (Collection major-version collision).

Key questions.

1. What are the new minimum PHP and WordPress versions?
2. Which public APIs (Query, Object, importer, WP-CLI commands) changed or were removed?
3. Is there a documented upgrade guide, and is there a codemod or Rector ruleset?
4. Did the normalized output schema change (field names, meta flattening, media references)?
5. Did illuminate/collections or the WordPress Fields API move a major version?

Integration Approach

Stack fit. Pin the package to the WordPress codebase, not the Laravel application. The Laravel side should only ever see a versioned, documented export schema (NDJSON records or a JSON payload with a schema_version field). Caper's internal API is an implementation detail of the WordPress tier.

Migration path.

1. Freeze the current 2.x export output on a representative content fixture (posts, custom post types, taxonomies, meta, media, relationships).
2. Read the v3.0.0 changelog and upgrade guide; produce a written breaking-change inventory mapped to our call sites.
3. Branch the WordPress codebase, upgrade in an isolated environment, resolve API changes.
4. Re-run the export against the same fixture set and diff against the 2.x baseline, field by field.
5. Only after a clean diff, promote to staging and re-run the Laravel importer against staging data.

Compatibility. Laravel version compatibility is largely irrelevant unless Caper shares a Composer lockfile with the app. If it does, resolve the illuminate/collections constraint first — that is the most probable blocker. Verify the WordPress-side PHP version against each site in the estate before scheduling the rollout.

Sequencing. Do not upgrade Caper and change the Laravel importer in the same release. Land the WordPress-side upgrade behind a pinned lockfile, validate output parity, then adjust the importer in a follow-up. Keep a 2.x branch available for rollback through at least one full migration cycle.

Operational Impact

Maintenance. Small, single-vendor OSS project with an infrequent release cadence — major versions may land years apart. Assume no deprecation runway between majors. Budget an internal owner and a fallback plan to fork or vendor the package if upstream stalls.

Support. GitHub issues only; no SLA, no commercial support. Escalation is "read the source." Factor this into on-call expectations for the migration pipeline.

Scaling. Throughput is bounded by WP_Query and WordPress's memory ceiling, not by Laravel. Use batched, paginated, resumable exports with explicit chunk sizes; run under WP-CLI with elevated memory limits. The Laravel importer must be idempotent (upsert keyed on a stable WordPress ID) so a failed batch can be safely replayed.

Failure modes.

• Partial exports that look complete → enforce a record-count and checksum at the end of each run.
• Silent field-mapping drift → schema-version the export and fail the importer on unknown versions.
• Memory exhaustion or timeouts on large sites → chunk and checkpoint.
• Duplicate content on re-run → idempotent upserts, never blind inserts.
• Orphaned or mismatched media → reconcile attachment IDs separately from post records.

Ramp-up. Productive work requires engineers fluent in both WordPress internals and Laravel. Estimate one to two sprints for a mid-level engineer to operate the pipeline unsupervised. The highest-leverage artifact is a written field-mapping contract between the Caper export and the Eloquent models — without it, every upgrade becomes an archaeology exercise.

Recommendation. Proceed with a scoped evaluation, not a rollout. The v3.0.0 major bump is exactly the moment to re-baseline the export and confirm parity, but the decision to adopt should be gated on the changelog contents, which were not available for this review. Until the breaking-change list is in hand, hold at 2.x and treat the upgrade as unscheduled work.