

Dashboard — run totals, recent activity, and all 21 generators grouped by category.
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
storeseeder/v1/<resource>/generate for programmatic use.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.languages directory is registered, so Loco Translate and WPML String Translation pick the admin up without configuration.Generators
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.
Other free plugins by the same author, all on WordPress.org.
If you are seeding a store, you may also want
For a WooCommerce store
For any site
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
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:
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.
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: