Export Command Laravel Package

Getting Started

1. Confirm the command exists. wp export is not bundled with recent WP-CLI releases — if you get "Error: 'export' is not a registered wp command", that's the package talking, not your site.

wp help export          # authoritative flag list for YOUR installed version
wp package list | grep export

2. Install it (once per environment).

wp package install wp-cli/export-command
# in Docker/CI as root:  wp --allow-root package install wp-cli/export-command
# Composer OOM:          COMPOSER_MEMORY_LIMIT=-1 wp package install wp-cli/export-command

Packages land in ~/.wp-cli/packages/. Pin a version (wp-cli/export-command:^0.9) so a CI image build months from now produces the same WXR.

3. First real use case — hand off one author's content. The canonical day-one task is "give me everything Alice published this quarter as a file I can hand to the content team":

mkdir -p /tmp/exports
wp export \
  --dir=/tmp/exports \
  --author=alice \
  --post_type=post \
  --post_status=publish \
  --start_date=2024-01-01 \
  --end_date=2024-03-31

4. Inspect before you trust it. The default filename is wordpress.<version>.<YYYY-MM-DD>.xml, so glob for it and check the item count against a wp post list count:

ls -lt /tmp/exports
grep -c '<item>' /tmp/exports/wordpress.*.xml
head -20 /tmp/exports/wordpress.*.xml   # confirm <wp:wxr_version> and site URL

5. Where to look first when something is off: wp help export (flags differ across versions), the <channel> block of the WXR (site URL, language, base site URL — these get rewritten on import), and the importer you'll use on the other side (wp-cli/import-command or the WordPress Importer plugin).

Implementation Patterns

Content-only staging refresh. Don't confuse this with a backup. The mature pattern is a two-track refresh: schema + options via wp db export/wp db import, content via WXR when you want a curated subset (e.g. only post and page from prod, not the 40k WooCommerce orders).

# prod
wp export --dir=/tmp --post_type=post,page --post_status=publish
# staging
wp import /tmp/wordpress.*.xml --authors=create
wp search-replace 'https://prod.example.com' 'https://staging.example.com' --all-tables --precise
wp cache flush && wp rewrite flush

search-replace after import is non-negotiable — WXR stores absolute URLs in post content, excerpts, and postmeta (including serialized ACF blobs).

Chunked exports for large sites. A single wp export resolves all matching post IDs up front, so a 200k-post site can blow memory before it writes anything. Loop by month and let each run be small and restartable:

for m in $(seq 1 12); do
  wp export --dir=/srv/exports \
    --post_type=post --post_status=any \
    --start_date=2023-$(printf %02d $m)-01 \
    --end_date=2023-$(printf %02d $m)-31 \
    --filename="2023-$(printf %02d $m).xml"
done

CI artifacts / scheduled dumps. --stdout makes the command pipe-friendly, and --filename makes the artifact name deterministic:

wp export --stdout --post_type=post,page --skip-comments | gzip > content-$(date +%F).xml.gz

Validate in the pipeline so a truncated WXR never ships:

xmllint --noout content.xml.gz && grep -c '<item>' content.xml

Multisite fan-out. There is no network-wide export; loop sites explicitly:

for url in $(wp site list --field=url); do
  wp export --url="$url" --dir=/srv/exports --filename="$(echo "$url" | tr '/:' '__').xml"
done

Wrapping it in your own command. If you need post-processing (injecting a custom post type, redacting emails, rewriting domains), write a small WP-CLI command that calls WP_CLI::runcommand( 'export --stdout ...', [ 'return' => true ] ), or call core's export_wp() directly in wp eval-file and hook export_args to adjust what it emits.

Migration checklist that actually works. Export → import into a clean target → rsync wp-content/uploads (WXR points at attachment URLs but ships no files) → wp search-replace → regenerate thumbnails if sizes changed → spot-check menus, widgets, and options by hand. Menus and widgets are not in WXR.

Gotchas and Tips

• It is not a backup. WXR contains posts, pages, custom post types, comments, terms, postmeta, and author records — not options, not users/passwords, not plugin settings, not custom tables. Anything you'd cry about losing needs wp db export.
• Media is metadata only. Attachments appear as <item> entries with URLs; the binaries live in uploads. Always pair with a file sync. Newer versions may offer an attachments flag — check wp help export before assuming.
• --dir must already exist and be writable, and relative paths resolve against your CWD, not the WordPress root. mkdir -p first; the error message is unhelpfully terse otherwise.
• Be explicit about --post_type and --post_status. Older versions defaulted to just post, which silently drops pages and CPTs. Never rely on the default in a script — write the list out.
• --max_file_size is in MB (default ~15) and splits per post. A single 40 MB post with embedded base64 or huge meta will still blow past the limit. Splitting also mutates --filename (numeric suffixes), so don't hardcode a downstream path when the export might fragment.
• --post__in takes source IDs, which are meaningless on the target — IDs are reassigned on import. Use it for a one-off pull from a known environment, never as a portable reference.
• Date filters compare against post_date in the site's local timezone, not UTC. Around DST boundaries and for posts scheduled near midnight, expect off-by-one surprises; widen the range by a day when in doubt.
• Comments dominate runtime on chatty blogs. --skip-comments is a large speedup when you only need content.
• Clean up partials. A run that dies mid-flight leaves a syntactically invalid (unclosed) XML file that looks plausible by size. Only promote files that passed xmllint.
• Package installs are per-user, per-environment. On ephemeral CI runners, bake wp package install into the image at build time (Composer hits Packagist); set WP_CLI_PACKAGES_DIR if you need a shared, cached location. wp package update is a separate, unautomated step — pin and upgrade deliberately.
• --stdout and notices: WP-CLI writes notices to STDERR, so > file.xml is normally clean, but add --quiet in pipelines where a stray notice would corrupt a checksum.
• Exit codes are your only signal. wp export doesn't fail loudly on zero results — it happily writes a WXR with <item> count 0. Assert the count in scripts.
• Extension points are thin. The command is largely a wrapper around core's export_wp(); there are no filters to reshape the WXR mid-stream. Post-process the XML (XSLT/sed/a PHP pass) or write your own command calling export_wp() with your own $args.