Flx Modernize sends the content of a page to a Flx Render service, a Node.js app, which returns the finished HTML page in your theme’s look. WordPress keeps handling each request, so its hooks and plugins keep running. If the Render service is unavailable, WordPress renders the page itself.

This release supports sites using the Twenty Twenty-Five theme. A Twenty Twenty-Five renderer package is available from modernize.flexplat.com; you can run it yourself or have it hosted for you. WooCommerce stores on the Storefront theme can opt in as well; see “WooCommerce stores” below.

See it in 60 seconds

The same WordPress page with Contact Form 7 and a jQuery lightbox, first in a typical Next.js + REST API front end, then rendered by Node.js with Flx Modernize. Try it yourself on the plugin demo page (visit it logged out).

What is rendered through Flx

The blog home page, category and tag archives
Single posts and pages
Search results
The “Page not found” (404) page, still sent with a real 404 status

The theme’s header with its menu, and its footer, appear on every one of these pages. What your plugins print in the page head and footer carries over too: the title, SEO tags (for example from Yoast SEO), structured data and scripts such as analytics. So do plugin styles, and plugin scripts together with the WordPress scripts they need, such as jQuery.

What always stays normal WordPress

Anyone who is logged in (administrators and editors always see normal WordPress). A WooCommerce store can let logged-in customers have its catalogue pages; see “WooCommerce stores” below
Previews, drafts, private, scheduled and password-protected content
Feeds, embeds, robots.txt, trackbacks and any request other than GET or HEAD
Visitors who have commented (WordPress’s comment cookies), and reply or “awaiting moderation” links, so they see their own pending comment and a filled-in form
With WooCommerce active: the shop, product pages, product categories and tags, the cart, checkout and My account pages, product search and WooCommerce’s own requests; visitors with something in their cart; and the whole site while WooCommerce’s “Coming soon” mode is on. A store that opts in changes some of this; see “WooCommerce stores” below
Page types your Render service does not offer: when it answers that it has no such page type, WordPress serves that type for the next hour without asking again

WooCommerce stores

Off unless a site opts in, with the constant FLX_MODERNIZE_WOOCOMMERCE in wp-config.php. It needs the Storefront theme and a Render service that draws Storefront, such as the Storefront renderer package. Any other theme, or a theme or WooCommerce template this release wasn’t reviewed against, stays normal WordPress.

The shop, product categories and tags, products and Storefront’s home page go through Flx, for visitors with or without something in their cart. Every visitor gets the same page, built with an empty cart, and WooCommerce’s own scripts fill in the visitor’s cart in the browser. No cart or customer data is sent to the Render service.
A further constant, FLX_MODERNIZE_WOOCOMMERCE_SHELL, puts the site’s header and footer from the Render service around the Cart and a guest’s My account page, and FLX_MODERNIZE_WOOCOMMERCE_SHELL_CHECKOUT does the same for Checkout. WordPress fills in these pages on your own server, so their contents are never sent. What comes from the Render service for these pages must pass a strict check, built on WordPress 6.9’s output buffer: no scripts and no forms. If it doesn’t pass, or on older WordPress, these pages stay normal WordPress. If you take real payments, ask your payment provider or assessor before turning on Checkout.
Logged-in customers stay normal WordPress, unless the store also sets FLX_MODERNIZE_LOGGED_IN_CUSTOMERS. Then they get the same catalogue pages as a guest, built the same way with nothing about them sent; WordPress marks the page as logged in and hides the review form’s name and email fields, which come from their account. Everything else stays normal WordPress for them, and anyone who can edit content or run the store always does. Leave it off if your prices or products differ per customer (memberships, wholesale or role-based prices).
Order pages, product search and sorted or filtered lists always stay normal WordPress.

Safety

Only anonymous visitors get Flx pages (and, on a store that turns it on, logged-in customers on catalogue pages), and the page data is always built as an anonymous visitor.
No visitor data is sent to the Render service: no cookies, no user account and no query-string values. The one exception is the words a visitor searches for, because the search results page shows them.
Requests to the Render service can be signed with a key only your site holds; a Render service in enforce mode rejects anything else.
Flx pages are sent with Cache-Control: private, no-store, unless you turn on edge caching (below). A page served by WordPress because the Render service failed is always sent with no-store.
If the Render service fails after a page was started, the normal page is fetched fresh from your own site, as the same visitor, so nothing the plugin did while preparing the page can change it. If your server cannot reach its own address, WordPress serves the page directly, as in earlier versions. Setting FLX_MODERNIZE_LOOPBACK_FALLBACK to false in wp-config.php turns the fresh fetch off.
Deactivating the plugin instantly returns the whole site to normal WordPress.

Edge caching (optional)

Off by default. Add define( 'FLX_MODERNIZE_EDGE_TTL', 300 ); to wp-config.php (seconds, 60 to 3600) and Flx pages that are the same for every visitor can be stored by your CDN: pages, single posts, the blog home page and category and tag archives, requested without a query string. They are sent Cache-Control: public, max-age=0, s-maxage=<TTL>. Search results, the 404 page, URLs with a query string, fallback pages and everything WordPress renders itself (logged-in users, previews, password-protected content) are never cached.

With FLX_MODERNIZE_CLOUDFLARE_ZONE_ID and FLX_MODERNIZE_CLOUDFLARE_API_TOKEN (a token that can only purge cache) also defined, the plugin clears your site from Cloudflare’s cache after any change that can show on a page. Your CDN must be set to follow the origin’s Cache-Control header; the documentation at modernize.flexplat.com shows the Cloudflare Cache Rule.

For developers

The flx_modernize_should_render filter lets you turn Flx off for a request (return false). It can never turn Flx on for a logged-in user.

The flx_modernize_head_footer_output filter turns off the head and footer output (return false).

Documentation and a step-by-step tutorial for building a renderer for a theme are at modernize.flexplat.com.

External Services

Flx Modernize works by sending page data to an external Flx Render service over HTTPS and displaying the HTML it returns.

Which service: the one whose URL an administrator enters on the Flx Modernize settings screen. It can be your own self-hosted instance (the renderer package is GPL-licensed open source) or one hosted for you. There is no default: until a Render URL is saved, the plugin sends nothing anywhere and WordPress renders every page normally.
When data is sent: only when an anonymous visitor requests a page that Flx renders (see the lists above). A store using the optional header and footer around Cart, Checkout or My account also sends the site’s shared parts in a background request from the site itself, about every 5 minutes while those pages are visited; nothing about the visitor or those pages’ contents is in it.
What is sent: the content needed to draw that page: title, content, excerpt, slug and permalink; publish and modified dates and author display name; featured image URL, size and alt text; site name, home URL and site language; the header menu’s labels and links; links to the site’s own theme CSS (which the Render service then fetches from your site); for archives and search, the list of posts and paging; for posts, the author’s archive link, the post’s categories and tags, the previous and next posts (title and link), the four latest posts for the theme’s “More posts” list, and the comments section as WordPress renders it for an anonymous visitor (approved comments with their author names, avatars and links, and the empty reply form); for search, the search words and the four latest posts (title, link and date) for the theme’s “More posts” list; the SEO tags, structured data (JSON-LD) and scripts that your plugins print in the page head and footer, captured as an anonymous visitor without cookies (WordPress’s own styles and scripts are left out). The filter flx_modernize_head_footer_output turns this off. The filter flx_modernize_comments_html can change or remove the comments section.
What a WooCommerce store that opted in also sends, for catalogue pages: the page’s middle as WooCommerce prints it (product descriptions, prices, stock, reviews with their authors’ names and avatars, related products and sidebar widgets); each product’s name, link, type, SKU, prices, stock, rating, review count, image and add-to-cart link; the site’s tagline and logo, its menus, its account, cart and privacy links, Storefront’s hook and widget output, and the page’s body classes; and everything WordPress prints in the page head and footer, including styles and scripts, apart from the charset and viewport tags.
What the optional header and footer around Cart, Checkout and My account send: the site’s name, tagline, logo and home URL, its menus, its account, cart and privacy links, the header’s style, the breadcrumb, footer widgets and Storefront’s hook output around the header and footer. No page content or head and footer output.
What is never sent: visitor cookies, IP addresses, user accounts, email addresses, passwords or other query-string values. For a store, nor is the visitor’s cart or customer data. A plugin can still print something on a catalogue page that depends on the visitor, such as a price or currency chosen from their location; that output is part of the page, so check such plugins before opting in.

Cloudflare API (optional). Only when an administrator has defined FLX_MODERNIZE_EDGE_TTL, FLX_MODERNIZE_CLOUDFLARE_ZONE_ID and FLX_MODERNIZE_CLOUDFLARE_API_TOKEN in wp-config.php: after a change that can alter public pages (for example a post published or a menu saved), the plugin asks Cloudflare to clear its cache for the site’s host name. It sends the zone ID, the token (as the Authorization header) and the site’s host name to api.cloudflare.com; nothing about visitors is sent. Without these constants the plugin never contacts Cloudflare. Cloudflare’s terms and privacy policy apply.

The Render service is operated by whoever hosts it: you, or the provider you choose. When the hosting is provided by Flx (Rickey Gu), the terms are agreed with you directly; see modernize.flexplat.com.