The Vue Router migration (T428481) moved more state to the client so the router could do the heavy lifting, module body HTML included, through getJsData(). MediaWiki has no Vue SSR, so the client recompiled those server-rendered strings on mount rather than adopting them. render() stopped being the thing that puts a module's body on the page: getJsData() carried the HTML and the client re-injected it. @Dillon spotted that render() was no longer being called server-side, and pulling that thread turned up the rest of the damage: module bodies dropping, the Banner module broken, and a no-JS visitor served a blank page.

We were previously pointing towards islands architecture by accident. The server was already emitting a card frame; the client was already hydrating bodies into it. We had built half of islands by accident and skipped the other half, the part that pins down who owns what, which happens to be the half that keeps it working.

This task restores the contract and the islands split, and ships the logic for 3 modules kinds (server side, progressive enhancement, vue island). It does not convert any default module to server-side rendering yet; putting that logic to work on the default modules is a follow-up.

The three render modes we inherited from GrowthExperiments (desktop, mobile-summary, mobile-details) ran two separate decisions through one string:

• which platform the server renders for
• how much detail to show

Splitting them lets the server settle platform and the client derive detail.

This restores a clean split and names the pattern. The server renders each module's card frame with an empty slot, and the client teleports its Vue island into that slot. The only rendering decision the server makes is platform, desktop or mobile; detail level, the compact card versus the full view, is the client's call and never reaches PHP. One serverRendered() flag now distinguishes three kinds of module:

• Vue island (the default): a server frame with an empty slot the client fills in.
• Server-static: the whole body is server HTML the client leaves alone (Banner, ReturnToHomepage).
• Progressively enhanced: a server body plus a behavior module that enhances it in place, no re-render.

Codex ships a server-side PHP library (Wikimedia\Codex), but it covers presentation and form components only: Card, Button, InfoChip, Message, Field, TextInput and the like. Anything with client state, a dialog, a popover, a menu, a combobox, has no PHP builder and lives only in the Vue library. The same no-SSR constraint that broke the old approach also means we cannot server-render one of those and hydrate it; the PHP and Vue libraries are two implementations of one design, not a single isomorphic render.

Progressively enhanced module support fills that gap: a module renders the presentation half server-side so no-JS users get real content, then layers the interactive Vue component on top. The contract supports it here; the first conversion of a default module, Policies & Guidelines, is the follow-up.

Without JavaScript the page renders server frames rather than a blank page: server-static modules show their content, island bodies fill in once JS loads behind a noscript notice, and a module name in the subpath renders that module's focused subpage, the destination the dashboard's in-body links fall through to.

*Acceptance criteria*

Contract

• render() is the sole source of a module's server HTML; getJsData() carries only bootstrap data (enabled, header, expandable, serverRendered), never body or footer HTML.
• Island modules emit an empty slot server-side and the client teleports the Vue body into it.
• Server-static modules (Banner, ReturnToHomepage) render their full body server-side and the client leaves them in place.
• The contract supports a progressively enhanced module, a server body enhanced in place by a behavior module; no default module is converted in this task.

No-JS

• A no-JS visitor sees server frames rather than a blank page, with a noscript notice explaining bodies that only fill under JS.
• A module name in the subpath renders that module's focused subpage, the no-JS destination an expandable card's anchor falls through to.

Coverage

• PHPUnit covers the contract: getBodyContent() returns the empty slot for an island and the full body for a server-rendered module, and the mobile card wraps in its self-link but drops that anchor on a focused render.