Native WordPress delivery

Native mode serves the public site directly from WordPress with the Superfunky block theme. It does not require a separate React deployment, static host, GraphQL round trip for the initial page, build webhook, or SSG publishing step.

Use native mode for a conventional WordPress or WooCommerce launch, a backend-first development site, or a temporary public site while the separate storefront is being prepared. The same installation can later move to dynamic SPA delivery or static-first SSG delivery.

Enable native mode

In Appearance > FunkyCommerce > Rendering mode:

1. turn Headless mode off;
2. save the Control Center;
3. open Settings > Permalinks and save once if public routes do not resolve;
4. visit the WordPress site URL in a private browser window;
5. verify the homepage, one page, one post, search, archives, and the custom 404;
6. if WooCommerce is active, verify shop, product, cart, checkout, and account routes.

When native mode is active, WordPress owns public routing and output. Headless build webhooks and artifact invalidation are not the publishing path: normal WordPress publish and update actions make content available through the WordPress page cache and CDN policy.

Do not enable Redirect public backend requests to the frontend while WordPress is the intended public site. Keep the WordPress Site Address and WordPress Address correct for the domain that serves native mode.

Native templates

The theme includes native block templates for:

• the front page and posts index;
• normal pages and singular posts;
• author and other archives;
• search results;
• community posts;
• not-found routes.

The header and footer are native template parts. WooCommerce owns its normal product, shop, cart, checkout, account, session, payment, and order behavior when the plugin is active. A published 404 page, or the compatible 4o4 alias, supplies editable native not-found content.

The native theme has its own compiled CSS and JavaScript. It does not download or execute the React storefront bundle to render ordinary pages.

Settings that are shared or mirrored

Native and headless modes read the same WordPress content and many of the same Control Center values, but they are different renderers. Confirm each important presentation choice in native acceptance rather than assuming pixel-identical output.

Source	Native behavior
WordPress pages, posts, media, authors, taxonomies, and comments	Rendered directly through WordPress templates and queries
WooCommerce products, prices, stock, taxes, shipping, payments, accounts, and orders	Rendered and processed by WooCommerce and the configured gateway plugins
Gutenberg blocks, theme.json, global styles, presets, and Additional CSS	Applied through the block theme and native WordPress style pipeline
Branding and visual tokens	The native styles share the theme's brand variables, fonts, radius, colour, and content-width foundations
Loading and footer Spotify controls	Mirrored into the native shell runtime when configured
UI string overrides and active language	Used by supported native shell labels and localized renderers
Custom 404 content	Resolved from the same published 404 page and linked translation

Some controls are specific to the React storefront, a build provider, or artifact delivery. Layout Studio session preferences, SPA activation, SSG hydration, deploy badges, and static discovery generation do not become native WordPress features merely because their values exist in the Control Center.

Menus

Assign classic WordPress menus under Appearance > Menus > Manage Locations:

• Header Menu supplies primary navigation;
• Mobile Menu supplies the mobile navigation contract used by supported surfaces;
• Footer Menu uses top-level items as columns and child items as links.

The native block header uses WordPress navigation behavior and can promote the assigned Header Menu to a Navigation block on first render. Review the resulting header in the Site Editor before launch. Footer template content remains editable as blocks, so check footer columns separately instead of assuming every classic footer-menu change rewrites the saved template part.

For multilingual sites, create and assign one menu per location and language. Stable slugs such as header-en, header-pl, footer-en, and footer-pl keep menu resolution predictable across native previews and headless clients.

Shortcodes

Native mode replaces headless data markers with sanitized server-rendered HTML. Supported editor-authored shortcodes include:

• hero and video hero;
• categories, sliders, carousels, grids, tags, product tags, and authors;
• reviews, comments, testimonials, and related sections;
• community feed, hero, marketplace, tag picks, and members;
• Spotify radio, store locations, maps, order success, and unsubscribe forms;
• wishlist, reading list, and authentication components.

WooCommerce handles cart, checkout, and account components through its native shortcodes and endpoints. The paid AI Assistant plugin owns native chat rendering when that companion is active.

Shortcode attributes use the same schema, aliases, normalization, and sanitization contract as headless marker generation, but native mode outputs WordPress/WooCommerce permalinks rather than links to a separate frontend origin.

Test every shortcode used by the site. A shortcode can depend on WooCommerce, a companion plugin, a provider key, published content, or a Pro capability even when the base renderer is present.

Editing and preview

The block editor uses the native theme stylesheet for closer editor/public parity. WordPress Preview requires a signed-in user with permission to edit the object.

Deployment > Mirrored native previews applies the current layout foundations and real header/footer navigation to authorized previews while headless mode is active. It is primarily a headless editorial preview control; native mode should be accepted on its actual public or staging URL.

Caching, SEO, and security

Configure normal WordPress page caching carefully:

• bypass cart, checkout, account, authenticated, preview, and nonce-bearing requests;
• never cache personalized WooCommerce responses publicly;
• purge affected public pages when content, menus, products, or global styles change;
• keep REST, GraphQL, cron, callbacks, media, and administration routes reachable;
• verify the selected SEO plugin's canonical, sitemap, robots, and social metadata output;
• test CSP, HSTS, forced HTTPS, custom login paths, and request filtering on staging.

Native mode avoids an SSG publication delay, but a full-page cache or CDN can still serve an older response until it is purged or expires.

Native acceptance checklist

• Headless mode is off and public backend redirects are off.
• WordPress Site Address, HTTPS, permalinks, and canonical URLs are correct.
• Header, mobile, and footer menus are assigned for every language.
• Front page, blog, page, post, author, archive, search, and 404 templates work.
• All used blocks and shortcodes render without headless placeholders.
• Product, cart, checkout, account, payment, tax, shipping, and email flows pass.
• Branding, fonts, colours, radius, content widths, loader, and footer content are checked.
• Page cache and CDN exclusions protect personalized and transactional routes.
• SEO, feeds, sitemaps, robots, structured data, consent, analytics, and security headers

are accepted on the public response.

• A backup and rollback path are documented before changing the production domain.

Next: prepare DNS, or compare dynamic SPA and static-first SSG.