Wp Import Laravel Package

Technical Evaluation

Package: statamic-rad-pack/wp-import v1.7.2 — a Statamic addon that imports WordPress content (posts, pages, custom post types, terms/taxonomies, media) into Statamic collections, taxonomies, and asset containers.

Architecture fit: The addon is a conventional Laravel package: a service provider registers an import command and config, and the importer maps WP entities onto Statamic's content model (collections → entries, WP taxonomies → Statamic taxonomies, WP media → asset containers). It sits entirely at the migration boundary of a Statamic build — it is not a runtime dependency, which is the key architectural fact for a TPM: it can be scoped, run, verified, and removed without touching production application code. That makes it a low-blast-radius tool to adopt, but also means it delivers no ongoing product value once migration is complete.

What v1.7.2 changes: A single commit, "Update term/taxonomy import," merged from a first-time contributor. Patch-level version bump. No deprecations, no config signature changes, no breaking changes announced. The change is scoped to taxonomy/term handling — i.e., the mapping of WP categories, tags, and custom taxonomies into Statamic taxonomies. This is the highest-fidelity-risk area of any WP→Statamic migration (hierarchical vs. flat terms, slug collisions, orphaned terms, term meta), so even a small fix here is materially relevant to migration correctness, but the release note gives no detail on whether it is a bug fix, an edge-case handling change, or a behavioral correction.

Technical risk: Low-to-moderate. Low because the change is a patch release in a narrow subsystem and the package is a build-time/one-off tool. Moderate because (a) taxonomy import bugs tend to surface as silent data problems — missing terms, flattened hierarchies, duplicated slugs — that only appear when editors work with content post-migration; (b) the release note is not self-describing, so we cannot say which behavior changed; and (c) the project appears to be maintained by a small team (rad-pack) with no visible LTS or support commitment.

Key questions to resolve before relying on it:

1. What exactly did PR #13 change — bug fix, new edge-case handling, or altered default behavior for hierarchical terms?
2. Does the fix alter output for previously-working imports (i.e., do we need to re-run or re-verify an already-completed migration)?
3. Which WP taxonomies are supported: core categories/tags only, or registered custom taxonomies with term meta?
4. Is the import idempotent/re-runnable, and how does it handle existing terms with matching slugs?
5. What is the project's maintenance posture — release cadence, open-issue backlog, tested Statamic/Laravel/PHP version matrix?

Integration Approach

Stack fit: Purpose-built for Statamic (running on Laravel), so it inherits the host application's PHP and Laravel constraints rather than imposing its own. Confirm the addon's declared support matrix against our pinned Statamic major, Laravel version, and PHP runtime before committing — that is a five-minute check and the single highest-value pre-adoption gate.

Migration path: Adopt via Composer and pin explicitly ("statamic-rad-pack/wp-import": "1.7.2") rather than floating a caret range, so a mid-migration patch cannot change import behavior underneath an in-flight content transfer. Because this is a v1.7.x patch, upgrading from v1.7.1 is semver-compatible and requires no code changes — but for a taxonomy fix, "no code changes required" does not mean "no output changes required."

Compatibility and verification: The concrete acceptance step for v1.7.2 is a differential test: run the importer against a representative WP export on v1.7.1 and v1.7.2 and diff the resulting term/taxonomy structure (term counts, hierarchy depth, slugs, parent relationships, associations to entries). If the outputs differ, we need to know whether the new output is the correct one before proceeding. If a migration has already been executed on v1.7.1, this diff determines whether a corrective re-import is warranted.

Sequencing:

1. Pin v1.7.2 in a non-production environment; verify version matrix.
2. Build a fixture WP dataset that deliberately includes nested categories, duplicate term names across taxonomies, unicode/slug-normalized terms, and unattached terms.
3. Run the differential comparison described above.
4. Validate term→entry associations, not just term creation — association loss is the failure mode that survives casual inspection.
5. Only then run against staging with production-shaped content, and schedule production during a content freeze.

Dependency ordering within the import itself matters: taxonomies/terms should be established before entries are created so associations resolve on first pass, with a second pass to reconcile links and media. Treat the importer as a pipeline to be ordered and re-run, not a single atomic action.

Operational Impact

Maintenance: The package is a migration tool, not a permanent platform component — plan to remove it from composer.json after the migration is validated and archived. That said, retaining it in a dev-only or require-dev context can be useful for re-imports or content refreshes. The arrival of a new external contributor is a mildly positive maintenance signal (broader contributor base), but one merged PR does not change the underlying concentration risk in a small-team addon.

Support: Expect GitHub-issue-level support with no SLA. TPM action: designate an internal owner for this tool during the migration window, and capture the mapping decisions (which WP taxonomies map to which Statamic taxonomies, how unmapped terms are handled) in a document the content team owns — not in the vendor's issue tracker.

Scaling: Import runtimes scale with total content volume and, critically, with the number of term→entry associations. Large sites (tens of thousands of posts, deep taxonomy trees) will be bounded by PHP memory limits and per-request execution time. Budget for batch sizing, queue-backed or chunked execution, and a runbook that specifies how to resume a partially completed import. Do not plan a large-site migration on the assumption of a single uninterrupted command run.

Failure modes to instrument for:

• Silent taxonomy degradation — terms created but hierarchy flattened, or terms dropped without error. Mitigation: post-import assertion comparing WP term counts per taxonomy against Statamic term counts.
• Association loss — terms exist but entries are not attached. Mitigation: sample-verify entries across each collection and taxonomy depth.
• Slug collisions and duplicates — repeated runs creating duplicate terms. Directly tied to the idempotency question above; test by running the import twice.
• Partial completion — process dies mid-run leaving an inconsistent state. Mitigation: run in staging first, snapshot the database, and maintain a documented reset procedure.
• Version drift — an unpinned patch altering import behavior mid-project. Mitigation: exact version pinning plus a lockfile committed for the migration branch.

Ramp-up: Developer effort to install and execute the importer is low — hours, not weeks. The real ramp-up cost is editorial and informational: someone must decide the taxonomy mapping, define what happens to unmapped or empty terms, and validate output with actual editors. Budget that as a half-day to a day of content-team time, and treat it as a prerequisite rather than a post-hoc QA step. The v1.7.2 change lands squarely in that decision area, so the mapping review should be scheduled alongside the version upgrade rather than after it.

Overall TPM read: v1.7.2 is a low-risk patch that is safe to adopt and worth adopting, because it improves the least trustworthy part of a WP→Statamic migration. It does not, however, change the package's strategic profile: it remains a small-team, single-purpose migration utility that should be pinned, verified with a differential test, and retired after cutover. The one non-negotiable follow-up is obtaining the substance of PR #13 — the release note alone is insufficient to sign off on taxonomy behavior in a production migration.