Test report – Midground 1.1.0

All figures come from real runs on 26 September 2026 against the local Docker environment (WordPress 7.1.2, PHP 8.3, MariaDB 11, WooCommerce 11.1.2) and, for the minimum versions, a fresh WordPress 6.6 on PHP 8.1. Browsers: Chromium, Firefox and WebKit from Playwright 1.63. Nothing is estimated. Raw data is in tests/results/ (not versioned) and can be recreated with the commands in each section.

Summary #

1. JavaScript unit tests (tests/js) #

The motion engine (interpolation per channel, combining effects, transform order, strength scaling), CSS value validation and the style compiler against shared test data, number formatting identical to PHP, document operations (insert, move, remove, style inheritance, allowed children).

2. PHP integration tests (tests/php) #

They run inside the real WordPress through WP-CLI; a PHP warning from Midground code turns a test red. Services of other companies are answered by local stand-ins (see status). Covered:

• Document model: invalid input, stable and duplicate ids, junk nodes, unknown element types kept safely, children that are not allowed, depth and size limits, sanitising per field type (inline HTML, rich text, links, numbers, dates, places, enums), scripts only for administrators, styles per screen size and injection attempts, attributes, effects, background video, SEO settings, migration from schema 1, JSON shape.
• Conditions and templates: matching, specificity before priority, priority and last change for equal rules (with a conflict), exceptions, facts from a real WP_Query; header and footer created once on first run, retired when replaced, the Site information for the editor.
• Storage: static copy and block structure, live rendering, revisions with the document and restore, original content stored once and restored exactly, edits made in another editor noticed and never overwritten, autosave, refresh without a revision.
• Motion: every built-in recipe (text reveal, hover and pointer included) gives valid data, strength 0 = rest, screen-size factors, custom keyframes, extensions.
• Media and fonts: 3D model validation, background video sources, the Google Fonts copy (only real font files, only from Google's font host, only administrators), @font-face served from the site.
• New elements: icon boxes (numbers however they are typed; a removed icon stays removed), reviews (rating and screen reader text; Google and Trustpilot through stand-ins, cleaned, cached, last good reviews kept), countdown (dates in the site's time zone), forms (the static copy keeps the shortcode), map (OpenStreetMap by default, Google only with a key, nothing loads by itself), background video (only safe settings, nothing before consent), API keys (checked, never exported). Slider, logo band, text band, popup, announcement bar, booking and language switcher are covered by the browser tests.
• Platform: SEO settings and cooperation with SEO plugins, WPML and Polylang, client mode (the server keeps layout and styles whatever is sent), export and import (images linked or copied, components re-linked), the licence layer with a stand-in shop, the AI assistant with a stand-in service, the move from Kulisse 1.0.
• Starter sites: every starter site imports without errors, takes over the front page, header and design, renders every page, updates instead of duplicating, and removing it restores the earlier design; fonts are copied when asked and fall back to a bundled font.
• Import, rendering, REST and life cycle: block and classic import, every element in editor, front-end and static mode, PHP/JS parity of the style compiler, the capability matrix for five roles, validation (400/404/413), a locked post gives 423, activation creates no content, uninstall keeps pages and documents, the documented extension example.

3. Browser tests (tests/e2e) #

Playwright, one worker, in five projects: desktop-chromium, desktop-firefox and desktop-webkit (1440×900) run every test; mobile-chromium (Pixel 7) and mobile-webkit (iPhone 14) run the tests marked @mobile.

• Chromium (desktop-chromium): 101 passed, 0 failed, 1 skipped
• Pixel 7 (mobile-chromium): 12 passed, 0 failed
• Firefox (desktop-firefox): 101 passed, 0 failed, 1 skipped
• WebKit (desktop-webkit): 101 passed, 0 failed, 1 skipped
• iPhone 14 (mobile-webkit): 12 passed, 0 failed

The one skipped test on the desktop projects is the phone editor test, which runs on the phones. In total 327 passed, 0 failed, 3 skipped on purpose.

4. Accessibility #

axe-core 4.13 with the WCAG 2.0/2.1 level A and AA rules, at rest (reduced motion, so animations are not measured half-way):

"passed" means no serious or critical violation. Each starter site row checks every page of that site (4, 3, 4, 4, 3 and 2 pages); those checks run on the desktop projects.

Also: a keyboard test (skip link, visible focus, every focused element visible, no focus trap), the editor tour (focus kept in the tour card, Escape closes, arrow keys step through), popups as real dialogs, reduced motion (no transforms, pinned scenes released), content readable without JavaScript, without WebGL and when the runtime fails. Not done: a manual test with a screen reader (see status).

5. Clean install and life cycle (tests/install/clean-install.sh) #

A new WordPress (its own database) on port 8089 with the packages from dist/:

1. Install and activate the theme and plugin from the ZIP files; activation creates no content.
2. First visit to the admin: a header and a footer are created once.
3. Build a page: heading, text, effect and CSS show; the revision has the document.
4. Update (reinstall over an older version number): the upgrade routine runs, the static copies are refreshed in the background, content is intact.
5. Deactivate: heading and text still show, the theme's fallback styles load, no PHP errors.
6. Uninstall (default): page, document, template and settings are kept; the plugin files go.
7. Reinstall: the document can be edited again.
8. Uninstall with "delete on uninstall": templates and settings are deleted, the page is kept and still readable.
9. The Skumring showcase without WooCommerce: import and removal work, no shop is created.
10. A starter site (Brightwater Plumbing): its front page, header and colours take over; removing it puts the earlier colours back.

All 100 PHP files of the theme and plugins also pass php -l on PHP 8.1.30.

The latest-version install was run three times on the final packages: twice 45 / 45, and once 44 / 45 – the check that reads the starter site's front page straight after the import did not find its heading in one run. It passed in the other two runs and on the minimum versions, and the cause was not found; it is noted here rather than hidden.

Commands:

python tools/package.py
bash tests/install/clean-install.sh
MG_WP_IMAGE=wordpress:6.6-php8.1-apache MG_CLI_IMAGE=wordpress:cli-php8.1 MG_PHP_TESTS=1 bash tests/install/clean-install.sh

6. Performance (tools/perf.mjs) #

Cold cache, median of 3 runs. Phone: Pixel 7, 4× CPU slowdown and a "Slow 4G"-like network (150 ms RTT, 1.6 Mbit/s). Desktop: 1440×900 without throttling. Measured locally; not Lighthouse.

KB = compressed transfer (gzip) measured in the network layer. "JS Midground" is the runtime; on the 3D page the 3D viewer (166.1 KB, three.js) and the model (213.4 KB, GLB) load only when the model comes near the screen – not with the page. The two starter site rows are measured on their own after importing each starter site (design included, fonts not copied from Google, so the bundled fonts stand in) into the same installation. Motion runtime per scroll frame (desktop, every effect active): business page 11 elements, median 0 ms, 95th percentile 0.1 ms, max 0.2 ms; 3D page 12 elements, median 0 ms, 95th percentile 0.1 ms, max 0.3 ms; Loopwise 4 elements, max 0.4 ms.

Against the budgets in the plan:

7. Translations #

All 2,596 / 2,596 strings are translated to Norwegian (Bokmål): 1,846 for the builder, the theme and the showcase from before, plus 750 new ones – the editor tour and Help menu, the Starter sites screen and the content of the six starter sites (bash tools/i18n.sh). The user guide exists in English and Norwegian. The Norwegian editor and site are checked by 12-norwegian.

8. What was found and fixed during testing #

Found by the tests and fixed before delivery:

• iPhone and iPad: tapping an element in the editor did not select it. Safari only turns a tap into a click where a click listener sits below the document; the canvas now has one. The editor's bottom sheets also spilled under the bottom bar on short phones, and the top bar's buttons overlapped on narrow screens.
• Safari: a page with a background video file never finished loading while the video started; video files now start after the page has loaded (which also helps every browser's loading time).
• Contrast (axe-core on every starter site page): key figures in the accent colour, text on the accent-coloured call to action, countdown labels, a label on the sale band and WooCommerce's greyed-out "Add to cart" button had too little contrast; all fixed (icon box groups got a shared number colour for this).
• Layout: outlined text bands were invisible (the outline took the transparent text colour), hidden screen-reader texts in carousels widened the page, long e-mail addresses in footers pushed the page wider, review cards left an empty column, key figures sat one per row on phones, booking buttons could not take colours.
• Layout shift on phones (found by the performance measurements): a menu that folds into a button first showed as a list until the runtime had started, and the fonts the design uses were not all preloaded (CLS 0.09 on the restaurant starter site on a throttled phone). Pages are now marked as scripted before they are drawn (with a fallback if the runtime never starts), and the heading and body fonts – bundled or copied from Google Fonts – are preloaded.
• Product page on phones: WooCommerce's image gallery jumped while its slider started (CLS 0.44). The gallery now keeps the tallest image's proportions from the first paint: 0.048.
• Found while building the showcase sites (showcase/): a header template's "Stick to the top" setting had no effect on the site, and a page's "Header over the first section" only worked with the theme's own header; both now work with Midground headers, and the header gets its own background back when the page scrolls (33-header). Titles in features, post lists, plans, questions and large quotes ignored the type settings (a one-weight serif was shown in a fake bold); "Remove icon" on icon boxes and features did not stick; captions, quote roles and archive descriptions were grey-on-dark on dark sections, and WooCommerce's stock text was too pale. All fixed.
• Editor: the overlay around the selected element rewrote the page many times per second even when nothing changed; the tour now keeps the keyboard focus even while the editor settles; the showcase's colour names were saved in Norwegian on English sites.

Tests that were changed because a browser behaves differently (not because of a fault): Safari's Tab key skips links unless the visitor turns that on, so the keyboard test focuses the skip link directly in WebKit; mobile WebKit in the tests has no mouse wheel; four tests now wait for a save, a preview or the right settings panel instead of racing it.

Firefox under the test machine's app sandbox had to be started from its real installation folder (PLAYWRIGHT_BROWSERS_PATH); this is about the test machine, not the product.

9. Not tested and known limits #

See status: real devices and Safari on macOS/iOS, a manual screen reader test, multisite, other WooCommerce product types and payment methods, measurements over a real network, and the features that were verified only with stand-ins for other companies' services.