Example content loader for new Threespot WordPress sites — pages and Gravity Forms — exposed as WP-CLI commands. Dev-dependency only, intended for fresh local installs.
composer require --dev threespot/wp-fixturesBedrock sites should add the package's GitHub repo to repositories in composer.json if it isn't already covered by an org-wide vcs entry:
"repositories": [
{ "type": "vcs", "url": "https://github.com/threespot/wp-fixtures" }
]The package self-registers its WP-CLI commands via Composer's autoload.files — no mu-plugin wiring or theme functions.php changes needed.
Prerequisite for form fixtures: loading Gravity Forms requires both Gravity Forms and the Gravity Forms CLI Add-On (gravityformscli) to be active — see Gravity Forms below. Page fixtures have no such dependency.
wp threespot fixtures load # load all fixtures (idempotent)
wp threespot fixtures load --pages # only pages
wp threespot fixtures load --forms # only Gravity Forms
wp threespot fixtures load --force # re-import even if already present
wp threespot fixtures load --path=… # override fixtures directory
wp threespot fixtures list # show what fixtures are available
wp threespot fixtures status # show which fixtures are loaded on this site
wp threespot fixtures export <post-id> # render a page back to fixture HTML (stdout)Order of operations when loading everything: Gravity Forms → pages. Page markup may reference imported forms, so they go first.
fixtures/
├── pages/ # *.html — Gutenberg block markup, optional YAML front-matter
└── forms/ # *.json — Gravity Forms native export
Filename derives the title (block-reference.html → "Block Reference"). File body is exactly what Gutenberg produces. Optional front-matter overrides defaults:
---
slug: block-reference
title: Block Reference
template: default-template.php
menu_order: 10
status: publish
post_type: page
author: admin
parent: parent-page-slug
---
<!-- wp:heading -->
<h2 class="wp-block-heading">Heading</h2>
<!-- /wp:heading -->Defaults when front-matter is absent: title from filename (titlecased, dashes/underscores → spaces), slug from sanitize_title(filename), status: publish, post_type: page, menu_order: 0, author: admin, no template override, no parent (top-level page).
author accepts a user_login or a numeric user ID. It defaults to the admin account; if no admin user exists (e.g. it was renamed), the loader falls back to the lowest-ID administrator. The author is resolved to an ID at import time — user IDs aren't portable across sites, so fixtures store the login, not the ID.
parent nests a page under another fixture page. Give it the slug of the parent (not an ID — IDs aren't portable). The loader inserts every page first, then wires up post_parent in a second pass, so child and parent fixtures can load in any order. An unknown parent slug is reported as an error and the page stays top-level.
A parent page can render a live index of its children with a core Page List block:
---
slug: test-pages
title: Test Pages
---
<!-- wp:page-list /-->On import the loader writes the page's own ID into the block's parentPageID attribute, scoping the list to that page's children. The list is generated by WordPress at render time from the post_parent tree, so it always reflects the current children — there are no slugs or URLs baked into the fixture to go stale.
Standard wp gf form import JSON exports. The loader shells out to that command, so the fixtures package doesn't parse or interpret form structure. Generate exports via Gravity Forms → Import/Export → Export Forms.
Requires the Gravity Forms CLI Add-On. The
wp gf …command namespace is not part of Gravity Forms core — it's provided by the separate Gravity Forms CLI Add-On (gravityformscli). Without it you'll see'gf' is not a registered wp commandwhen loading forms. Install and activate it from the WordPress admin (Forms → System Status / Add-Ons), then confirm withwp cli has-command gf.
Re-running load skips fixtures already imported. Markers used:
| Fixture type | Marker location | Marker key | Value |
|---|---|---|---|
| Page | postmeta |
_threespot_fixture_source |
e.g. pages/block-reference.html |
| Gravity Form | site option |
_threespot_fixtures_loaded |
array of imported source paths |
Markers track source path, so renaming a fixture file (or moving a post to a different slug) won't trigger re-import. Pass --force to re-import and update existing records.
For Gravity Forms, --force runs the import again — GF assigns a new form ID rather than updating in place. If form IDs matter (the bundled form-examples page references form ID 1), delete duplicates before re-running.
Hand-writing Gutenberg markup is painful. Roundtrip through the editor instead:
# Build the page in WordPress's editor on a local site, then:
wp threespot fixtures export 42 > fixtures/pages/new-page.htmlexport writes front-matter only for metadata that differs from loader defaults, so the output is minimal.
Run load locally → confirm content looks right → use terminus to push the database to dev/staging/multidev. The package itself is a dev-dependency and is not deployed to Pantheon environments.
- Gutenberg schemas evolve. Older fixtures may render with deprecation warnings against newer WordPress versions. Keep fixtures simple, regenerate periodically by re-exporting.
- Custom block coupling. Fixtures using blocks from
threespot/wp-blockspin to that package's block schemas; version-bump fixtures when block schemas change. - Form ID assumption. The bundled
form-examplespage references form ID 1, the ID Gravity Forms assigns on a fresh install. If you create forms manually before running fixtures, the assumption breaks — delete conflicting forms and re-run. - Third-party placeholder images. Fixture markup may include
<img>tags pointing at services like placehold.co. Replace with real images via the normal WordPress media flow before client review.
MIT — see LICENSE.