Import Command Laravel Package

Product Decisions This Supports

• Framework reality check first: despite the brief describing a "Laravel/PHP package," this is a WP-CLI command for WordPress (wp import <file.wxr>), distributed via Composer as a WP-CLI package. It is PHP, and it can live in the same monorepo/CI pipeline as a Laravel app, but it is not a Laravel package and has no service provider, facade, or Laravel-native API. Treat any Laravel leverage as adjacency, not integration.
• Content migration strategy: the core decision it informs is "how do we move content between WordPress instances, or off WordPress into our Laravel product?" It gives you a scripted, repeatable WXR ingest step rather than a human clicking through the WordPress importer UI — which is the difference between a migration you can rehearse and one you can't.
• Build vs. buy (narrowly): for WXR-shaped input, this is closer to "adopt" than "build" — it already handles posts, pages, comments, taxonomies, authors, and attachment references, plus author remapping and selective skipping. Writing that parser in-house is a multi-week task with a long tail of edge cases (serialized meta, duplicate slugs, orphaned attachments).
• Roadmap input for a headless/decoupled architecture: if you're running WordPress as a content backend behind a Laravel API, this is a viable one-time cutover tool when you eventually consolidate onto Laravel-native content tables. It also serves as a reference implementation for what a WXR parser must handle if you decide to build the Laravel-side importer.
• Use cases worth scoring: agency/portfolio site consolidations, staging→production content promotion, blog-network merges, re-platforming a marketing site, and seeding demo/test content into non-production environments.
• Signal quality caveat for the roadmap: 22 stars and an "opportunity" score of 0.43 say this is a maintenance-mode utility from the WP-CLI org, not an actively marketed product. That's acceptable for a one-shot migration dependency and unacceptable as a long-lived integration surface.

When to Consider This Package

Adopt when all of these hold:

• You operate WordPress and have WP-CLI available in the target environment (it is a hard prerequisite — this is not usable from Laravel's HTTP layer).
• The migration is batch and one-directional, and a short maintenance window or a read-only content freeze is acceptable.
• Your source data is already WXR (WordPress export XML) or can trivially become it.
• You want the migration to be idempotent-ish and re-runnable in CI/staging rather than a manual runbook.
• You're comfortable with MIT licensing and pinning a version, because upstream activity is thin.

Look elsewhere when:

• You need incremental or bidirectional sync — this is a bulk importer, not a replication tool.
• You need rich custom field / ACF / relationship remapping beyond what the command exposes; you'll be writing a companion script anyway.
• You need transactional rollback, dry-run diffing, or per-record validation reporting — you'll be building those on top.
• The source isn't WordPress (CSV, JSON, Contentful, legacy CMS) — use a Laravel-native importer (maatwebsite/excel, custom artisan commands, spatie/laravel-data for mapping) instead.
• You need vendor support or SLAs — this has neither.
• Volume or content model complexity is high enough that a purpose-built ETL with an audit table is cheaper than debugging a black-box CLI.

How to Pitch It (Stakeholders)

To executives — the one-liner: "It's a free, MIT-licensed command-line tool that moves existing WordPress content into a new environment without manual copy-paste, which de-risks and shortens a re-platforming or site-consolidation project. Cost is essentially zero; the risk is that it's a small, low-activity open-source utility, so we budget a spike to validate it against our actual content before committing."

To engineering — the honest framing: "It's wp-cli/import-command, a WP-CLI package, not a Laravel dependency. We'd install it as a pinned Composer package in a WordPress context and drive it from a script or CI job. It handles the boring 80% of WXR parsing; we own the mapping config, validation, and rollback story. Before we build anything bespoke, spend a day running a real export through it and tell me where it breaks."

Framing to avoid: presenting this as a Laravel integration. The first question from any engineer will be "where's the service provider?", and the honest answer — "there isn't one, and there shouldn't be" — is better delivered up front than discovered in sprint planning.