Wiping WordPress for a fresh SSI import

June 5, 2026

When you want a truly clean baseline — every post deleted, every term gone, every postmeta row removed — to re-test an import end-to-end or to benchmark from zero. This guide covers SSI’s own --delete-all shortcut (the fastest path for a single-import site), the WP Reset plugin (for the full-wipe case), and two narrower alternatives if you only want to delete imported data.

Read this whole page before running anything. A bad reset can take SSI’s wp_ssi_imports, wp_ssi_import_history, and per-import aux tables with it — which costs you your saved import configuration.

Quick path — re-running a single SSI import

Use this if you’ve only run ONE import on this site and just want to re-run it cleanly (e.g. benchmarking with new SSI code). No WP Reset, no full wipe — just SSI’s own delete-all mode plus optional cleanup of orphaned terms and media.

Step 1 — Delete the products this import created

wp ssi <import-id> --delete-all

The --delete-all flag tells SSI to skip CSV loading and worker spawning entirely and only run the process-deletes stage. Every product previously created by this import will be deleted (force-deleted, not trashed). The import’s saved configuration in wp_ssi_imports is preserved.

What this does NOT delete: – Terms imported by previous runs (product_cat, product_brand, pa_color, pa_size, etc.) — orphaned terms remain. – Uploaded media (attachment posts AND files in wp-content/uploads/). – Other plugins’ postmeta linked to the deleted products gets cascaded by WP but anything keyed on attachment_id survives.

For a true “before” state, also run the next two steps.

Step 2 — Delete imported product terms

WooCommerce expects these system taxonomies to stay populated — DO NOT touch them: – product_visibility — outofstock / rated / featured flags – product_type — simple / variable / grouped / external — Woo breaks without these – product_shipping_class — user-configured shipping classes

Everything else (categories, tags, brands, attributes) is fair game. One liner per taxonomy:

wp term list product_cat    --field=term_id | xargs -r wp term delete product_cat
wp term list product_tag    --field=term_id | xargs -r wp term delete product_tag
wp term list product_brand  --field=term_id | xargs -r wp term delete product_brand

For all pa_* attribute taxonomies (color, size, material, whatever your CSV maps), a small loop:

for t in $(wp taxonomy list --field=name | grep '^pa_'); do wp term list "$t" --field=term_id | xargs -r wp term delete "$t"; done

Or do everything in one shot:

for t in product_cat product_tag product_brand $(wp taxonomy list --field=name | grep '^pa_'); do wp term list "$t" --field=term_id | xargs -r wp term delete "$t"; done

The -r flag on xargs is GNU-specific — it skips invocation when stdin is empty, so empty taxonomies don’t trigger a confusing “needs term IDs” error.

Step 3 — Delete uploaded media

wp post delete --force on an attachment fires wp_delete_attachment, which removes both the DB row AND the file on disk (the WP-canonical path):

wp post delete $(wp post list --post_type=attachment --format=ids --posts_per_page=-1) --force

That’s the right answer for most sites. At 100k+ attachments it gets slow (each delete fires the full hook cascade), so for huge wipes here’s the fast fallback — raw SQL for the DB side, plus find for the files:

# DB side — drops attachment posts + their postmeta + term relationships in one go
wp db query "DELETE p, pm, tr FROM wp_posts p LEFT JOIN wp_postmeta pm ON pm.post_id=p.ID LEFT JOIN wp_term_relationships tr ON tr.object_id=p.ID WHERE p.post_type='attachment';"

# File side — delete everything under uploads/ except the SSI CSV directory
find "$(wp eval 'echo wp_get_upload_dir()["basedir"];')" -mindepth 1 -maxdepth 1 ! -name 'super-speedy-imports' -exec rm -rf {} +

Trade-off: the SQL form skips delete_attachment hooks, so plugins that listen for those (cloud-storage offloaders, external CDN purgers) won’t get notified. Fine for a clean-slate benchmark, not for a production wipe.

After either approach, flush the object cache so stale attachment metadata doesn’t leak into the re-import:

wp cache flush

Step 4 — Re-run the import

wp ssi <import-id>

The SSI aux tables (wp_super_speedy_imports_*_<id>) get DROPped and recreated by load-csv, so leftover state from the previous run doesn’t matter.

When to use the quick path vs WP Reset

Situation Use
One SSI import on the site, fresh-benchmark re-run Quick path (this section)
Multiple SSI imports running concurrently against same site Quick path per-import, OR full WP Reset if you want all gone
Mixed WP content (pages, blog posts, users, custom plugins) you want to preserve Quick path — surgical
Site has gotten into a weird state and you want a truly fresh WP WP Reset below
Just want to test a single stage without touching products Drop SSI aux tables only — see Option 3 below

Option 1 — WP Reset plugin (recommended for full wipes)

What WP Reset does

The default Reset Site action:

  • Empties: wp_posts, wp_postmeta, wp_comments, wp_commentmeta, wp_terms, wp_termmeta, wp_term_taxonomy, wp_term_relationships.
  • Keeps: users, current user’s session, active theme, active plugins, site URL, WP version, WP options (with a small number of exceptions).
  • By default leaves custom plugin tables alone — including wp_ssi_imports, wp_ssi_imports_meta, wp_ssi_import_history, wp_ssi_import_history_stages. Your import configuration survives.

What it does NOT do by default:

  • Does not delete media files from wp-content/uploads/ (only the attachment posts pointing at them). Run the media cleanup step below if you want those gone too.
  • Does not touch custom WP Reset snapshots.

Step 1 — Install WP Reset

If you don’t already have it:

wp plugin install wp-reset --activate

Step 2 — Take a snapshot first (always)

This is the “oh shit” button. Takes ~10-30 seconds depending on DB size. Restoring is fast.

wp reset snapshots create --name="pre-fresh-import-$(date +%Y%m%d-%H%M)" --description="State before wiping for fresh SSI import benchmark"
wp reset snapshots list

The snapshot includes everything WP Reset would otherwise wipe, so you can always roll back if the import goes wrong.

Step 3 — Run the reset

CLI (fastest, scriptable):

wp reset reset --yes

The --yes skips the interactive confirmation. WP Reset will:

  1. Empty the WP core tables listed above.
  2. Reinstall the WP defaults (one sample post, one sample page, default theme settings).
  3. Reactivate the plugins that were active before the reset (so SSI is still on after).
  4. Log you out — re-login at /wp-admin/.

UI alternative: Tools → WP Reset → Reset tab → “I understand” checkbox → “Reset site” button.

Step 4 — Verify SSI’s tables survived

wp db query "SHOW TABLES LIKE 'wp_ssi_%'"

You should see: – wp_ssi_imports (your saved import configs) – wp_ssi_imports_meta – wp_ssi_import_history – wp_ssi_import_history_stages – Any per-import aux tables left over from previous runs (e.g. wp_super_speedy_imports_batch_10)

If any are missing, restore from the snapshot you took in step 2:

wp reset snapshots restore <uid-from-list>

…then come back and use Option 2 or 3 below instead.

Step 5 — Confirm SSI’s CSV file is still accessible

The reset doesn’t touch wp-content/uploads/ so your CSV at wp-content/uploads/super-speedy-imports/<file>.csv should still be there. Quick check:

wp ssi <import-id> list-files

Should print your CSV.

Step 6 — Re-run the import

wp ssi <import-id>

Option 2 — Targeted wipe of imported posts only

Use this if you have OTHER WordPress content on the site you want to preserve (pages, blog posts, users’ work, etc.) and only want to wipe what SSI imported.

If your imported post type is product:

# Wipe all products + their variations (force=true skips trash)
wp post delete $(wp post list --post_type=product,product_variation --format=ids --posts_per_page=-1) --force

This is slow at scale — wp post delete fires the full WP delete cascade per post (hooks, postmeta cleanup, term-relationship cleanup, attachment unlink, etc.). At 868k products, expect hours.

Faster, more surgical SQL version (skips WP hooks — fine for fresh-import benchmarking, NOT fine for production sites with other plugins listening for delete events):

wp db query "
DELETE p, pm, tr
FROM wp_posts p
LEFT JOIN wp_postmeta pm ON pm.post_id = p.ID
LEFT JOIN wp_term_relationships tr ON tr.object_id = p.ID
WHERE p.post_type IN ('product', 'product_variation');
"

Then clean up orphan terms (terms left behind because they belonged only to deleted products):

wp term recount $(wp taxonomy list --field=name | tr '\n' ' ')
# Or for the specific taxonomies your products use:
wp term recount product_cat product_tag pa_color pa_size

Option 3 — Drop just the SSI aux tables (keep WP content)

If you want WP intact and only want to clear SSI’s per-import staging tables (e.g. you stopped an import mid-way and want to start the load-csv stage clean without affecting any data already in wp_posts):

# List the per-import aux tables for import id 10
wp db query "SHOW TABLES LIKE 'wp_super_speedy_imports_%\\_10'"
wp db query "SHOW TABLES LIKE 'wp_ssi_%\\_10'"

# Drop them all in one go (replace 10 with your import id)
for t in $(wp db query "SELECT TABLE_NAME FROM information_schema.TABLES WHERE TABLE_NAME LIKE 'wp\\_super\\_speedy\\_imports\\_%\\_10' OR TABLE_NAME LIKE 'wp\\_ssi\\_%\\_10'" --skip-column-names); do
    wp db query "DROP TABLE IF EXISTS $t"
done

Then re-run from load-csv:

wp ssi 10 load-csv

load-csv itself does DROP TABLE IF EXISTS on each aux table before recreating, so this manual step is normally only needed if you’re trying to diagnose a corrupt state. SSI’s design is to leave aux tables around between runs precisely so you can do post-mortems — they get re-created cleanly at the start of every new run.

Optional — clear the wp-content/uploads/ media too

WP Reset doesn’t touch on-disk media. If your import uploads images and you want a truly clean filesystem state for the benchmark:

# CAREFUL — irreversible.
# Confirm the path is the WordPress uploads dir, then:
rm -rf /var/www/<your-site>/htdocs/wp-content/uploads/*/

# Or via WP-CLI (won't delete the directory structure, just the files):
wp media regenerate --yes --only-missing  # won't help — needs attachment posts
# (no built-in WP-CLI cmd for raw file delete — use rm)

Then re-run the import and watch upload-remote-images actually pull every image again.

If you want to keep certain uploads (e.g. wp-content/uploads/super-speedy-imports/ where your CSVs live), exclude them:

find /var/www/<your-site>/htdocs/wp-content/uploads/ -mindepth 1 -maxdepth 1 ! -name 'super-speedy-imports' -exec rm -rf {} +

Quick decision tree

Goal Use
Clean WP + benchmark from absolute zero, preserve SSI config Option 1 (WP Reset) + optional media wipe
Re-run a specific import without affecting other WP content Option 2 (targeted post wipe)
Restart just the SSI staging pipeline mid-run Option 3 (drop aux tables for that import id)
Roll back after a botched reset wp reset snapshots restore <uid>

Post-reset gotchas

  1. WooCommerce setup wizard — WP Reset clears most options but leaves Woo’s “we’re set up” flag. If you see the setup wizard pop up, dismiss it; this is normal.
  2. Object cache — flush after a reset, especially with Redis / Memcached: wp cache flush.
  3. Permalink rewrite rules — re-save permalinks: wp rewrite flush.
  4. GridPane / hosting caches — page cache may serve stale 404s. Clear via your control panel or wp cache flush if integrated.
  5. WP Reset itself stays active — if you don’t want it visible on a benchmark run, wp plugin deactivate wp-reset after step 4 of Option 1.

Verifying the wipe took effect

wp post list --post_type=product --format=count             # should be 0 (or 1 if Woo sample product reseeded)
wp term list product_cat --format=count                     # 1 (uncategorized) or 0
wp db query "SELECT COUNT(*) FROM wp_postmeta"              # very small number — just options/sample
wp db query "SELECT COUNT(*) FROM wp_term_relationships"    # similar

Numbers in the low double-digits = clean reset. Anything in the thousands = something didn’t get wiped, investigate before re-importing.

×
▲
▼
1/1