Step 2: Connect plugin and renderer

Get the full loop running on a throwaway WordPress: visitor → WordPress → signed request → renderer → HTML.

Run the renderer

cd renderer
npm ci && npm run build
FLX_RENDER_DEPLOYMENT=local PORT=3000 node dist/server.js
curl -s localhost:3000/health        # {"success":true,…}

Install the plugin on the test site

wp plugin install flx-modernize --activate
wp option update flx_modernize_render_url http://127.0.0.1:3000

The CI workflow (.github/workflows/step0-fidelity.yml) does exactly this on a fresh WordPress, plus the steps from step 1. Two details that cost time if you miss them:

• Run WordPress's PHP server with several workers (PHP_CLI_SERVER_WORKERS=4). While rendering, the renderer calls back to WordPress for the theme CSS; a single-worker server deadlocks.
• Give WordPress an absolute path without ../; WordPress refuses to create upload folders under such paths.

Sign the requests

SECRET=$(openssl rand -hex 32)
wp config set FLX_MODERNIZE_RENDER_KEY_ID site1 --type=constant
wp config set FLX_MODERNIZE_RENDER_SIGNING_SECRET "$SECRET" --type=constant
# renderer side:
FLX_RENDER_SIGNING_KEYS="site1:$SECRET" FLX_RENDER_AUTH_MODE=enforce …

Check: a logged-out request for a page returns HTML that links the renderer's /static/styles.css, and curl -X POST localhost:3000/api/v1/render/page without signature headers gets 401.

See what the plugin sends

When a page looks wrong, look at the payload before touching the renderer. A read-only wp eval that calls the payload builders (for example \FlxModernize\Payloads\NavigationPayloadBuilder::build( home_url( '/' ) )) shows exactly what the renderer receives. On Twenty Twenty-Five this found two problems that no amount of renderer work would have fixed:

• The menu payload was empty because menu items were saved as page links, not custom links. Fixed in the plugin.
• The theme CSS was missing in production because Cloudflare challenged the renderer's CSS fetch. Fixed in Cloudflare; see step 3.