# UnblockWP Features > [!question] Lingering Questions > - How is the Twig markup stored per block, and is it portable if the plugin is deactivated — graceful degradation, or broken residue like classic shortcode lock-in? > - Does "one clean HTML element" hold through nested loops and conditions, or do control primitives reintroduce wrapper divs? > - Is the shipped "accessibility audits" skill validated against WCAG 2.2 AA, or is it heuristic LLM output with no conformance evidence? > [!tip] Article Ideas > - A side-by-side "core blocks vs. UnblockWP" rendered-DOM demo measuring wrapper count and CSS payload — turns an unbenchmarked vendor claim into a testable comparison. > [!link] Cross Reference > - [[3. Resources/MOCs/Open Source Governance MOC]] — the BYO-key AI assistant is a small but real anti-lock-in governance pattern worth tracking alongside FAIR. > - [[Core Abilities Must Be Consumer-Neutral Primitives Not One Interface's Mirror]] — related existing note on WordPress AI-connector architecture. > [!quote] Vocabulary > - **Timber / Twig** — Timber is a mature WordPress templating library built on Twig; UnblockWP's data layer is explicitly "Timber-inspired," borrowing a proven expression language rather than inventing a proprietary one. > - **BYO-key AI** — routing an AI assistant through the user's own API key (OpenAI/Anthropic/Google) rather than a bundled proprietary model, so cost and governance stay with the site owner. ## Bibliographic capsule UnblockWP features page (unblockwp.com/features), ~400 words, a developer-oriented WordPress block tool's marketing page. Not a study — vendor claims, unbenchmarked. ## Author's thesis (as argued) Every UnblockWP block renders a single clean HTML element with full control over markup, styles, scripts, and data — "nothing is abstracted away" — positioned directly against the nested-`<div>` output of core blocks and most page builders, and backed by a Twig/Timber-style data layer, a BYO-key AI assistant, and a per-page critical-CSS performance strategy. ## Key arguments (≤3) 1. **Clean, controllable block output is the entire pitch.** The page leads with "each block renders a single clean HTML element" as a direct response to a known WordPress pain point (wrapper-div bloat, duplicated CSS). 2. **A Twig-based data layer, explicitly modeled on Timber, wires content into blocks** with 50+ formatting filters and zero-config integration with ACF/Meta Box/JetEngine/Pods — choosing a mature, AI-familiar language sidesteps the cold-start problem of a proprietary expression syntax. 3. **The AI assistant deliberately avoids vendor lock-in** by routing through WordPress AI connectors with the user's own API key rather than bundling a proprietary model — an architecturally responsible choice that shifts cost and governance to the user. ## Claim atoms ### Blocks can render one clean HTML element > [!quote] ID:rw_unblockwp_01 > "Each block renders a single clean HTML element. You control the markup, the styles, the scripts, and the data. Nothing is abstracted away." Where/why: opening line of the features page — the product's entire spine; names the core WordPress pain point (wrapper-div bloat) in one breath. ### Twig data layer borrows Timber's proven model > [!quote] ID:rw_unblockwp_03 > "A Timber-inspired data layer using Twig, a proven templating language for WordPress." Where/why: anchors a new expression system to a trusted, AI-familiar language — explains why the AI assistant can reliably author expressions. ### AI assistant is BYO-key, not proprietary > [!quote] ID:rw_unblockwp_04 > "No proprietary AI system. Unblock connects through WordPress AI connectors with your own API key, currently supporting OpenAI, Anthropic, and Google." Where/why: a responsible-AI governance precedent for plugin authors, aligned with where WordPress Core AI/Abilities direction is heading. Promoted below as a new Permanent note. ### Per-page critical CSS is the performance lever > [!quote] ID:rw_unblockwp_05 > "One CSS file per page with only the styles it uses. Small files are inlined in the head." Where/why: the load-bearing, most-testable performance claim — the one a Core Performance reviewer should benchmark before repeating. ## Permanent candidates - **BYO-key AI connectors are a responsible-AI governance pattern for plugins** (H4) — not yet captured by an existing note. Promoted below as a new Permanent note. - Clean block output as a marketable product category (H1) is a genuine claim but reads more as market observation than a durable, falsifiable claim — held back from promotion pending a rendered-DOM benchmark that would make it testable. ## Processing checklist - [x] Checked for an existing Permanent note before creating — none found for this source. - [x] Promoted the BYO-key AI governance claim to a new Permanent note. - [ ] Build the core-blocks-vs-UnblockWP rendered-DOM comparison before treating the clean-markup claim as anything beyond a vendor assertion. - [x] Connect into [[3. Resources/MOCs/Open Source Governance MOC]] and [[3. Resources/MOCs/AI & the Future of Knowledge Work MOC]]. ## Metadata - Source: [[3. Resources/Literature Notes/UnblockWP Features]] ## Links - [[3. Resources/MOCs/Open Source Governance MOC]] — BYO-key AI as a small anti-lock-in governance pattern. - [[3. Resources/MOCs/AI & the Future of Knowledge Work MOC]] — AI-connector architecture choices shape who bears cost/governance for AI features.