My WP/Woo Plugin Scaffolding in 2026 🔗 **Source:** [My WP/Woo Plugin Scaffolding in 2026](https://www.briancoords.com/my-wp-woo-plugin-scaffolding-in-2026/) > [!note]+ Document Notes > tags: [WordPress, WooCommerce, Plugins] > author: Brian Coords > source: briancoords.com > reference: [https://www.briancoords.com/my-wp-woo-plugin-scaffolding-in-2026/] > date created: 2026-02-15 10:30 > > # 🏷️ Title: My WP/Woo Plugin Scaffolding in 2026 > <!-- 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 - The author refines a personal WooCommerce/WordPress plugin starter to better fit AI-assisted “agentic” development. - It matters because traditional scaffolding (e.g., `create-block` with mustache templates) doesn’t align well with LLM workflows. - Key stakeholders: WordPress/Woo developers, AI tool builders, hosting providers, and the Core AI team. - Risks/tradeoffs: relying on evolving AI tools, missing emerging WP build systems, and lack of standardized best practices for modern admin UIs/DataViews. - Bottom line: ship real, fully working plugin scaffolds and rich examples so AI agents can reliably build modern WP/Woo interfaces. ## 📖 Main Content - The author reflects on Woo “Getting Started” docs and how rapid AI changes keep everyone in a perpetual beginner state. - Traditional scaffolding via `wordpress/create-block` uses mustache templates that are hard to test and iterate on; in an AI world, string-replacement and boilerplate generation are better delegated to agents. - Instead, the author now builds a fully functional starter plugin that mirrors their real workflow: React-based admin screens (often via Woo or WP settings APIs), DataViews backed by private CPTs/taxonomies, and dynamic blocks using the Interactivity API, all built with WordPress Scripts. - AI already excels at repetitive code (CPTs, meta, REST endpoints, basic tests) but struggles with newer, more complex React-based admin UIs and modern block patterns; the scaffold focuses on those “hard parts.” - Two caveats: experimental extensible site editor tooling is still too early to rely on, and best practices for DataViews/DataForms are immature, so the starter is opinionated and provisional. - The repo doubles as both working code and instruction set for agents (“here’s where things go, how to rename, what to wire up”), avoiding mustache indirection so the scaffold itself can be run, tested, and evolved. - The author publishes the starter on GitHub and questions whether `create-block` is still the right approach for agentic coding, suggesting an “agent code library” of indexable, high-quality example repos for modern admin and block development. - They explore whether WordPress can be a “vibe-coding” platform: not competing with Replit/Lovable’s blank-slate model, but leaning into WP’s strengths as a powerful CMS/e‑commerce system and UI layer for non-technical content managers. - WordPress must serve both front-end presentation and application UI needs, which creates a heavy cognitive load for developers and for AI models trying to generate WP-specific UIs. - Many hosts are building AI site/block builders aimed at novices, but the author doubts the long-term moat once general-purpose coding agents can simply “build my WordPress site” directly. - They distinguish between optimizing AI clients to better interact with WordPress vs. making WordPress itself easier for any agent to use (especially UI components and blocks). - While the Core AI team improves external AI interaction with WP data and APIs, the author is focused on enabling LLMs to construct admin UIs and block-based layouts as easily as generic React+Tailwind apps. - They argue the best investment is in solid docs and a rich, centralized library of real-world examples (blocks, patterns, admin components) so models can more reliably generate high-quality WP interfaces. - The piece ends by sharing the Woo extension starter and inviting feedback on boilerplate ingredients and improvements. ### 🗒️ Notes - AI’s rapid evolution keeps even experienced Woo developers in a “getting started” mindset. - `wordpress/create-block` was previously the preferred way to scaffold projects but its mustache-based templates are awkward for testing and for AI agents to learn from. - In an AI-first workflow, templates should showcase idiomatic code and patterns; agents can handle repetition and string substitution. - The author’s starter centers on: - React admin screens registered via Woo or WP settings pages. - DataViews backed by private CPTs/taxonomies to reuse WP’s data layer and REST API. - Interactivity API-based dynamic blocks for front-end content. - WordPress Scripts for flexible builds across admin bundles and multiple blocks. - AI is good at: - Registering post types, meta fields, REST endpoints. - Verifying JavaScript build setups. - AI is weak at: - Complex React admin UIs. - Building DataViews/DataForms. - Assembling cohesive block-based pages with WP’s specific APIs/components. - Experimental extensible site editor tooling and routing look promising but are too unstable to bake into a starter today. - DataViews and DataForms lack canonical examples; the author’s implementation is pragmatic rather than authoritative. - The new workflow: clone the starter, run Claude Code or Codex, describe the new plugin and naming, and let the agent wire features using the scaffold’s instructions. - Because the starter is a real, running plugin (not mustache templates), it can be tested directly and iterated on; improvements in one production plugin can be backported into the scaffold by an agent. - The GitHub repo is intended as a shared resource others can fork or critique, surfacing better practices for the community. - The author suggests WordPress may need an “agent code library” of high-signal, functional examples to feed training data and improve codegen quality, especially vs. other frameworks that already have rich example ecosystems. - WordPress’s challenge is unique: it must be both a page builder and an app framework for non-technical users, blending front-end layout with admin UX. - Many hosted AI builders focus on onboarding new users, but their value may erode as general-purpose agents become the primary interface for creating sites. - Strategic question: optimize for in-house AI builders, or make WordPress so agent-friendly that any external LLM can excel at building WordPress sites? - The author favors the latter: make core UI components, blocks, patterns, and admin primitives “dead simple” for models to discover and use via great docs and a robust catalog of examples. - Empowering existing users and developers with AI and better scaffolds should turn them into evangelists for the ecosystem. ## 📚 References - WordPress `create-block` tool — https://developer.wordpress.org/block-editor/reference-guides/packages/packages-create-block/ - WordPress Interactivity API overview — https://developer.wordpress.org/block-editor/reference-guides/interactivity-api/ - WordPress Scripts (`@wordpress/scripts`) — https://developer.wordpress.org/block-editor/reference-guides/packages/packages-scripts/ - WooCommerce developer docs — https://developer.woocommerce.com/ - WordPress Playground — https://developer.wordpress.org/playground/ ## 🗣️ Paraphrase - The author has created a personal Woo/WP plugin starter that reflects how they actually build modern, React-heavy admin interfaces and blocks, designed to work hand‑in‑hand with AI coding agents instead of traditional mustache-based scaffolding. - They argue WordPress should prioritize making its UI components, blocks, and admin patterns extremely legible to LLMs via strong documentation and rich examples, rather than chasing proprietary “AI site builder” moats, and they share their starter to spark community discussion. ## 📰 Newsletter Staying productive with WordPress in 2026 increasingly means pairing your workflow with AI. Brian Coords just published a WooCommerce-focused plugin starter that swaps mustache-heavy `create-block` scaffolds for a fully functional, React-based extension template designed for Claude Code/Codex. If you’re building DataViews-backed admin UIs, Interactivity API blocks, or just want a realistic boilerplate for modern WP/Woo dev, this is a great reference—and a reminder that our ecosystem still needs a centralized “agent-friendly” library of examples. ## ✅ Action Items #### DevRel - Highlight this scaffold as a concrete example in talks and workshops on “agentic” WordPress development. - Build small, task-focused demos (e.g., adding a new DataView) using the starter and publish them as reference repos. - Improve docs around React-based admin screens, DataViews, and Interactivity API usage so AI agents and humans share the same canonical patterns. - Run content campaigns comparing traditional `create-block` workflows vs. agent-driven scaffolds, measuring adoption and friction points. - Survey developers on what they need most from a centralized “agent code library” for WordPress. #### OSPO - Encourage corporate contributors to upstream high-quality, production-tested admin UI and block examples under permissive licenses. - Establish contribution guidelines for AI-oriented example repos (code style, documentation, test coverage). - Integrate license and provenance metadata into example libraries to support responsible AI training. #### Community - Organize contributor sprints focused on building and documenting modern admin screens, DataViews, and DataForms. - Create mentorship paths around “AI-assisted plugin building,” pairing experienced WP devs with newcomers. - Encourage sponsors to fund work on official example repos and educational materials that lower the barrier to building complex WP interfaces. #### WordPress - Core: prioritize developer-facing examples showing how to build complex admin UIs, not just front-end blocks. - Core Performance: profile React-based admin screens and Interactivity API patterns included in scaffolds to ensure they scale. - Core AI: align external AI integration work with an internal push for “model-friendly” UI components and documentation. - **Core Program Team:** coordinate initiatives across Documentation, Core, and Marketing to promote a central library of example plugins/components. - Mobile: explore how agent-built features and blocks translate into mobile admin/app experiences. - Playground: provide presets that load vetted starter plugins (like this Woo extension) for experimentation. - Community: add “AI-assisted development” tracks to meetups and WordCamps, featuring scaffolding workflows. - Training: create lesson plans around building a plugin from the starter using an AI agent. - Marketing: tell stories of developers who ship faster with high-quality scaffolds plus AI agents. - Support: document common failure modes when AI-generated code misuses WP APIs, and how scaffolds mitigate them. - Design: offer reusable Figma/component libraries that map directly to core UI packages and are easy for AI to reference. - Documentation: add end-to-end examples covering CPT+DataView+Interactivity flows. - Photos / TV: produce screen-recorded walkthroughs of using the starter with AI and caption them thoroughly. - Polyglots: translate key scaffold documentation into major community languages. - Accessibility: ensure example plugins and scaffolds follow WCAG 2.2 AA to set a strong baseline. - Meta: improve .org’s discoverability and indexing of “example plugins” as a first-class resource. - CLI: explore CLI commands for cloning and customizing official scaffolds with minimal prompts. - Hosting: coordinate with hosts on exposing “start from vetted scaffold” options alongside AI site builders. - Tide: evolve scoring to recognize adherence to modern, well-documented patterns in example plugins. - Openverse: surface educational media around AI and WP dev in curated collections. - Themes: align block theme examples with plugin scaffolds for coherent full-stack patterns. - Plugins: streamline review for educational scaffold plugins while keeping strict security checks. #### The WPOCC - Fund microgrants for maintainers building and curating agent-friendly example repos. - Run documentation and example-building sprints centered on modern WP admin and Interactivity API usage. - Pilot matched grants for scaffolds that prove high adoption in learning environments. ### FAIR - Promote technically independent, locally clonable scaffolds with clear provenance and versioning. - Encourage transparent funding and governance for example libraries so no single vendor captures the ecosystem. - Treat scaffolds and governance docs (codes of conduct, contribution models) as reusable, productized assets. ## 🧪 Hypotheses - H1: Providing fully functional, opinionated WP/Woo scaffolds significantly reduces time-to-first-feature for AI-assisted plugin development. - H2: A centralized, curated library of admin/UI and block examples improves LLM output quality for WordPress-specific tasks. - H3: Developers using AI agents plus robust scaffolds will favor WordPress over generic SaaS “vibe-coding” tools for business applications. - H4: Lack of standardized best practices for DataViews/DataForms is a key bottleneck in modern WP admin development. ### 📊 Methodology - Run controlled studies comparing devs building the same Woo extension using (a) `create-block` templates vs. (b) the new scaffold with an AI agent; measure completion time, bug count, and subjective friction. - Fine-tune or evaluate LLMs on corpora with and without curated WP admin/block examples; compare code correctness and adherence to best practices. - Survey plugin developers about tool choices and satisfaction before and after adopting agent-oriented scaffolds. - Analyze GitHub telemetry (forks, stars, issues) and plugin directory stats for scaffold-based projects. ### ❓ Questions - What minimal set of patterns (CPTs, DataViews, Interactivity, settings screens) should every “official” WP scaffold include? - How can WordPress core structure docs to be maximally consumable by AI agents as well as humans? - Where should an “agent code library” live and how should it be governed? - How will experimental features like the extensible site editor reshape recommended scaffolding patterns? ### 🔮 Future Research - Systematically catalog common admin UI patterns across major plugins and turn them into reusable, documented components. - Explore dedicated evaluation benchmarks for “WordPress code generation” tasks across major LLMs. - Investigate how to keep scaffolds aligned with rapidly changing WP APIs (e.g., site editor, Interactivity API). ### 💡 Implications - Practice: Developers can ship Woo/WP extensions faster by starting from working, AI-ready scaffolds. - Policy: Project leaders may need to formalize example libraries as first-class assets in the WordPress ecosystem. - Security: Central, vetted scaffolds reduce the risk of insecure patterns proliferating via AI-generated code. - Education: Training programs can pivot to teaching scaffold+AI workflows rather than raw boilerplate writing. - Funding: Sponsorship can move from “one-off docs” to maintaining evergreen example repositories. ### 🧠 Learning Styles Assessment - Reading level estimate: ~college/early professional (Flesch–Kincaid Grade ≈ 11–13) due to technical vocabulary and long sentences. #### 👀 Visual learners - Present: mental models of admin screens, DataViews, and blocks; screenshot reference. - Improve: add architecture diagrams showing data flow between CPTs, DataViews, REST, and React admin screens. #### 🔊 Aural learners - Present: none explicitly. - Improve: provide a short audio walkthrough or podcast-style explanation of the scaffold and workflow. #### 🗣️ Verbal learners - Present: conceptual explanations, comparisons (`create-block` vs. functional scaffold), clear terminology. - Improve: add more analogies (e.g., “agent code library” as a recipe book) and concise glossaries. #### 🧩 Kinesthetic learners - Present: implied hands-on path (clone repo, run AI agent, build plugin). - Improve: turn this into explicit step-by-step labs and checklists. #### 🧠 Logical learners - Present: clear problem→solution→implication reasoning (from mustache pain to agentic scaffolds). - Improve: include simple decision trees for when to use which scaffolding approach. #### 🧑‍🤝‍🧑 Social learners - Present: invitation to community feedback and forking on GitHub. - Improve: add discussion prompts and recommended venues (Slack channels, forums) for sharing scaffolds. #### 🧘‍♀️ Solitary learners - Present: blog format supports solo reading and reflection. - Improve: add reflection questions like “What does my ideal plugin starter need?” #### 🌿 Naturalistic learners - Present: none directly. - Improve: tie the ecosystem metaphor (WordPress as an ecosystem) to sustainability and long-term maintainability of patterns. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: typical blog structure with headings; likely acceptable. - Improve: ensure headings are hierarchical and images (like admin screenshots) have descriptive alt text. #### Keyboard navigation - Present: standard theme likely supports basic keyboard navigation. - Improve: verify focus styling and logical tab order in example admin UIs. #### Contrast and readability - Present: depends on theme but likely meets basic contrast. - Improve: check contrast ratios for code examples and screenshots; adjust fonts/line-height for dense technical text. #### Text resizing and reflow - Present: responsive layout should support zooming. - Improve: verify 200% zoom behavior and minimize horizontal scrolling in code samples. #### Media and captions - Present: static images; no audio/video. - Improve: describe images more fully and consider linking to live Playground demos. #### Forms and interactions - Present: minimal on the article page. - Improve: ensure any demo plugins use accessible forms (labels, error messaging, hit areas). #### Standards reference - Map improvements to WCAG 2.2 AA criteria for text alternatives, adaptability, distinguishability, and keyboard access. ### 🌍 DEIB Assessment #### Cultural breadth - Present: globally relevant developer topic but mostly US/Western framing. - Improve: include examples from diverse markets and languages, and note multilingual plugin considerations. #### Inclusive language - Present: generally neutral, avoids stereotypes. - Improve: reduce insider jargon or explain it for less-experienced developers. #### Neurodiversity support - Present: structured into sections; some chunking. - Improve: add more subheadings, bullet lists, and explicit summaries for dense passages. #### Representation - Present: individually authored technical perspective. - Improve: reference diverse voices or projects in the WP dev community tackling similar problems. #### Psychological safety - Present: inviting tone; open to criticism (“tell me how I’m doing it wrong”). - Improve: explicitly normalize experimentation and learning in public. ### ✅ Logical Validity #### Strong reasoning - Inductive: from personal experience with mustache-based scaffolds and AI agents, the author infers that fully functional scaffolds are more compatible with agentic coding; this is well grounded in concrete workflow pain points. - Causal: argues that better docs and examples will improve AI’s ability to generate WP UIs; plausible given how LLMs rely on training data and documentation. #### Fallacies - None obvious; some extrapolation about future AI site builders and moats is speculative but framed as opinion, not fact. #### Tone of voice - Reflective, practical, and mildly opinionated; mixes technical specifics with accessible metaphors (“vibe-coding platform”). ### 🛡️ DARVO Analysis - Deny: no denial or minimization of harm; the piece is constructive and technical. - Attack: no attacks on individuals or groups; vendors and tools are discussed respectfully. - Reverse victim/offender: not present; the author doesn’t position themselves or WordPress as a victim. ## 🎯 Conclusion The article proposes a pragmatic response to AI-era WordPress development: replace fragile template scaffolds with real, opinionated starter plugins that reflect modern React-based admin and block patterns, and build a centralized library of such examples. For readers, the next steps are to experiment with the shared Woo extension scaffold, adapt it to their workflow, and contribute patterns and documentation back to the wider WordPress ecosystem. ## 🧱 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] 5–10-word present-tense claim > [!quote] [{Title or entity}](https://www.briancoords.com/my-wp-woo-plugin-scaffolding-in-2026/) by [[Brian Coords]] via [[briancoords.com]]. Published 2026-02-09. > “I’ve published it on GitHub with the hope that anyone can use it or even fork and change it to suit their preferences.” Two lines: context and use. Cite data if relevant. [view highlight](https://www.briancoords.com/my-wp-woo-plugin-scaffolding-in-2026/#H1) #xref #articleseed ID:rw_[MISSING] ### [H2] 5–10-word present-tense claim > [!quote] [My WP/Woo Plugin Scaffolding in 2026](https://www.briancoords.com/my-wp-woo-plugin-scaffolding-in-2026/) > “AI is great and doing that kind of automated labor.” Two lines: context and use. [view highlight](https://www.briancoords.com/my-wp-woo-plugin-scaffolding-in-2026/#H2) #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] Functional scaffolds improve AI-assisted WP coding - Scope/condition in one line. - Pointer to page/time or dataset. - Links: [[WordPress-Scaffolds]] [[AI-Agents]] #### [Z2] Central example libraries boost code quality - Scope/condition in one line. - Pointer to page/time or dataset. - Links: [[WordPress-Examples]] [[LLM-Training-Data]] --- ### ✏️ 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 Brian Coords’s Woo extension starter in a Playground sandbox — context/https://www.briancoords.com/my-wp-woo-plugin-scaffolding-in-2026/ #fleeting #inbox - [F2] Draft a minimal agent-friendly WordPress scaffold for non-Woo use cases — context/https://www.briancoords.com/my-wp-woo-plugin-scaffolding-in-2026/ #fleeting #inbox - [F3] Outline requirements for a centralized “agent code library” on WordPress.org — context/https://www.briancoords.com/my-wp-woo-plugin-scaffolding-in-2026/ #fleeting #inbox --- <!-- deep-read:sections end -->