PHPackages                             wp-php-toolkit/blueprints - PHPackages - PHPackages  [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register)

1. [Directory](/)
2. /
3. [Utility &amp; Helpers](/categories/utility)
4. /
5. wp-php-toolkit/blueprints

ActiveLibrary[Utility &amp; Helpers](/categories/utility)

wp-php-toolkit/blueprints
=========================

Blueprints component for WordPress.

v0.8.1(1mo ago)0158GPL-2.0-or-laterPHPPHP &gt;=7.2

Since Sep 8Pushed 1mo agoCompare

[ Source](https://github.com/wp-php-toolkit/blueprints)[ Packagist](https://packagist.org/packages/wp-php-toolkit/blueprints)[ Docs](https://wordpress.github.io/php-toolkit/reference/blueprints.html)[ RSS](/packages/wp-php-toolkit-blueprints/feed)WikiDiscussions trunk Synced today

READMEChangelogDependencies (20)Versions (27)Used By (0)

   slug blueprints   title Blueprints   install wp-php-toolkit/blueprints   see\_also    filesystem | Filesystem | Prepare files and fixtures before applying site setup steps.

 httpclient | HttpClient | Download packages or source data as part of provisioning workflows.

 cli | CLI | Wrap repeatable blueprint operations in a small command.

    Declarative WordPress site provisioning. Write a Blueprint JSON document for plugins, options, content, and setup steps; let the runner execute it.

Why this exists
---------------

[](#why-this-exists)

A WordPress environment is more than a database dump. It can require a specific core version, plugins, themes, site options, uploaded files, content, and setup steps. Rebuilding that by hand makes demos, tests, bug reports, workshops, and CI fixtures drift over time.

The Blueprints component treats site setup as data. A blueprint JSON document describes the desired steps, and the runner applies them to either a new WordPress install or an existing one. The validator exists because user-authored JSON needs clear, path-specific errors rather than generic schema failures.

`RunnerConfiguration` separates the web root from the WordPress core directory, since real hosts often put them in different places. Both paths are explicit on the runner, never inferred.

Blueprints can *create* a new WordPress install (download core, set up the database, apply steps) or *apply to an existing* site. Creating a fresh install needs filesystem access this in-browser runtime doesn't have, so the runnable snippets focus on `APPLY_TO_EXISTING_SITE`.

Configure a runner for an existing site
---------------------------------------

[](#configure-a-runner-for-an-existing-site)

`RunnerConfiguration` is a fluent builder. A real run also needs a blueprint reference; this snippet shows the site-target fields in isolation.

```
