Export Command Laravel Package

Product Decisions This Supports

• Replatforming / exit-cost decisions. WXR is the standard interchange format WordPress importers understand. If we're weighing "stay on WordPress" vs. "move content into our Laravel app or another CMS," this package turns that from a bespoke engineering project into a scripted command. That materially changes the build-vs-buy and stay-vs-migrate calculus.
• Scope-cutting for migrations. Filters on post type, status, author, category, and date range let us decide what content is in scope — e.g., "migrate published posts and pages only, last 24 months, exclude drafts and custom types." That's a product decision about content surface area, and it's testable cheaply before committing to a migration timeline.
• Backup and staging-refresh strategy. If we operate WordPress anywhere in the estate, this enables a repeatable, automatable snapshot of content as a CI/cron step rather than a manual admin-dashboard export. Supports the decision to treat content as a versioned, portable asset instead of something trapped in a database.
• Content audits and editorial operations. Per-author or per-category exports give editorial and marketing a way to pull slices of content for review, archival, SEO audits, or syndication without DB access.
• Tooling investment sizing. Because it's a single command with a stable output format, we can decide not to build an in-house exporter UI and instead invest the saved effort in the importer side, where the real product risk lives.
• Roadmap gating for the Laravel side. If the plan is "ingest WordPress content into Laravel," this defines the upstream contract (WXR) we'd build against — useful for deciding whether to build a WXR parser/importer now or defer.

When to Consider This Package

Adopt when:

• We operate at least one WordPress site and already use WP-CLI (or are willing to), so the marginal cost is near zero.
• We need scriptable, repeatable exports for migrations, staging refreshes, or backups — not one-off manual downloads.
• We need selective exports (by post type, status, author, category, or --start_date/--end_date) rather than a full dump.
• We need standard WXR specifically, because the receiving end is a WordPress importer or a tool that already understands WXR.
• MIT licensing and no vendor lock-in matter to us.

Look elsewhere when:

• There is no WordPress in the stack. This is a WP-CLI command, not a Laravel package — it has no place in a Laravel app's composer.json as a runtime dependency. In a pure Laravel product, treat it as an ops-side tool at best, and it's irrelevant otherwise.
• We need fidelity WXR doesn't give. WXR is content-oriented: it does not carry users/passwords, options, plugin tables, WooCommerce orders, custom tables, or guaranteed post IDs. Any decision requiring byte-level DB reproduction should use mysqldump/replication, not this.
• We need media binaries. WXR references attachment URLs; it does not bundle the files. Sibling tooling is required.
• We need incremental/delta sync. There's no reliable cursor-based "changed since" export; date-range filtering on post dates is not a substitute for change-data-capture.
• We need a GUI or a supported commercial SLA. This is a community WP-CLI component; non-technical stakeholders cannot self-serve with it.
• Registry signals are a concern. 13 stars and a release dated in the future (2026-08-04) suggest the registry metadata is unreliable. Verify actual maintenance cadence and that it ships/bundles with the WP-CLI version we'd standardize on before treating it as a dependency. Low stars here understate real usage — this is a WP-CLI satellite package, historically bundled — but confirm rather than assume.

How to Pitch It (Stakeholders)

To executives: This is a free, MIT-licensed command that lets us pull our WordPress content out in a standard, portable format, on demand, from a script. Its strategic value is reduced lock-in: it lowers the cost and risk of ever moving off WordPress, and it makes backups and staging refreshes routine rather than manual. There's no license cost and no vendor negotiation — the decision is whether we want that option available, and the answer is almost always yes.

To engineering: It's wp export from WP-CLI — one command, filterable by post type, status, author, category, and date range, emitting standard WXR that existing importers already parse. It composes cleanly into cron jobs and CI pipelines, adds no runtime dependency to the Laravel application, and requires nothing beyond PHP and WP-CLI on the WordPress host. Be explicit about the boundaries so nobody is surprised later: WXR is content, not a database snapshot — no users, options, plugin tables, custom tables, or media binaries, and no incremental sync. If we need any of those, we plan for them separately (DB dump, media sync, or a custom extractor) rather than stretching this tool. The 13-star count is a distribution artifact, not a quality signal, but we should pin a WP-CLI version and confirm the package's release cadence before scripting it into anything critical.