DX UI

WordPress plugin that turns a design export — Lovable, Claude Design, a Vite/React, Vue, Next.js or plain HTML/CSS/JS archive, a pasted component, or a Figma file — into editable Gutenberg pages: every section a block, the header and footer in Appearance › Menus and Widgets (or kept with the page), images and fonts in the site, and the look of the design intact.

The plugin is called DX UI (menu: DX); the repository, the text domain and the code still say dxai-ui.

Tour of the admin panel, recorded before the Designs screen — click the picture to play it (about a minute): Convert, the Library (its panels are a design's tabs now, its collections the Site screen), Form entries, Settings.

• Install
• Using the plugin
• Working on the plugin
• More documentation

Requirements

PHP 8.2+ (with dom, libxml, mbstring, zip), WordPress 6.6+, an administrator account with unfiltered_html, a writable wp-content/uploads. A block theme is not required: converted pages use the plugin's own DX Blank page template, which works under classic themes too. The full list is in readme.txt.

Install

1. Get dxai-ui-<version>.zip (a release, or build it yourself — see Build a release).
2. Plugins › Add New › Upload Plugin, choose the ZIP, Activate.
3. Open DX in the admin menu.

To try it first, open it in WordPress Playground (blueprint.json: the newest release, logged in, on DX).

Updates come as any plugin's do: Dashboard › Updates offers each new release of this repository's GitHub releases (the header's Update URI; betas while the site runs a beta — dxai_ui_update_channel chooses). A development checkout — this repository linked into a site — is never offered one: WordPress deletes the folder it replaces, and through the link that is the repository.

Activation stops and names any PHP extension that is missing. Do not update the plugin from wp-admin on a site where it is a junction to this repository (see the working environment).

Using the plugin

The admin menu DX has five screens: Designs (every design on the site, and a page for each with eight tabs: Overview, Pages, Look, Blocks, Words, Speed, Transfer, History), Convert, Site (the site's template, and the collections every import adds to), Form entries and Settings.

1. Settings (only if you need an AI engine)

A design archive is compiled by the plugin itself — colours, images, fonts, motion, pages — with no AI call. The AI engines (Anthropic Claude, OpenAI, xAI Grok, DeepSeek) and the Figma token are for a pasted component, a Figma file, and for Write with AI on a design's Words tab. Add the keys in DX › Settings (keys are encrypted at rest and never sent back to the browser), choose the provider and model, and press Test active engine.

2. Convert a design

DX › Convert is a six-step wizard:

Importing the same design again updates its pages in place; nothing on the site is deleted.

YouTube videos are never put on a page as a live player: a player loads its scripts and trackers for every visitor, whether anyone watches or not. A YouTube iframe in a design (also the markup an AI engine writes) becomes the team's example: two embeds of the video that are hidden (block visibility, they are what the editor shows, so the address can be changed there) and a facade for the phone and for the desktop (<div class="youtube-facade" data-video-id data-video-title>, in the groups "Mobile iFrame" and "Desktop iFrame"). Only the video's id and title change from one video to the next. The player loads when a visitor presses the facade. The facade is drawn (thumbnail and play button) and swapped for the player by a script, and the phone's and the desktop's are told apart by mobile-show and mobile-hide: the American Restoration theme has the script and the styles. They are not there on a converted page (the theme's scripts and styles are detached from it) or on another theme, so there the plugin prints its own copy (assets/js/youtube-facade.js, assets/css/youtube-facade.css, 768px as the theme's breakpoint), only on a page that has a facade and never on a page of a theme that brings its own. The two work together if both are loaded. A theme can say it has them with add_theme_support( 'dxai-youtube-facade' ) or the dxai_ui_theme_has_youtube_facade filter. Before WordPress 6.9, which cannot hide a block, only the two facades are written. A map, a playlist or a video file is left as the design wrote it.

3. Work with what was made — Designs

DX › Designs lists every design on the site — its pages, its sections, where it is (six chips: imported, native blocks, theme colours, theme fonts, its states and whether the Interactivity API drives them, exported) and when it was last imported — with search and two filters, and opens a page for each design: Overview (what to do next, and the design report), Pages, Look, Blocks, Words, Speed, Transfer (export the package, import one) and History (the import snapshots, with Restore). What is the site's rather than one design's is on DX › Site: the template (the theme, the header in Menus, the footer in Widgets, the logo, the fonts, DX Base) and the collections (every generated page with Export, the synced patterns, the headers and footers, the menus, the conversions). The panels on a design's tabs, one for each thing you may want to do with it:

4. Fonts and colours follow the theme

A converted page can use the site's own fonts and colours instead of the design's:

• Fonts, on a theme that lets the site choose them (the DevriX themes: Theme Global Settings › Fonts). Headings use the headline font, everything else — paragraphs, spans, links, buttons, labels — the body font. The design's own fonts are not used and are not uploaded again: the page uses the theme's font files and asks for no others. Code (pre, code) stays monospace and icon fonts keep their glyphs. Nothing in the page's content is rewritten, so a change in Theme Global Settings reaches every design at once. A design that already had its fonts copied is put on the theme's with an update (its font rules leave its stylesheet, kept in a record so they can be put back, and the font files no stylesheet names are removed); a design can be set to keep its own fonts with the design's Speed tab › Use the design's own fonts.
• A theme that does not manage fonts (a block theme such as Twenty Twenty-Five) leaves designs in their own fonts, copied to the site as before. Another theme can opt in with the dxai_ui_theme_fonts filter (the two font stacks, their slugs and the @font-face rules to print).
• Theme Global Settings (the ACF options page of the DevriX themes), when the site has it and the owner filled a field: the fonts and the colours as above, the primary logo (the header draws it before the Site Logo, as the theme does, and an import does not give the site the design's logo when it has one), and the radius of buttons and cards (border_radius_style: the theme's own lengths are printed after the theme's button styles on a page that does not load the theme's stylesheet). Without ACF, on another theme, or with a field left empty, nothing is read and everything works as before. dxai_ui_theme_option supplies a value from elsewhere.
• Colours, on any theme with a palette (classic or block). A design's Look tab binds its colours to the theme's palette, by role; switch Follow the theme's colours on for the design. Until then it keeps its own.

5. Form entries

Forms in converted pages store their submissions in WordPress. DX › Form entries lists them (date, email, message, page) and exports a CSV.

6. From the command line

wp dxai-ui … (add --user=<admin> where a command writes):

Working on the plugin

The working environment

The plugin is developed on Windows with Local (PHP 8.2, nginx, MySQL), and the repository is the plugin: Local loads it through a directory junction, so every saved file is live.

1. In Local create a site named DXAI-UI (domain dxai-ui.local, PHP 8.2, nginx, MySQL), as in docs/LOCAL-WP.md.
2. Link the repository into the site's plugins folder (a junction, from a Command Prompt):

   mklink /J "C:\Users\<you>\Local Sites\DXAI-UI\app\public\wp-content\plugins\dxai-ui" "C:\path\to\DXAI-UI"

3. Activate it: wp plugin activate dxai-ui (or in wp-admin). Admin: http://dxai-ui.local/wp-admin/admin.php?page=dxai-ui.
4. Install the admin build tools: npm install (Node 20 or newer).

Local's command-line PHP has no php.ini, so scripts that need WordPress go through bin/wp-php.sh, which supplies the extensions and the site's MySQL port (Local changes it when it restarts the site; DXAI_DB_PORT=<port> overrides). wp-cli is not on the PATH either: keep a wp-cli.phar and a dxai-cli.ini in .verify/tools/ (git-ignored) and run php -c .verify/tools/dxai-cli.ini .verify/tools/wp-cli.phar --path=<wp-root> ….

Build the admin app

npm install          # once
npm run build        # production build into assets/build/
npm start            # watch mode while editing assets/src/admin/

The PHP needs no build. assets/build/ is not committed: npm run build creates it, and the release builds it again so a ZIP can never ship a stale bundle.

Templates: a theme and the team's sections for it

The sections a page is made of belong to a template: a theme (or a kind of theme) and the team's sections written in its blocks, classes and colours. The plugin carries one, American Restoration's (data/block-library, for that theme and the DX themes made from it: Pages\Template). A site whose theme has no template gets the generic library: the same sections, made in core blocks (the theme's label block as a paragraph, its box with a link as a group whose title is the link, its picture as core's picture), in the colours this theme's palette has for the same roles (a dark ground, the brand's colour, an accent, a light ground: read from the palette by what the colours are), with the theme's font sizes and button styles where it has them. The panel says which is in use. The sections' own layout classes are the plugin's own rules, so they stand on any theme; what a template's theme adds (its component styles, its patterns in the inserter) is only there on that theme. dxai_ui_templates adds templates; dxai_ui_template names the one to use (a test does).

A site keeps templates of its own too, in its uploads (wp-content/uploads/dxai-ui/templates/<slug>/: the exports as they came, library.json, the layouts' blocks — Pages\Library_Store). In DX › Site › Team libraries, upload a WordPress export of a site the team built (Tools › Export, pages), or a page copied from the editor's code view, for a theme: the plugin reads its pages into layouts the way it read American Restoration's (Pages\Layout_Builder, below), keeps the export, and lays out the pages made on that theme with them — before the built-in template, and together with it when the library is made to extend it (a library for American Restoration that adds the team's newer sections to the plugin's). Upload more exports to train it: each is kept, and the library is built again from all of them, the same arrangements counted together. Open a library to see its layouts and the build's report; remove it and the pages already made keep their sections. Only an administrator; nothing of the exported site reaches a page, not even its name (verify-libraries.php holds it to that). wp dxai-ui library list|create|add|build|delete does the same from the command line.

Build the team's layouts

The pages made in the team's style are laid out with the team's own layouts, kept in the plugin (data/block-library/blocks/layout-*.html, listed in library.json with source: layout; sixty-five of them: forty-four from the eleven live sites, twenty-one from the team's two showcase pages). They are read from the pages of the team's finished sites — the structure, and the words that are every page's: every line of theirs becomes a slot ({{t:h2-s}}, a heading of a short length; {{row:title}} in a repeated card; {{t:call}} on a phone button), and a line that says nothing of one site stays in its slot as its first words ({{t:p-m|We work with all insurance companies.}}, with [[company]], [[phone]], [[subject]], [[region|the area]] where the site's own facts were; a line with a figure, a street, a tool, a platform, a name, or that goes on about the page's own service is not kept), every picture of a row a row's picture, every drawing a marker to the plugin's own (data/block-library/icons, bin/build-icons.cjs extracts them from the lucide package), a picture laid under a section stays behind (it is the site's decoration), a brand's colour goes (a dark band of it becomes the theme's dark, so its light words stay readable) and a theme colour stays, and a site's classes, scripts and ids go; a card's second link to its page goes (a row has one page), and a section of a list — reviews, steps, questions, badges, places, related pages — whose rows were a widget or a picture is no layout at all. Nothing of the sites reaches a page, not even their names (verify-block-library.php holds it to that). The builder is a developer's tool; the plugin ships only its result.

wp eval-file bin/build-layouts.php --user=1 <pages dir> [<export.xml> …] [dry] [only=<role>] [max=<n>]
node bin/build-icons.cjs

<pages dir> holds one JSON a page (id, title, site, url, content), as a database dump of the sites gives; an <export.xml> is a WordPress export (WXR) of the team's own showcase — the test page with every block of theirs — read as a site of its own, every arrangement of which counts once (the sections the library already holds by hand, from the same pages, are not taken twice). The builder picks, for every role but the hero and the form, up to eight structures: up to half from the showcase, the rest the ways the live sites use most, from as many sites as there are; it writes data/block-library again, keeping the sections built by hand. After it, run verify-block-library.php.

Run the checks

The whole pack runs with one command, each suite judged by one rule — exit 0 is PASS, 1 is FAIL, 77 is SKIP (something it needs is not here; a line SKIP: <why> says what), anything else is an ERROR, and a pass that ran no checks is an ERROR too:

node bin/run-suites.cjs --wp "wp --path=/path/to/a/test/site" --group ci --strict

--wp is however wp-cli reaches the site you test on, run from this folder (CI uses npx @wordpress/env run cli --env-cwd=wp-content/plugins/dxai-ui wp). bin/suites.json puts every suite in a group: ci runs on a clean WordPress (this plugin, DX Base, Twenty Twenty-Five, nothing imported), local needs what a working site holds (the American Restoration theme, imported designs), manual and browser are run by hand. --strict fails a SKIP too, and a bin/verify-* file the manifest does not list. The pack packs the fixture archives first (bin/pack-fixtures.php: .verify/ is not in git).

The static checks need composer install once, then composer check: every PHP file and script parses (bin/lint.cjs), the PHPCS gate holds (phpcs.xml.dist: security, prepared SQL, translations, PHP 8.2 and later — not formatting), and PHPStan finds nothing that is not in phpstan-baseline.neon. node bin/hooks-doc.cjs writes docs/HOOKS.md, the filters and actions the plugin fires; document a hook with a comment above its call.

CI (.github/workflows/ci.yml) runs the static checks, hooks-doc --check, the admin build and the ci group under --strict on wp-env for every push to main and every pull request.

Each suite is a PHP script that loads WordPress, runs its checks offline against fixtures, prints ok / FAIL, and exits non-zero on a failure:

bash bin/wp-php.sh bin/verify-speed.php            # or: wp eval-file bin/verify-speed.php --user=1
bash bin/wp-php.sh bin/verify-theme-fonts.php
bash bin/wp-php.sh bin/verify-native-blocks.php
bash bin/wp-php.sh bin/verify-team-pages.php
bash bin/wp-php.sh bin/verify-block-library.php
bash bin/wp-php.sh bin/verify-libraries.php