StoreSeeder – eCommerce Test Data Generator for WooCommerce & Fluent Cart

StoreSeeder generates realistic test data for WooCommerce and Fluent Cart — products with real prices and stock, customers with plausible addresses, and orders that point at both. It helps developers, agencies and store owners build datasets for testing, client demos and performance work without hand-crafting records.

Build a whole coherent shop in one click with a recipe — a corner grocer, a fashion boutique, a home & garden store — or generate one resource at a time with a live preview of exactly what a run will create.

Where the data lands is decided by a platform driver, and the same twenty-one generators feed every driver. Fluent Cart and WooCommerce are included today; drivers for other platforms are planned, and the registration filter is public, so a third party can add one from their own plugin without changes here.

All data is created through the target platform’s own models, so generated records respect the same validation, relationships, and business logic as real data and stay compatible with that platform’s updates.

Sample data is optional and consent-based. StoreSeeder can download locale-specific reference data (product names, addresses, customer tags) from GitHub to make generated content more realistic. Nothing is downloaded until you accept a one-time consent prompt on the plugin’s admin page. After that, StoreSeeder will re-fetch the files if they go missing. No data about your site is ever transmitted, and declining costs you no functionality — generators fall back to built-in defaults. You can change the decision at any time from Settings.

Highlights

• 21 generators — products, product variations, categories, tags, brands, customers, orders, transactions, refunds, coupons, shipping plans, shipping classes, tax classes, order tax lines, attributes, cart sessions, labels, product downloads, subscriptions, licences, and activity logs.
• One driver per platform — the generators are platform-neutral, so the same fixed seed produces identical data wherever it is written. Fluent Cart and WooCommerce ship; the driver layer is public for the rest.
• Modern admin — a single-page React app (React Router v7, Tailwind CSS v4, lucide icons) that adapts to your WordPress admin color scheme.
• Live preview — a read-only preview of real faker rows that refreshes as you change settings, without persisting anything.
• 75 locales — names, addresses, phone numbers, and postcodes in any locale FakerPHP ships a provider for. The picker offers exactly what the REST API accepts, searchable by name or code.
• Schema-driven configuration — each generator renders its own fields from a parameter schema: nested options, ranges, toggles, and intelligent defaults.
• REST API — every generator is exposed at storeseeder/v1/<resource>/generate for programmatic use.
• WP-CLI — wp storeseeder generate products --count=20 --locale=de_DE, plus preview, platform and locale commands. The same controllers as the REST API, so nothing can drift.
• Translation-ready — every string passes through gettext and the plugin’s own languages directory is registered, so Loco Translate and WPML String Translation pick the admin up without configuration.
• One-click cleanup — delete the data StoreSeeder generated, tracked in its own ledger so your own rows are never matched on.
• Optional MCP integration — expose generators as AI tools via the WordPress Abilities API (see below).
• Extensible — filters and actions cover the full generation lifecycle, one filter registers a whole platform, and one filter sets the capability required to use the plugin.

Generators

• Products — pricing, inventory, and content, created as a sellable product (post, product detail, and variation rows).
• Product Variations — additional priced variations attached to existing products, with unique SKUs.
• Customers — demographics, billing and shipping addresses, purchase history, and contact preferences.
• Orders — line items, billing and shipping addresses, applied coupons, payment, shipping, tax, and status distribution.
• Transactions — payment transactions tied to real orders.
• Refunds — full and partial refunds created against existing charge transactions.
• Coupons — discount types, usage limits, validity windows, and restrictions.
• Shipping Plans — shipping methods and zones.
• Shipping Classes — groups of products with similar shipping requirements.
• Tax Classes — tax classes with geographic rate rows.
• Order Tax Lines — per-order tax lines linking orders to tax rates.
• Attributes — attribute groups and terms, linked to real product variations.
• Product Categories — categories, nested where asked, with existing products filed under them. Needs a platform that has them: WooCommerce, EasyCommerce and Fluent Cart all do.
• Product Tags — tags applied to existing products. WooCommerce and EasyCommerce have tags; Fluent Cart does not, and says so rather than inventing somewhere to put them.
• Brands — product brands attached to existing products, optionally nested as sub-brands. Needs a platform that has brands: WooCommerce, EasyCommerce and Fluent Cart do.
• Cart Sessions — abandoned and active cart sessions.
• Labels — labels (tags) attached to existing orders and customers.
• Product Downloads — downloadable files for products, with download permissions on existing orders.
• Subscriptions — subscription records against existing orders (on Fluent Cart, active billing requires Pro).
• Logs — activity log entries across orders, products, customers, and system events.

Deleting generated data

Settings has a Danger zone action that deletes what StoreSeeder created — products, orders, customers and everything hanging off them — with a per-resource breakdown of what will go. wp storeseeder cleanup delete does the same from WP-CLI.

It deletes only rows the plugin recorded creating, in its own ledger table. Nothing is ever matched on for resembling test data, so a staging site restored from production keeps its real catalogue. Data generated before this version was released is not in the ledger and is not offered.

Model Context Protocol (MCP) Integration

The plugin can optionally expose each generator as two MCP tools so AI clients (e.g. Claude Desktop, IDE assistants) can work with test data in natural language: a read-only preview that shows the rows a run would create, and a generate tool that creates them. Settings has one switch per risk class — enable AI tools, allow preview tools, allow generating — and each is a registration gate, so a tool that is switched off is never offered to a client at all. Only administrators can change them.

The tools are served at /wp-json/storeseeder-mcp/mcp, and are also reachable through the mcp-adapter plugin’s own default server for clients already configured against it. A desktop client connects through Automattic’s mcp-wordpress-remote proxy (https://github.com/Automattic/mcp-wordpress-remote), using an application password for a user who has StoreSeeder access; that repository documents the setup and the current config format. This requires the WordPress Abilities API (bundled in WordPress 6.9+, or installable separately) and the mcp-adapter plugin. MCP is entirely optional and degrades gracefully — the plugin works normally when these dependencies are absent.

External services

StoreSeeder connects to GitHub and to WordPress.org. Nothing is contacted on activation, every request is administrator-initiated, and no personal or store data is ever transmitted.

1. GitHub — sample data repository

Locale-specific reference data (product names, addresses, customer tags) used to make generated content more realistic. Downloaded only after an administrator accepts the consent prompt on the plugin admin page — that prompt is the only way permission is granted. Until it is, “Sync now” and “Force re-sync” on the Settings page open the prompt instead of downloading. Once permission is on record, “Sync now” downloads; nothing is fetched on page load or on a schedule. Declining leaves every generator working from built-in defaults, and the decision can be changed from Settings at any time.

2. WordPress.org — plugin directory API

The “Our Plugins” admin page lists the plugin author’s other WordPress.org plugins with live ratings and install counts. Requested by the browser, only when an administrator opens that page.

3. GitHub — recipe repository

Store recipes: the vocabulary that makes every generator produce one coherent shop. Downloaded only when an administrator presses “Download the recipes” on the Recipes page, and only once the consent prompt above has already been accepted — one consent record covers both, because asking twice for the same answer trains people to click through prompts. Unlike the sample data this is never fetched implicitly. Declining or ignoring it leaves the rest of the plugin unaffected.

The full disclosure for each service — endpoint, exactly when the request is made, what is sent and received, and the provider’s terms of service and privacy policy — is documented here:

Read the external services disclosure

Source code

The minified JavaScript and CSS in build/ is compiled from the TypeScript and CSS sources in src/, which are not included in the distributed plugin package. The complete, human-readable source is public:

Browse the StoreSeeder source on GitHub

Build tooling is webpack (via @wordpress/scripts), TypeScript, and Tailwind CSS, configured by webpack.config.js, tsconfig.json, and postcss.config.js in the repository root. The build steps are listed under “Development Setup” above; local setup, the full toolchain, and the quality gates are documented here:

Read the contributing guide

Privacy

All generated data is stored in your own WordPress database and is never transmitted anywhere. Generated content is fictional and does not represent real individuals or transactions. The plugin does not collect analytics and does not phone home.

The plugin makes two outbound requests, both administrator-initiated and both carrying no site data — see the “External services” section above, and the external services disclosure for the full detail.

Contributing

Development happens on GitHub. Bug reports, feature requests, and pull requests are all welcome — the issue tracker is the place to start. Setting up, the quality gates, and how to add a platform driver, a generator or a recipe are documented here:

Read the contributing guide