Site conversion checklist

For: building a Flx renderer for one client site. Each site gets its own renderer, built for that site's theme as the client has customised it (colours, fonts, header, footer, templates). The tutorial explains the techniques; this page is the order to apply them in, and what to check at each step.

1. Intake (before any code)

• Stack: theme and version, WordPress and PHP versions, and the plugin list. Flag plugins that print styles or scripts in the page head or footer: they carry over (since 1.6.0), but check each one on the staging copy, especially styles aimed at theme markup and scripts with no file of their own (see Flx Modernize). With WooCommerce active, the plugin keeps the store, and shoppers with a cart, on normal WordPress (since 1.7.0). A store on the Storefront theme can opt in (since 1.8.0); step 17 of the tutorial lists what else to check for a store.
• Pages: which routes the site uses (home or blog index, archives, posts, pages, search, 404) and which templates (for example "Page No Title"). Each template in use needs its own layout in the renderer.
• Styles: the style variation, custom colours and fonts, and any Additional CSS.
• Header and footer: screenshots on desktop and phone, the menu open and closed. Mark which parts are WordPress menus (Navigation blocks) and which are static: logo, text, links, social icons.
• Target: agree the fidelity band with the client: 70% acceptable, 80% good, 90% perfect.

2. Staging copy

Copy the site (database, uploads, theme settings) to a throwaway WordPress. Every measurement and experiment runs on that copy, never on the live site: the checks seed content, switch plugins and load pages many times.

3. Baseline

Pick the measured pages: one per template the site uses, plus a few representative posts and pages. Run the fidelity check on the staging copy and record the starting score per page.

4. Build

• Start from the closest renderer (the Twenty Twenty-Five package for a Twenty Twenty-Five site).
• Styles: use the site's own colour and font presets (they arrive as CSS variables). Check the body font matches the site's typography, not the theme default.
• Header and footer: a Tailwind layout restyled to match the site's own header and footer. A Tailwind template is a fine starting point, but the result must look like the client's site, not the template.
  • Hard-code the logo, layout, static text and static links.
  • Never hard-code menu items. Render them from the navigation payload (labels, links, current page, sub-menus), so the client's menu edits in WordPress appear without a renderer change.
  • If the footer uses a WordPress menu, send it like the header menu (a plugin change) rather than copying its links.
• Templates: one layout per template the site uses, from the theme's own markup (step 6).

5. Verify

• The fidelity check on the staging copy reaches the agreed band on every measured page, desktop and phone.
• The safety checks pass: who gets Flx, cache headers, head and footer output (step 7).
• In a real browser: the menu on desktop (hover and keyboard into sub-menus), the phone menu (open, close, Escape), a search, a 404 and a comment.

6. Go live

Deploy the renderer, connect the plugin with its signing key, and check live pages: Flx-rendered, the right cache headers, and deactivating the plugin rolls back at once (step 8).

7. Hand-off record

Write down, per site:

• what is hard-coded in the header and footer, so a later design change there is known to need a renderer update;
• the fidelity score per page at hand-off;
• the hours spent.