Wanted: real-world WordPress WXR exports (especially with ACF, Polylang, WooCommerce) to dogfood pull-wordpress

[JoshuaPozos]

What's this issue for

cms-sim pull-wordpress shipped in v0.6.1 with synthetic WXR fixtures — the example-wp-pull/ walk-through (12 documents, Gutenberg + Classic bodies, 2 attachments, nested categories, featured-image flow) plus a handful of unit-test fixtures. That covers the common shapes, but real production WordPress sites carry edge cases that synthetic fixtures will never surface on their own:

• ACF (Advanced Custom Fields) — repeaters, flexible content, post-object refs, gallery / image fields, conditional logic
• Polylang / WPML with real translation grouping (the _translations post-meta key that links en/fr/es versions into one logical entry)
• Custom post types + ACF combos
• WooCommerce product structures (product attributes, variations, custom taxonomies)
• Gutenberg blocks beyond paragraph/heading/list — custom blocks, embeds, columns, reusable blocks

If you maintain a WordPress site and can share a WXR export, please drop it here. The maintainers will use it as a regression / dogfood fixture for follow-up patches.

What we want

The file from wp-admin → Tools → Export → All content (full export — All content, not just posts).

Anonymization is fine and encouraged:

• Replace post bodies with lorem ipsum — body content doesn't matter, the Gutenberg / HTML structure does.
• Scrub user emails, real names, and login credentials.
• If your URLs are sensitive, replace the domain in <wp:base_site_url> and <wp:attachment_url> (a quick sed works fine).

What we want preserved:

• All <wp:post_type> declarations (so we see the custom CTs you use).
• <wp:postmeta> keys — these expose ACF / WooCommerce / Polylang conventions. The values can be anonymized; the keys are what tell us what plugins are in play.
• Category / tag / language taxonomies and their nicename slugs.
• Gutenberg block markers (<!-- wp:* -->) inside <content:encoded> — even with lorem ipsum content, the block structure is the interesting part.

How to share

Drop the file directly in this issue (GitHub accepts XML uploads up to ~25 MB; gzipped is fine too), or attach a gist link / file-share URL. Add a short note describing what's in play:

"WordPress 6.4, ACF Pro 6.2, Polylang Pro 3.4, WooCommerce 8.5. Site has 200 posts, 50 products, 3 languages (en/fr/de). Custom post types: case_study, team_member."

That kind of context is what helps us decide which patch to ship first.

What you'll get back

• Your shared dataset becomes a checked-in test fixture (anonymized form only) under src/wordpress/**/*.test.ts or example-wp-pull/data/.
• The release notes for the patch that fixes whatever you surfaced will credit your handle (unless you ask us not to).
• If your export uncovers a non-trivial bug, you get co-author credit on the fix commit.

Privacy

We won't include identifying information in any committed fixture. If your share leaks something private, ping the maintainer at the email in SECURITY.md and we'll squash + force-push to scrub.

Thanks for helping make pull-wordpress actually production-ready.