Export Command Laravel Package

Technical Evaluation

What the package actually is. wp-cli/export-command is not a general-purpose PHP library — it is a WP-CLI command bundle. It registers the wp export subcommand and depends on a bootstrapped WordPress runtime (WP_Query, wpdb, post type/taxonomy registries, pluggable functions). There is no public PHP API, no service provider, no PSR-compatible interface, and no events. Its only contract is: exit code, stdout, and a WXR file on disk.

Architecture fit. Poor for a pure Laravel application; reasonable for a hybrid WordPress + Laravel estate. The only viable integration shapes are:

1. Sibling process — WP-CLI installed in the same container/host as a WordPress instance; Laravel invokes wp export via Symfony\Process from a scheduled command or queued job.
2. Pipeline stage — cron/CI exports WXR, a Laravel job ingests and normalizes it into Eloquent models.
3. Anti-pattern to avoid — adding this to composer.json of a Laravel app and attempting to call it in-process. It will pull wp-cli/wp-cli and a pinned symfony/console, which conflicts with Laravel's console component and offers no benefit.

Integration feasibility. Low-to-moderate effort if a WordPress runtime already exists and we own it. The command surface is straightforward and well-suited to automation (--post_type, --status, --author, --category, --start_date, --end_date, --dir, --filename). If there is no WordPress runtime in the target environment, this package is not integrable — the work becomes "stand up WordPress," which is a different project.

Technical risk.

• Runtime coupling (high). The exporter reads WordPress internals directly. Custom post types only appear if their registering plugins/themes are active in the CLI context. Silent omission is the most dangerous failure mode.
• Composer conflict (medium). Duplicate symfony/console constraints versus Laravel. Mitigate by installing WP-CLI as a PHAR, not a Composer dependency.
• Duplicate command registration (medium). wp export has historically shipped inside WP-CLI core. Loading this package alongside a modern WP-CLI can raise "command already defined" or shadow the built-in implementation — load order and version pinning must be verified in a spike.
• Monolithic output (medium). One invocation produces one WXR file. No resumability, no streaming consumer contract. Large sites require manual chunking by date window or post type.
• WXR fidelity (medium). Serialized postmeta, attachments (referenced by URL, files not included), and CDATA-encoded content:encoded are the classic re-import corruption points.

Key questions for the team.

1. Is a WordPress runtime in scope at all, and who owns it operationally?
2. Single site or multisite? Multisite changes the invocation model (--url per site).
3. What is the content volume, and what is the largest single post type by row count?
4. Do we need one-time migration or recurring delta sync? The delta story is weaker (date filters only, no tombstone/deletion signal).
5. What is the destination — WordPress, or Laravel/Eloquent? If Laravel, WXR is an interchange format we must parse ourselves; that cost dominates.
6. Are media assets in scope? This package exports references only.
7. Who patches if a WordPress core upgrade breaks the command?

Integration Approach

Stack fit. PHP 7.4+/8.x, Composer-installable, MIT. Best consumed as a runtime tool inside a WordPress container image, not as an application dependency of the Laravel codebase. Recommended shape:

app (Laravel)  --Process-->  wp-cli container  --writes-->  shared volume (WXR)
       \-- queued ingest job reads WXR from shared volume / S3

Migration path. None for existing Laravel data — WXR is WordPress-native. The real migration work is the WXR → Eloquent mapping layer:

Compatibility.

• Pin WP-CLI to a tested minor version; verify whether wp export is already bundled before loading this package.
• Pin the WordPress core version in the source environment and re-run the export smoke test on every core upgrade.
• Ensure all CPT/plugin code is loaded in the CLI context (WP_CLI constant guards often short-circuit plugin logic — audit for this).
• Confirm PHP CLI memory limit and max_execution_time on the exporter host.

Sequencing.

1. Spike (2–3 days): confirm command availability, run a filtered export on staging, validate XML well-formedness and item counts against wp post list --format=count.
2. Containerize (1 sprint): WP-CLI + WordPress runtime image, shared volume or S3 sink, secrets for DB access, atomic write + checksum.
3. Ingest job (1–2 sprints): queued Laravel job parsing WXR with an XMLReader (streaming, not SimpleXML on large files), idempotent upserts keyed on wp:post_id, dead-letter handling.
4. Delta schedule: --start_date watermark stored per site; daily or hourly cadence depending on freshness requirement.
5. Cutover: dual-run with row-count and spot-check reconciliation, then flip read traffic.

Operational Impact

Maintenance. Small code surface, MIT license, WP-CLI org stewardship — but only 13 stars signals near-zero independent adoption. The command is effectively maintained as part of WP-CLI core, so version drift is the primary maintenance concern, not feature churn. The stated last release of 2026-08-04 should be treated as unverified metadata and confirmed against Packagist before planning. Budget ~1–2 days per WordPress minor upgrade for regression testing.

Support. Community-only: GitHub issues and WP-CLI Slack. No SLA, no vendor. We own the pipeline end-to-end, including patches. Bus factor is small; institutional knowledge must be documented rather than assumed.

Scaling characteristics.

• Single-process PHP CLI; memory ceiling is the binding constraint, not CPU.
• No incremental/streaming output — cost scales linearly with content volume and is dominated by DB read + XML serialization.
• Chunking strategy: partition by --post_type × date window (e.g. monthly) to bound file size and enable parallel export of independent types.
• File size and disk I/O: expect multi-GB WXR for media-heavy corpora; plan storage and transfer accordingly.
• Media is not exported — a parallel rsync/S3 sync is a hard dependency for any usable migration.

Failure modes to instrument.

Ramp-up. Low for the exporter itself — anyone fluent in WP-CLI is productive in half a day. The asymmetrical cost is the consumer side: a robust WXR ingest in Laravel is 1–2 sprints including serialization quirks, media, and idempotency. Plan and staff accordingly; the package is the cheap half of the project.

Recommendation. Conditional adopt. Justified only when a WordPress runtime is already owned and the requirement is content egress from it. It is not a Laravel package, should not enter the Laravel composer.json, and should be treated as an external CLI tool with a thin, well-instrumented contract: run it, verify exit code + item counts + checksum, ingest the artifact.