Wordpress Importer Laravel Package

Product Decisions This Supports

This is not a Laravel package — it is the official WordPress plugin (GPL-2.0, 89 stars, low opportunity score) that defines how a WXR export file is parsed and materialized into content. Its PM value is as a specification and effort benchmark, not as a dependency.

• Build vs. buy for onboarding migration. Every WordPress-based prospect is a switching-cost problem. This package lets you scope "self-serve WXR import" against the real unit of work — authors, post types, taxonomies, threaded comments, serialized postmeta, attachment sideloading, and ID remapping — instead of the happy path of "parse some XML."
• Fidelity tiering on the roadmap. It gives you a concrete ladder: content-only → content + media → content + media + SEO/meta + menus + redirects. Each tier maps to a measurable activation and churn-reduction bet, and to a support-load estimate.
• Whether to ship import as a growth lever. Importing is a top-of-funnel feature for a WordPress-adjacent ICP. This package tells you the long tail (malformed XML, huge sites, missing media) is where the cost lives, which is the argument for a managed/"white glove" tier rather than fully self-serve v1.
• Data model and schema pressure. Postmeta is schemaless key/value; if your Laravel models are rigid, the importer becomes a forcing function for a flexible metadata column or a JSON meta table. Decide that before you commit to import.
• SEO preservation as a product requirement. WXR carries permalinks and GUIDs; the importer's behavior around them frames the redirect-mapping requirement, which materially affects whether migrating customers keep their traffic.
• Interchange format strategy. If WXR is your ingest format, you inherit a de facto standard and its edge cases rather than inventing one — and you get a free escape hatch (export to WXR) that reduces buyer lock-in anxiety.

When to Consider This Package

Consider it when:

• You need to ingest WordPress content into a Laravel app and want an authoritative read on WXR semantics before estimating. Read the source; do not composer require it.
• You are writing an ADR on import fidelity, and need to enumerate edge cases honestly rather than guess.
• You are scoping media sideloading, author mapping, and comment threading — the parts teams consistently underestimate.
• You need a behavioral reference for a specific bug class: duplicate imports on re-run, term hierarchy ordering, serialized PHP payloads in postmeta.

Look elsewhere when:

• You want a Laravel-native importer (jobs, queues, chunking, S3 disks, Eloquent upserts). This package has none of that and is coupled to WordPress runtime functions.
• GPL-2.0 is incompatible with your distribution model. Bundling or deriving from this code into a closed-source SaaS is a legal review, not a sprint task. Safer: treat it as documentation, or isolate any reuse behind a process boundary.
• You need delta/incremental sync or two-way sync. This is one-shot, full-import by design.
• Your targets are large sites (100k+ posts, GBs of media). The plugin's importer is historically fragile under PHP time/memory limits; WP-CLI or a custom chunked pipeline is the real answer.
• You need non-WXR sources (Contentful, Drupal, CSV, Notion) — no leverage here.
• You need active upstream momentum. 89 stars and a low opportunity score say "maintained, not evolving." Don't plan around new capabilities.

How to Pitch It (Stakeholders)

Bottom line: do not adopt as a dependency; use it as a spec and an effort yardstick.

• For executives: WordPress migration is a recurring sales objection and a churn-reducer. This package is the industry-standard definition of what "import" must handle, so it de-risks our estimate. It does not reduce the build — it prevents us from under-scoping it. Licensing is GPL-2.0, so it informs our design rather than shipping inside our product.
• For engineering: treat it as a reference implementation. Reimplement the parsing and mapping in Laravel using queued, idempotent, resumable jobs with per-entity checkpoints. Steal its edge-case list — author mapping, term hierarchy, serialized meta, attachment sideload, ID remap, re-run safety — and discard its execution model.
• Recommendation: run a two-week spike against three real customer WXR files (small, medium, ugly) to convert this into a defensible estimate and a fidelity-tier proposal. Decide build vs. managed-service after the spike, not before.
• Risk to flag: the cost is not the parser, it's the long tail. Budget support capacity and a "we'll migrate it for you" tier for anything above the median file.