Automate Your WordPress Theme Development
🔗 **Source:** [Automate Your WordPress Theme Development](https://georgestephanis.wordpress.com/2026/01/06/automate-your-wordpress-theme-development/)
> [!note]+ Document Notes
> ```yaml
> tags: [WordPress, Themes, Automation]
> author: George Stephanis
> source: WordPress.com
> reference: [https://georgestephanis.wordpress.com/2026/01/06/automate-your-wordpress-theme-development/]
> date created: 2026-01-07 00:00
>
> ---
> # 🏷️ Title: Automate Your WordPress Theme Development
<!-- deep-read:sections start -->
## 🧭 Table of Contents
- [📝 Summary](#-summary)
- [📖 Main Content](#-main-content)
- [🗒️ Notes](#️-notes)
- [📚 References](#-references)
- [🗣️ Paraphrase](#️-paraphrase)
- [📰 Newsletter](#-newsletter)
- [✅ Action Items](#-action-items)
- [🧪 Hypotheses](#-hypotheses)
- [📊 Methodology](#-methodology)
- [❓ Questions](#-questions)
- [🔮 Future Research](#-future-research)
- [💡 Implications](#-implications)
- [🧠 Learning Styles Assessment](#-learning-styles-assessment)
- [📊 Accessibility Assessment](#-accessibility-assessment)
- [🌍 DEIB Assessment](#-deib-assessment)
- [✅ Logical Validity](#-logical-validity)
- [🛡️ DARVO Analysis](#-darvo-analysis)
- [🎯 Conclusion](#-conclusion)
### 🔗 References
- Include links cited in or relevant to the article.
## 📝 Summary
- What happened: The author built a reusable boilerplate and workflow to rapidly spin up Full Site Editing (FSE) themes from Figma designs using Create Block Theme, GitHub Actions, Composer/@wordpress/scripts, Sass, Playground, and Starter Content.
- Why it matters: Dramatically reduces repetitive setup, improves consistency, and enables easy client demos.
- Key stakeholders: Theme developers, agencies, clients reviewing designs, WordPress core/tooling teams.
- Risks and tradeoffs: Boilerplate can drift from best practices; automation hides complexity; Playground demos may differ slightly from production hosting.
- Bottom line: Investing in opinionated automation around FSE, Playground, and starter content pays off for recurring theme work.
## 📖 Main Content
- The article starts from the need to ship many FSE themes quickly from Figma, motivating a “solid starter theme” instead of reinventing the wheel.
- The core tool is the **Create Block Theme** plugin, which lets you edit templates, headers/footers, colors, and typography in the Site Editor and then write those changes back into the theme on disk ([Create Block Theme section](https://read.readwise.io/read/01ked1m98mm01j3eptkpacmq36?endLexposition=00008_00002-003Q&startLexposition=00006&emphasizeText=it+then+gives+you+a+simple+option+to+write+your+changes+to+disk+in+the+theme+itself)).
- As a base, the author prefers starting from the official Create Block Theme boilerplate, which is minimal—header/footer partials, a basic index template, and a `theme.json` that you extend via the Site Editor ([boilerplate explanation](https://read.readwise.io/read/01ked1m98mm01j3eptkpacmq36?endLexposition=0000I_00000-004M&startLexposition=0000A&emphasizeText=There%E2%80%99s+really+not+a+lot+to+it.+A+header+and+footer+partial%2C+a+general+index+template%2C+and+a+theme.json+file)).
- He then layers automation:
- **Automatic namespacing** via a GitHub Action, adapted from Automattic’s Special Projects templates. Creating a new repo from the template triggers automatic renaming of the theme folder and namespaces to match the new theme name, replacing older fragile local string-replace scripts ([automatic namespacing description](https://read.readwise.io/read/01ked1m98mm01j3eptkpacmq36?endLexposition=0000Q_00001_00000-001f&startLexposition=0000K&emphasizeText=as+soon+as+you+use+the+boilerplate+to+create+a+new+repository%2C+with+one+click+you+can+have+the+theme+folder+and+all+the+namespaces+reflecting+the+new+instance%E2%80%99s+name)).
- **Build tools automation** using `@wordpress/scripts` for JS/CSS bundling and Composer for translations, PHP formatting, etc., wired in so everything works out of the box ([build tools section](https://read.readwise.io/read/01ked1m98mm01j3eptkpacmq36?endLexposition=0000Y_00002-000V&startLexposition=0000S&emphasizeText=That%E2%80%99s+why+I%E2%80%99ve+got+my+boilerplate+leveraging+a+lot+of+the+public+work+that+the+Special+Projects+Team+built)).
- For styling, the author likes Sass but increasingly uses `theme.json` for block theme styles so they’re editable via the Site Editor and avoid CSS specificity issues, while also improving WYSIWYG in the editor ([Sass vs theme.json reasoning](https://read.readwise.io/read/01ked1m98mm01j3eptkpacmq36?endLexposition=0000e_00000-006g&startLexposition=0000a&emphasizeText=I+find+I%E2%80%99ve+moved+more+toward+%28where+possible%29+defining+the+styles+in+theme.json)).
- A major feature is **WordPress Playground** integration:
- Playground runs WordPress entirely in the browser, without a server.
- The real value is instant test sites: clients or stakeholders can try a theme or feature via a link backed by the current GitHub repo state, once the boilerplate is configured ([Playground utility](https://read.readwise.io/read/01ked1m98mm01j3eptkpacmq36?endLexposition=0000o_00001_00000-000Q&startLexposition=0000g&emphasizeText=It+makes+it+trivial+to+set+up+a+test+site+and+let+a+user+%28or+client+or+stakeholder%29+instantly+test+out+a+plugin+or+trial+a+theme)).
- To avoid blank demo sites, he uses **Playground Blueprints** plus **Starter Content**:
- Blueprints can import WXR exports or run an `importThemeStarterContent` step, reusing the older Starter Content feature from WordPress 4.7 and adapting it for block themes ([starter content overview](https://read.readwise.io/read/01ked1m98mm01j3eptkpacmq36?endLexposition=0000y_00005_00000-000V&startLexposition=0000q&emphasizeText=Starter+Content+is+a+feature+that+was+introduced+through+the+Customizer+way+back+in+WordPress+4.7)).
- A snag: Starter Content still imports classic nav menus, but FSE themes use navigation blocks:
- Core offers a class to convert legacy menus to block navigation, but it isn’t directly referenceable.
- The boilerplate runs custom PHP during Playground setup (via a Blueprint step) that can bootstrap a theme file, clean up imported Starter Content, fix permalinks, and reconcile navigation menus.
- Since navigation blocks only accept menu IDs, the author adds a custom slug property in templates that maps to the appropriate Starter Content menu, ensuring header/footer menus are wired correctly ([navigation handling and slug mapping](https://read.readwise.io/read/01ked1m98mm01j3eptkpacmq36?endLexposition=0001C_00001_00000-000z&startLexposition=00010&emphasizeText=Finally%2C+core%E2%80%99s+navigation+block+only+supports+specifying+menus+by+ID+%E2%80%94+no+support+for+slugs)).
- He closes by acknowledging the boilerplate isn’t perfect but has saved significant client time and invites others to use it and build “super-cool-stuff” ([closing reflection](https://read.readwise.io/read/01ked1m98mm01j3eptkpacmq36?endLexposition=0001K_00000-0017&startLexposition=0001E&emphasizeText=For+me%2C+though%2C+it%E2%80%99s+a+great+starting+point%2C+and+has+saved+me+a+bunch+of+time+for+client+work.)).
### 🗒️ Notes
- Motivation: recurring client work building FSE themes from Figma leads to creating a “solid starter theme” instead of repeating set-up work ([opening motivation](https://read.readwise.io/read/01ked1m98mm01j3eptkpacmq36?endLexposition=00004_00000-0025&startLexposition=00000&emphasizeText=Whatever+is+a+programmer+to+do+but+make+sure+I%E2%80%99m+being+efficient+and+not+reinventing+the+wheel+by+creating+a+solid+starter+theme.)).
- Create Block Theme (CBT):
- Acts as the main bridge between Site Editor customization and the theme files on disk.
- Encourages designing in the editor first, then persisting to the filesystem ([CBT description](https://read.readwise.io/read/01ked1m98mm01j3eptkpacmq36?endLexposition=00008_00002-003Q&startLexposition=00006&emphasizeText=While+you%E2%80%99re+editing+your+theme+in+the+Site+Editor+%E2%80%94+customizing+page+templates%2C+headers%2C+footers%2C+colors%2C+typefaces+%E2%80%94+it+then+gives+you+a+simple+option+to+write+your+changes+to+disk)).
- Boilerplate base:
- Uses the official CBT boilerplate repo, which is intentionally minimal and expects you to expand via Editor-made templates and patterns.
- `theme.json` is central for defining theme parameters and later editor overrides ([boilerplate rep
<!-- deep-read:sections end -->
[[3. Resources/Readwise/Full Document Contents/Articles/Automate Your WordPress Theme Development|Full Document Contents]]
## Document Notes
```yaml
tags: #WordPress #Themes #Automation
author: George Stephanis
source: WordPress.com
reference: [https://georgestephanis.wordpress.com/2026/01/06/automate-your-wordpress-theme-development/]
date created: 2026-01-07 00:00
---
# 🏷️ Title: Automate Your WordPress Theme Development
## 🧭 Table of Contents
- [[#📝 Summary]]
- [[#📖 Main Content]]
- [[#🗒️ Notes]]
- [[#📚 References]]
- [[#🗣️ Paraphrase]]
- [[#📰 Newsletter]]
- [[#✅ Action Items]]
- [[#🧪 Hypotheses]]
- [[#📊 Methodology]]
- [[#❓ Questions]]
- [[#🔮 Future Research]]
- [[#💡 Implications]]
- [[#🧠 Learning Styles Assessment]]
- [[#📊 Accessibility Assessment]]
- [[#🌍 DEIB Assessment]]
- [[#✅ Logical Validity]]
- [[#🛡️ DARVO Analysis]]
- [[#🎯 Conclusion]]
### 🔗 References
- Include links cited in or relevant to the article.
## 📝 Summary
- What happened: The author built a reusable boilerplate and workflow to rapidly spin up Full Site Editing (FSE) themes from Figma designs using Create Block Theme, GitHub Actions, Composer/@wordpress/scripts, Sass, Playground, and Starter Content.
- Why it matters: Dramatically reduces repetitive setup, improves consistency, and enables easy client demos.
- Key stakeholders: Theme developers, agencies, clients reviewing designs, WordPress core/tooling teams.
- Risks and tradeoffs: Boilerplate can drift from best practices; automation hides complexity; Playground demos may differ slightly from production hosting.
- Bottom line: Investing in opinionated automation around FSE, Playground, and starter content pays off for recurring theme work.
## 📖 Main Content
- The article starts from the need to ship many FSE themes quickly from Figma, motivating a “solid starter theme” instead of reinventing the wheel.
- The core tool is the **Create Block Theme** plugin, which lets you edit templates, headers/footers, colors, and typography in the Site Editor and then write those changes back into the theme on disk ([Create Block Theme section](https://read.readwise.io/read/01ked1m98mm01j3eptkpacmq36?endLexposition=00008_00002-003Q&startLexposition=00006&emphasizeText=it+then+gives+you+a+simple+option+to+write+your+changes+to+disk+in+the+theme+itself)).
- As a base, the author prefers starting from the official Create Block Theme boilerplate, which is minimal—header/footer partials, a basic index template, and a `theme.json` that you extend via the Site Editor ([boilerplate explanation](https://read.readwise.io/read/01ked1m98mm01j3eptkpacmq36?endLexposition=0000I_00000-004M&startLexposition=0000A&emphasizeText=There%E2%80%99s+really+not+a+lot+to+it.+A+header+and+footer+partial%2C+a+general+index+template%2C+and+a+theme.json+file)).
- He then layers automation:
- **Automatic namespacing** via a GitHub Action, adapted from Automattic’s Special Projects templates. Creating a new repo from the template triggers automatic renaming of the theme folder and namespaces to match the new theme name, replacing older fragile local string-replace scripts ([automatic namespacing description](https://read.readwise.io/read/01ked1m98mm01j3eptkpacmq36?endLexposition=0000Q_00001_00000-001f&startLexposition=0000K&emphasizeText=as+soon+as+you+use+the+boilerplate+to+create+a+new+repository%2C+with+one+click+you+can+have+the+theme+folder+and+all+the+namespaces+reflecting+the+new+instance%E2%80%99s+name)).
- **Build tools automation** using `@wordpress/scripts` for JS/CSS bundling and Composer for translations, PHP formatting, etc., wired in so everything works out of the box ([build tools section](https://read.readwise.io/read/01ked1m98mm01j3eptkpacmq36?endLexposition=0000Y_00002-000V&startLexposition=0000S&emphasizeText=That%E2%80%99s+why+I%E2%80%99ve+got+my+boilerplate+leveraging+a+lot+of+the+public+work+that+the+Special+Projects+Team+built)).
- For styling, the author likes Sass but increasingly uses `theme.json` for block theme styles so they’re editable via the Site Editor and avoid CSS specificity issues, while also improving WYSIWYG in the editor ([Sass vs theme.json reasoning](https://read.readwise.io/read/01ked1m98mm01j3eptkpacmq36?endLexposition=0000e_00000-006g&startLexposition=0000a&emphasizeText=I+find+I%E2%80%99ve+moved+more+toward+%28where+possible%29+defining+the+styles+in+theme.json)).
- A major feature is **WordPress Playground** integration:
- Playground runs WordPress entirely in the browser, without a server.
- The real value is instant test sites: clients or stakeholders can try a theme or feature via a link backed by the current GitHub repo state, once the boilerplate is configured ([Playground utility](https://read.readwise.io/read/01ked1m98mm01j3eptkpacmq36?endLexposition=0000o_00001_00000-000Q&startLexposition=0000g&emphasizeText=It+makes+it+trivial+to+set+up+a+test+site+and+let+a+user+%28or+client+or+stakeholder%29+instantly+test+out+a+plugin+or+trial+a+theme)).
- To avoid blank demo sites, he uses **Playground Blueprints** plus **Starter Content**:
- Blueprints can import WXR exports or run an `importThemeStarterContent` step, reusing the older Starter Content feature from WordPress 4.7 and adapting it for block themes ([starter content overview](https://read.readwise.io/read/01ked1m98mm01j3eptkpacmq36?endLexposition=0000y_00005_00000-000V&startLexposition=0000q&emphasizeText=Starter+Content+is+a+feature+that+was+introduced+through+the+Customizer+way+back+in+WordPress+4.7)).
- A snag: Starter Content still imports classic nav menus, but FSE themes use navigation blocks:
- Core offers a class to convert legacy menus to block navigation, but it isn’t directly referenceable.
- The boilerplate runs custom PHP during Playground setup (via a Blueprint step) that can bootstrap a theme file, clean up imported Starter Content, fix permalinks, and reconcile navigation menus.
- Since navigation blocks only accept menu IDs, the author adds a custom slug property in templates that maps to the appropriate Starter Content menu, ensuring header/footer menus are wired correctly ([navigation handling and slug mapping](https://read.readwise.io/read/01ked1m98mm01j3eptkpacmq36?endLexposition=0001C_00001_00000-000z&startLexposition=00010&emphasizeText=Finally%2C+core%E2%80%99s+navigation+block+only+supports+specifying+menus+by+ID+%E2%80%94+no+support+for+slugs)).
- He closes by acknowledging the boilerplate isn’t perfect but has saved significant client time and invites others to use it and build “super-cool-stuff” ([closing reflection](https://read.readwise.io/read/01ked1m98mm01j3eptkpacmq36?endLexposition=0001K_00000-0017&startLexposition=0001E&emphasizeText=For+me%2C+though%2C+it%E2%80%99s+a+great+starting+point%2C+and+has+saved+me+a+bunch+of+time+for+client+work.)).
### 🗒️ Notes
- Motivation: recurring client work building FSE themes from Figma leads to creating a “solid starter theme” instead of repeating set-up work ([opening motivation](https://read.readwise.io/read/01ked1m98mm01j3eptkpacmq36?endLexposition=00004_00000-0025&startLexposition=00000&emphasizeText=Whatever+is+a+programmer+to+do+but+make+sure+I%E2%80%99m+being+efficient+and+not+reinventing+the+wheel+by+creating+a+solid+starter+theme.)).
- Create Block Theme (CBT):
- Acts as the main bridge between Site Editor customization and the theme files on disk.
- Encourages designing in the editor first, then persisting to the filesystem ([CBT description](https://read.readwise.io/read/01ked1m98mm01j3eptkpacmq36?endLexposition=00008_00002-003Q&startLexposition=00006&emphasizeText=While+you%E2%80%99re+editing+your+theme+in+the+Site+Editor+%E2%80%94+customizing+page+templates%2C+headers%2C+footers%2C+colors%2C+typefaces+%E2%80%94+it+then+gives+you+a+simple+option+to+write+your+changes+to+disk)).
- Boilerplate base:
- Uses the official CBT boilerplate repo, which is intentionally minimal and expects you to expand via Editor-made templates and patterns.
- `theme.json` is central for defining theme parameters and later editor overrides ([boilerplate repo reference](https://read.readwise.io/read/01ked1m98mm01j3eptkpacmq36?endLexposition=0000I_00000-004M&startLexposition=0000A&emphasizeText=a+theme.json+file+that+starts+defining+parameters.)).
- Namespacing automation:
- Earlier, Automattic’s team relied on local scripts to clone and string-replace template repos; fragile and manual.
- A GitHub Action now handles renaming, so creating a new repo from the boilerplate yields a correctly namespaced theme immediately.
- Build tooling:
- `@wordpress/scripts` abstracts complex JS build configuration.
- Composer coordinates translation generation, PHP formatting, and other tooling, bundled into the boilerplate so you can just run the provided scripts.
- Styling approach:
- Sass is still preferred for writing CSS, but the author shifts much logic to `theme.json`:
- Theme.json-driven styles are cleaner for overrides in the Site Editor.
- Avoids classic CSS specificity fights and ordering issues.
- Improves block editor WYSIWYG fidelity, since editor and front output share the same design tokens.
- Playground:
- WordPress running entirely in-browser is reframed from a novelty into a practical client tool.
- By wiring Playground to a GitHub repo, stakeholders always see the latest code without needing to set up hosting.
- Boilerplate configuration hides the complexity so “it’ll just work magically” for each new theme.
- Starter Content & Blueprints:
- Pain point: blank sites after theme install vs polished screenshots.
- Blueprints can:
- Import a WXR export for bulk content.
- Use `importThemeStarterContent` to leverage core’s Starter Content feature.
- Starter Content, originally tied to the Customizer, is revived for block themes by mapping it into Playground flows.
- Menus and navigation:
- Block theme navigation differs from legacy Appearance → Menus.
- Starter Content still creates classic menus, so:
- Core offers a conversion class, but it isn’t directly referenced in configuration.
- Blueprint runs custom PHP from within the theme to:
- Convert menus to block navigation.
- Tidy imported content and set things like permalinks.
- Because the navigation block only accepts IDs, templates add a custom slug which is then mapped to the correct menu created by Starter Content, allowing different header/footer menus to wire up reliably.
- Evaluation:
- The stack (CBT + boilerplate + GitHub Actions + Composer/@wordpress/scripts + Playground + Starter Content) forms an opinionated workflow optimized for agencies and frequent FSE work.
- It favours convention over configuration—ideal when you own the workflow, but requires ongoing maintenance as WordPress evolves.
- The article is practical and implementation-focused, not theoretical; no benchmarking, but strong experiential justification.
## 📚 References
- Automate Your WordPress Theme Development (original article): https://georgestephanis.wordpress.com/2026/01/06/automate-your-wordpress-theme-development/
- Create Block Theme plugin (overview): https://wordpress.org/plugins/create-block-theme/
- CBT boilerplate in the official repo (mentioned base): https://github.com/WordPress/create-block-theme/tree/trunk/assets/boilerplate
- WordPress Playground: https://developer.wordpress.org/playground/
- Playground Blueprints docs: https://developer.wordpress.org/playground/blueprints/
- `@wordpress/scripts` package: https://developer.wordpress.org/block-editor/reference-guides/packages/packages-scripts/
- WordPress Starter Content (4.7 feature): https://make.wordpress.org/core/2016/11/30/starter-content-for-themes-in-4-7/
- Example theme repository template PR (navigation slug mapping): https://github.com/georgestephanis/theme-repo-template/pull/1
## 🗣️ Paraphrase
- Paragraph A: The author needed to ship many FSE themes from Figma designs, so instead of starting from scratch each time, they invested in a reusable, automated starter theme.
- Paragraph B: Using tools like Create Block Theme, build tooling, GitHub Actions, Playground, and Starter Content, they built a boilerplate that can quickly be cloned, renamed, demoed in-browser with content, and extended via the Site Editor.
## 📰 Newsletter
WordPress theme work getting repetitive? George Stephanis outlines a practical automation stack for Full Site Editing themes: start from the official Create Block Theme boilerplate, wire in GitHub Actions for automatic namespacing, lean on `@wordpress/scripts` and Composer for build tasks, and ship Playground-powered demos loaded with Starter Content so clients see “real” sites, not blank slates. If you regularly turn Figma into themes, this workflow is worth a close look.
## ✅ Action Items
#### DevRel
- Highlight this boilerplate-based FSE workflow in talks, tutorials, and live-coding sessions for agencies.
- Build a short course on Create Block Theme + Playground Blueprints for rapid prototyping.
- Add copy-pastable examples of Blueprint configs, starter content, and navigation conversion to official docs.
#### OSPO
- Document patterns for sharing boilerplate themes as open templates, including governance for accepting changes.
- Ensure dependencies like `@wordpress/scripts` and Composer packages are license-compliant and scanned regularly.
- Promote upstream contributions to WordPress Playground and Starter Content where gaps are found.
#### Community
- Host theme automation clinics where maintainers share boilerplate setups and CI recipes.
- Pair new contributors on issues around FSE theme tooling, Blueprint examples, and starter content.
- Encourage sponsors to fund improved Starter Content and Playground UX for agencies.
#### WordPress
- Core: Improve APIs for Starter Content in block themes and better navigation migration from classic menus.
- Core Performance: Benchmark Playground-based flows vs traditional local setups for developer productivity.
- Core AI: Explore assisted theme.json generation and automated starter content scaffolding from Figma or copy.
- **Core Program Team:** Coordinate cross-team work on Create Block Theme, Playground, and starter content to keep flows coherent.
- Mobile: Investigate how Playground and starter content could complement mobile theme previews.
- Playground: Ship more first-class Blueprints for FSE theme demos, including menu and permalink setup.
- Community: Document “demo-ready” theme practices for meetups and WordCamps.
- Training: Produce lessons on FSE theme automation, from boilerplate to Playground demos.
- Marketing: Highlight case studies where automation significantly cut theme delivery time.
- Support: Add KB entries guiding developers to CBT, Playground, and starter content for client demos.
- Design: Provide `theme.json` starter palettes and typography sets for common use cases.
- Documentation: Expand examples showing end-to-end flows: CBT → boilerplate → Playground → Starter Content.
- Photos: Curate photo packs suitable for starter content in demo sites.
- TV: Record short walkthroughs of building a theme and exposing it via Playground.
- Polyglots: Ensure starter content and demo sites are translation-ready.
- Accessibility: Audit starter content templates and playground demos for WCAG compliance.
- Meta: Consider adding links from the theme directory to Playground-powered demos.
- CLI: Offer commands to scaffold FSE themes with Playground and starter content wiring.
- Hosting: Coordinate with managed hosts who might embed Playground demos in their dashboards.
- Tide: Factor in structured theme.json usage and starter content quality into scoring discussions.
- Openverse: Suggest Openverse-powered image starter content for Playground demos.
- Themes: Encourage reviewers to recognise structured starter content and automation in theme reviews.
- Plugins: Support plugins that complement CBT, Playground, and starter content pipelines.
#### The WPCC
- Programs: Support fellows working on FSE boilerplates, demo kits, and starter content upgrades.
- Projects: Run documentation sprints around FSE automation workflows.
- Funding experiments: Pilot microgrants for agencies that open-source their automation stacks.
### FAIR
- Technical independence: Encourage local copies of boilerplates with clear provenance, tags, and signed releases.
- Policies and covenants: Publish transparent guidelines on sponsorship or funding for playground-based tooling.
- Productized governance artifacts: Provide templates for boilerplate governance, contributor roles, and evaluation scorecards.
## 🧪 Hypotheses
- H1: Teams using a CBT-based boilerplate with automatic namespacing will reduce initial setup time for new FSE themes by at least 50%.
- H2: Themes demoed via Playground with Starter Content will receive more useful client feedback than blank or minimally populated demos.
- H3: Moving most styling into `theme.json` instead of Sass/CSS will reduce editor vs front-end visual discrepancies.
- H4: Preconfigured Composer and `@wordpress/scripts` pipelines will increase the proportion of themes that ship with translations and code formatting enabled.
### 📊 Methodology
- Run time-tracked experiments across several teams spinning up new themes with and without the boilerplate.
- A/B test client demos: Playground with rich starter content vs basic staging sites; survey perceived quality and clarity.
- Compare bug reports and support tickets related to visual mismatches before and after adopting `theme.json`-centric styling.
- Analyze repo histories for presence of build scripts, translations, and formatting in projects using vs not using preconfigured tooling.
### ❓ Questions
- How can Create Block Theme and Starter Content be more directly integrated for block themes, without extra bootstrap PHP?
- Could Playground Blueprints eventually manage navigation migrations and slug/ID mapping automatically?
- What’s the best way to keep a boilerplate updated as FSE and core APIs evolve without breaking existing themes?
- How might Figma or design tokens flow directly into `theme.json` in a repeatable way?
### 🔮 Future Research
- Explore more robust navigation mapping APIs (e.g., slug-based and location-based configurations).
- Investigate standardized “demo blueprints” that theme authors can bundle or link from the directory.
- Prototype design-to-`theme.json` pipelines that integrate with popular design tools.
- Study long-term maintenance costs and benefits of complex boilerplates in agency environments.
### 💡 Implications
- Practice: Agencies can standardize on automation-heavy FSE workflows, improving delivery speed and consistency.
- Policy: WordPress could recommend minimum automation and demo standards for themes marketed to clients.
- Security: Preconfigured Composer and CI flows can embed security checks and linting by default.
- Education: Training materials need to shift from hand-built themes to editor-first + automation-first approaches.
- Funding: Sponsoring shared boilerplates and Playground tooling may be a high-leverage way to support the ecosystem.
### 🧠 Learning Styles Assessment
- Reading level estimate: Approximately late high school / early college. (Rough Flesch-Kincaid estimate based on sentence length and technical vocabulary.)
#### 👀 Visual learners
- Present: Descriptive explanations of flows (e.g., how Playground ties to GitHub), but mostly text.
- Improve: Add diagrams of theme creation pipelines, Blueprint flowcharts, and before/after screenshots of starter content demos.
#### 🔊 Aural learners
- Present: None explicitly.
- Improve: Provide a short audio walkthrough or screencast narration of setting up a new theme from the boilerplate.
#### 🗣️ Verbal learners
- Present: Clear explanations of tools (CBT, Playground, Starter Content) with contextual examples.
- Improve: Add analogies (e.g., “boilerplate as a factory line”) and a short glossary for newer FSE terms.
#### 🧩 Kinesthetic learners
- Present: Implied hands-on steps (clone repo, run Playground, etc.), but not fully procedural.
- Improve: Add step-by-step checklists and small “try this” labs for creating a demo theme.
#### 🧠 Logical learners
- Present: Reasoned arguments about why automation and `theme.json`-first styling are beneficial.
- Improve: Include more explicit comparisons, tables of pros/cons, and simple metrics (time saved, errors avoided).
#### 🧑🤝🧑 Social learners
- Present: References to client/stakeholder feedback loops.
- Improve: Suggest team-based exercises (e.g., pair building a theme, review each other’s Blueprints).
#### 🧘♀️ Solitary learners
- Present: Article is suitable for independent, deep reading.
- Improve: Add reflection prompts (e.g., “list your current theme setup steps and where automation fits”).
#### 🌿 Naturalistic learners
- Present: None.
- Improve: Light analogies to ecosystems (e.g., boilerplates as habitats that support many theme “species”) or sustainability of reusing patterns vs bespoke work.
### 📊 Accessibility Assessment
#### Screen reader semantics
- Present: Standard blog structure likely with headings; no detailed info in the article itself about semantics.
- Improve: Ensure all code snippets, links, and images (if any) have descriptive text and proper heading hierarchy.
#### Keyboard navigation
- Present: Default theme likely supports focus and logical reading order.
- Improve: Verify skip links and clear focus styles in any sample themes built from the boilerplate.
#### Contrast and readability
- Present: Depends on the WordPress.com theme used; article text likely adequate.
- Improve: Encourage high-contrast palettes in starter `theme.json` presets.
#### Text resizing and reflow
- Present: Standard WordPress responsiveness.
- Improve: Test themes derived from the boilerplate at 200% zoom and with reduced-motion preferences.
#### Media and captions
- Present: Article is text-based; no media discussed.
- Improve: Add captions/transcripts for any future video demos of the workflow.
#### Forms and interactions
- Present: Not applicable within the article; indirectly relevant to playground demos.
- Improve: Ensure any demo forms in starter content follow accessible label and error patterns.
#### Standards reference
- Map potential gaps in starter content and demo themes to WCAG 2.2 AA (e.g., 1.4.x contrast, 2.1.x keyboard, 2.4.x navigation).
### 🌍 DEIB Assessment
#### Cultural breadth
- Present: Focused on tooling; culturally neutral.
- Improve: Include examples from different locales and languages when discussing starter content.
#### Inclusive language
- Present: Neutral, technical tone; minimal jargon but assumes some FSE familiarity.
- Improve: Add brief explanations when introducing specialized tools and link to beginner resources.
#### Neurodiversity support
- Present: Clear structure and short sections, but dense concepts.
- Improve: Use more subheadings, bullet lists, and consistent patterns for describing each tool.
#### Representation
- Present: No people depicted or quoted beyond the author.
- Improve: Share use cases from a range of agencies and contributors globally.
#### Psychological safety
- Present: Encouraging, non-judgmental tone; emphasizes experimentation.
- Improve: Explicitly invite questions and experimentation, and link to community spaces where help is available.
### ✅ Logical Validity
#### Strong reasoning
- The argument that automation via boilerplates and GitHub Actions replaces fragile manual scripts is causally strong: fewer manual steps → fewer errors and faster setup.
- The claim that `theme.json`-driven styles improve WYSIWYG consistency is supported by shared configuration between editor and frontend.
- Using Playground for client demos is logically justified: instant, up-to-date demos lower friction for feedback.
#### Fallacies
- None obvious. Some claims are experiential rather than empirically measured but not overstated.
#### Tone of voice
- Practical, conversational, and modest: acknowledges imperfection (“No, of course not. But no project ever really is.”) while still advocating for the workflow’s usefulness.
### 🛡️ DARVO Analysis
- Deny: No denial or minimization of harm; article is purely technical.
- Attack: No attacks on individuals or groups.
- Reverse victim/offender: Not present; there is no conflict or accusation context.
- The piece is cooperative and solution-oriented rather than defensive.
## 🎯 Conclusion
The article presents an opinionated but practical automation stack for FSE theme development centered on Create Block Theme, a lean boilerplate, GitHub Actions, Composer + `@wordpress/scripts`, Playground, and Starter Content. For developers repeatedly building themes, adopting similar patterns can significantly reduce setup time, improve demo quality, and create a more reliable, editor-first workflow.
## 🧱 Refactor Appendix (append after 🎯 Conclusion)
### 📚 Literature Split Pad
- Purpose: Stage Konik CEE units that become per-source Literature notes.
- Split level: **H3**.
- Include verbatim quotes under 25 words and a [view highlight] link.
### [H1] Automating FSE theme boilerplates accelerates delivery
> [!quote] [Automate Your WordPress Theme Development](https://georgestephanis.wordpress.com/2026/01/06/automate-your-wordpress-theme-development/) by [[George Stephanis]] via [[WordPress.com]]. Published 2026-01-06. Accessed {{date:YYYY-MM-DD}}.
> “For me, though, it’s a great starting point, and has saved me a bunch of time for client work.”
Used to justify investing in standardized, automated FSE boilerplates.
[view highlight](https://read.readwise.io/read/01ked1m98mm01j3eptkpacmq36?endLexposition=0001K_00000-0017&startLexposition=0001E&emphasizeText=For+me%2C+though%2C+it%E2%80%99s+a+great+starting+point%2C+and+has+saved+me+a+bunch+of+time+for+client+work.) #xref #articleseed ID:rw_[MISSING]
### [H2] Playground demos make FSE themes easier to trial
> [!quote] [Automate Your WordPress Theme Development](https://georgestephanis.wordpress.com/2026/01/06/automate-your-wordpress-theme-development/)
> “It makes it trivial to set up a test site and let a user (or client or stakeholder) instantly test out a plugin or trial a theme.”
Context for advocating Playground-based demo environments for client feedback.
[view highlight](https://read.readwise.io/read/01ked1m98mm01j3eptkpacmq36?endLexposition=0000o_00001_00000-000Q&startLexposition=0000g&emphasizeText=It+makes+it+trivial+to+set+up+a+test+site+and+let+a+user+%28or+client+or+stakeholder%29+instantly+test+out+a+plugin+or+trial+a+theme.) #xref ID:rw_[MISSING]
---
### 🔖 Atomic Split Pad (Zettel Candidates)
- Purpose: Promote reusable claims into Atomic notes.
- Split level: **H4**.
- Each item: one idea, present tense, specific, testable.
#### [Z1] Boilerplate automation accelerates FSE theme setup
- In agency contexts reusing similar patterns across many client themes.
- Pointer: article section on namespacing and boilerplate setup.
- Links: [[WordPress-Theming]] [[Developer-Automation]]
#### [Z2] Playground demos improve client feedback on themes
- When demos are wired to current GitHub state and seeded with starter content.
- Pointer: article section on Playground and Blueprints.
- Links: [[WordPress-Playground]] [[Client-Feedback-Loops]]
---
### ✏️ Fleeting Queue (Extract by Selection)
- Purpose: Capture quick actions or sparks for Fleeting notes.
- Extraction: **Select one line** → “Refactor: Extract selection to new note (content only).”
- Keep each line short and self-contained.
- [F1] Try forking the theme-repo-template and wiring a Playground Blueprint — context/https://georgestephanis.wordpress.com/2026/01/06/automate-your-wordpress-theme-development/ #fleeting #inbox
- [F2] Evaluate moving more CSS into theme.json for better editor parity — context/https://georgestephanis.wordpress.com/2026/01/06/automate-your-wordpress-theme-development/ #fleeting #inbox
- [F3] Prototype a workshop around CBT + Playground + Starter Content — context/https://georgestephanis.wordpress.com/2026/01/06/automate-your-wordpress-theme-development/ #fleeting #inbox
---
## 🧰 Template Library (paste into Note Refactor → Refactored Note Template)
<!-- Copy ONE template at a time into the plugin before running each batch. -->
### 📝 Fleeting — Refactored Note Template (Konik-ready)
---
type: fleeting
status: inbox
created: {{date:YYYY-MM-DD}} {{time:HH:mm}}
process_by: {{date:YYYY-MM-DD}} # review within 24–48 hrs
source_title: [MISSING]
source_link:
author: [MISSING]
source_type: article|paper|video|podcast|thread
reading_stage: inspectional|analytical|syntopical
project:
tags: #fleeting #inbox
---
# 📝 Fleeting Note — {{title}}
## 🧠 One-liner (my words)
- State the single idea in one short sentence.
## 🧭 Context & cue
- Where did this arise? Page/timecode/speaker.
- Trigger: quote, data point, claim, or question.
## 🧪 Adler checks (quick)
- What is this about as a whole?
- What is said in detail, and how?
- Is it true? Evidence for or against?
- So what? Impact or next move.
## 🔎 Bias & reliability snapshot
- Possible bias or framing?
- What evidence would change my view?
## 🧩 Konik bridge
- Draft a claim header for promotion.
### [H1] 5–10-word present-tense claim
> [!quote] [{{source_title}}]({{source_link}}) by [[{{author}}]]. Accessed {{date:YYYY-MM-DD}}.
> “Short quote under ~25 words.”
One line on why this matters.
[view highlight]({{source_link}}) #xref ID:rw_[MISSING]
## 🧰 Next moves (pick 1–2)
- [ ] Promote to *Literature* with citation.
- [ ] Draft *Atomic* claim from [H1].
- [ ] Park as testable question.
## ✅ Processing checklist
- [ ] Rewrote in my words.
- [ ] Decided: trash | keep | convert.
- [ ] Linked to at least one related note.
- [ ] Tagged and moved out of inbox.
---
### 📚 Literature — Refactored Note Template (Konik-ready)
---
type: literature
status: draft
created: {{date:YYYY-MM-DD}} {{time:HH:mm}}
adler_level: inspectional|analytical|syntopical
reading_stage: inspectional|analytical|syntopical
source_title: [MISSING]
author: [MISSING]
year:
publisher_or_journal:
edition_or_volume:
doi:
url:
accessed: {{date:YYYY-MM-DD}}
citekey:
project:
tags: #literature #reading
---
# 📚 Literature Note — {{title}}
## 🧰 Action Inbox
- [H1] Short action — context/{{url}} #articleseed
- [H2] Short action — context/{{url}} #xref
- [H3] Short action — context/{{url}} #share
## 🧭 Bib Capsule
- Title, author, year, venue, and link.
- One-line scope: what the work attempts.
## 🧠 Author’s Thesis (their words)
- Core claim briefly. Include page/timecode.
## 🧩 Key Arguments
- Argument A — method/evidence — page/time.
- Argument B — method/evidence — page/time.
- Argument C — method/evidence — page/time.
## 🧪 Evaluation (Adler)
- What is this about as a whole?
- How is it argued? Fairly and clearly?
- Is it true or plausible? Why?
- So what? Practical or theoretical impact.
## 🗒️ Notes (Konik CEE units)
### [H1] 5–10-word present-tense claim
> [!quote] [{{source_title}}]({{url}}) by [[{{author}}]] via [[{{publisher_or_journal}}]]. Published {{year}}. Accessed {{accessed}}.
> “Verbatim highlight under ~25 words.”
Two lines: context and use. Link to data if relevant.
[view highlight]({{url}}#H1) #xref #articleseed ID:rw_[MISSING]
### [H2] 5–10-word present-tense claim
> [!quote] [{{source_title}}]({{url}}) by [[{{author}}]] via [[{{publisher_or_journal}}]]. Published {{year}}. Accessed {{accessed}}.
> “Verbatim highlight under ~25 words.”
Two lines: context and use.
[view highlight]({{url}}#H2) #xref ID:rw_[MISSING]
## 🔖 Zettel Candidates
#### [Z1] 5–10-word present-tense claim
- One-line context and page/time.
#### [Z2] 5–10-word present-tense claim
- One-line context and page/time.
## 🏷️ Tag Coverage
#articleseed: 0 • #xref: 0 • #share: 0 • #bmf: 0 • #addendum: 0
## ✅ Processing Checklist
- [ ] Thesis captured in my words.
- [ ] 1–3 Zettel candidates drafted.
- [ ] Action Inbox pruned to high-signal items.
- [ ] Cross-links added and filed.
---
### 🔖 Atomic (Zettel) — Refactored Note Template (Konik-ready)
---
type: atomic
id: {{date:YYYYMMDDHHmm}}-{{title}}
status: evergreen
created: {{date:YYYY-MM-DD}} {{time:HH:mm}}
origin: reading|thinking|experiment
proof_state: conjecture|working|supported|refuted
source_literature: [[Source-Literature-Note]]
citekey:
project:
tags: #zettel #idea
---
# 🔖 {{title}} <!-- 5–10 words, present tense, specific -->
## 🧠 Claim
- One idea only. Clear and testable.
## 🧾 Evidence & Pointers (Konik)
- [H#] from [[{{source_literature}}]] — page/time — brief rationale.
- ID:rw_[MISSING] — link to highlight or dataset.
> [!quote] Evidence snippet (≤25 words) if essential.
> Cite page/time. Keep it minimal.
## 🔍 Scope & Conditions
- When this holds. Boundaries and exceptions.
## 🔗 Links
- Broader: [[Parent-Concept]]
- Narrower: [[Specific-Case]]
- Related: [[Parallel-Idea]]
## 🧪 Tests / Falsifiers
- One check that could disconfirm the claim.
- Simple study or observation plan.
## 🧰 Implications
- Practice, policy, or design moves in one line each.
## 🔙 Backlinks
- From: [[{{source_literature}}]] • Context line.
## ✅ Maintenance
- [ ] Links in and out.
- [ ] Title still precise?
- [ ] Proof state updated.
```
## Highlights
- There’s really not a lot to it. A header and footer partial, a general index template, and a theme.json file that starts defining parameters. The idea is that you’ll start creating more templates and patterns in the Site Editor and then save them to the theme as needed. ([View Highlight](https://read.readwise.io/read/01kedafdcgxc0vkwxmpqzdzdtb))
- Tags: 👻 ai highlighted
## 🌱 Spawned Notes
- [[Lit · Automating FSE theme boilerplates accelerates delivery]]
- [[Lit · Playground demos make FSE themes easier to trial]]
- [[Zet · Boilerplate automation accelerates FSE theme setup]]
- [[Zet · Playground demos improve client feedback on themes]]
- [[Flt · Try forking the theme-repo-template and wiring a Playground Blueprint]]
- [[Flt · Evaluate moving more CSS into themejson for better editor parity]]
- [[Flt · Prototype a workshop around CBT Playground Starter Content]]