Tracking issue for adding WP-CLI support to Create Block Theme, originally requested in #688.
Background
Issue #688 proposes WP-CLI commands so developers can persist Editor changes to disk from the terminal — useful for git workflows and automation. @bacoords prototyped a wp cbt save command on a separate branch (https://github.com/bacoords/create-block-theme/tree/add/cli-export-command) but did not open a PR; the prototype acknowledges duplicated logic from the REST API.
This tracking issue proposes a four-PR sequence that ships the CLI as a thin layer over a properly extracted service layer, so REST and CLI share a single implementation.
Approach
For each of save and export:
- Refactor first — extract the REST handler's orchestration into a service class (
CBT_Theme_Save, CBT_Theme_Export) under includes/create-theme/. REST endpoint becomes a thin wrapper. Add PHPUnit coverage. No behavior change at the wire boundary.
- Add the CLI command — register on the same service. Kebab-case flags,
wp_is_block_theme() guard, ## EXAMPLES, i18n.
Doing the refactor first means the test coverage we need anyway lands in a small, reviewable PR before any new surface area is added.
Variation, clone, child-theme, blank-theme, and reset commands are deliberately out of scope for v1 and can be added in follow-ups once the pattern is established.
Sub-issues
Out of scope (potential follow-ups)
- Variation / clone / blank / child theme creation as CLI commands
- Behat feature tests (the plugin has no Behat infrastructure today)
- Promoting silent filesystem failures to
WP_Error (separate concern from the refactor)
References
Open to discussion on scope, sequencing, and naming before any PRs are opened.
Tracking issue for adding WP-CLI support to Create Block Theme, originally requested in #688.
Background
Issue #688 proposes WP-CLI commands so developers can persist Editor changes to disk from the terminal — useful for git workflows and automation. @bacoords prototyped a
wp cbt savecommand on a separate branch (https://github.com/bacoords/create-block-theme/tree/add/cli-export-command) but did not open a PR; the prototype acknowledges duplicated logic from the REST API.This tracking issue proposes a four-PR sequence that ships the CLI as a thin layer over a properly extracted service layer, so REST and CLI share a single implementation.
Approach
For each of
saveandexport:CBT_Theme_Save,CBT_Theme_Export) underincludes/create-theme/. REST endpoint becomes a thin wrapper. Add PHPUnit coverage. No behavior change at the wire boundary.wp_is_block_theme()guard,## EXAMPLES, i18n.Doing the refactor first means the test coverage we need anyway lands in a small, reviewable PR before any new surface area is added.
Variation, clone, child-theme, blank-theme, and reset commands are deliberately out of scope for v1 and can be added in follow-ups once the pattern is established.
Sub-issues
CBT_Theme_Saveservice fromrest_save_themewp cbt saveCLI commandCBT_Theme_Exportservice fromrest_export_themewp cbt exportCLI commandOut of scope (potential follow-ups)
WP_Error(separate concern from the refactor)References
Open to discussion on scope, sequencing, and naming before any PRs are opened.