WP-CLI Command Reference

Super Speedy Emails adds a wp sse command group for migration and maintenance tasks that are easier (and safer) from the command line than the admin UI. All commands run under WP-CLI on the server hosting your site.

wp sse migrate

Import subscribers and ownership data from another system, or check the result. Every migration defaults to a dry run — it reports what would happen and writes nothing. Add --commit to actually apply the changes.

This is deliberate: run it once without --commit, read the report, and only commit when the numbers look right.

wp sse migrate mailpoet

Import subscribers, lists, and unsubscribes from MailPoet (reads MailPoet’s own database tables).

wp sse migrate mailpoet            # dry run — shows what would be imported
wp sse migrate mailpoet --commit   # actually import

Imports subscribers (matched/deduplicated by email), recreates their list memberships as SSE lists, and preserves their status — unsubscribed and bounced contacts are brought across as suppressions, not as active subscribers, so you don’t accidentally email people who opted out. Re-running is safe (idempotent): a second run produces no duplicates.

wp sse migrate mailerlite

Import from a MailerLite CSV export.

wp sse migrate mailerlite --file=/path/to/mailerlite-export.csv
wp sse migrate mailerlite --file=/path/to/mailerlite-export.csv --commit

--file is required and must point to a readable CSV on the server. Groups become lists; status is preserved the same way as the MailPoet importer.

wp sse migrate wc-customers

Backfill subscriber records and product-ownership data from existing WooCommerce orders. Useful when you install SSE on a store that already has order history, so the support-email and product-audience features know who owns what.

wp sse migrate wc-customers             # dry run, all-time
wp sse migrate wc-customers --commit    # apply
wp sse migrate wc-customers --days=365 --commit   # only orders from the last year

--days=N limits the backfill to orders placed in the last N days (omit for all-time). Ownership is recorded with bundle expansion — a customer who bought a bundle is recorded as owning each plugin inside it.

wp sse migrate report

Print a post-migration sanity check — counts of subscribers, lists, suppressions, and their sources — so you can verify a migration landed as expected.

wp sse migrate report

Triggering a support-email run

Not part of the migrate group, but useful for scripted testing of the automated support emails: you can run one saved Support Email record directly with wp eval.

# Run a single Support Email record by id (same logic as the Send now button):
wp eval '$r = SSE_Support_Rules::get( <record_id> ); print_r( SSE_Support_Emails::run_support_email( $r ) );'

# Run every ACTIVE record (only acts if the opt-in cron option is enabled):
wp eval 'SSE_Support_Emails::daily_check();'

Pair it with Send mode = Redirect or Log-only (Test Modes) so you can rehearse without emailing real owners.

Tips

• Always dry-run first. Run any migrate command without --commit, read the report, then commit.
• Back up the database before a large committed migration — it’s the safe habit even though the importers are idempotent.
• These commands need WP-CLI access to the server. If you’re on managed hosting without shell access, ask your host whether WP-CLI is available, or run the migration on a staging copy and move the result across.

Related

• Migrating to Super Speedy Emails — the full migration walkthrough with planning advice
• Automated Support & Changelog Emails · Test Modes
• Developer Reference