Post-processing and integrations

Add operational integrations only after the backend, storefront, commerce flows, and design have passed acceptance. Each integration introduces an external system, new data flows, or a potentially disruptive security policy.

Guides

1. GTM and GA4 – analytics container injection, consent, events, and

verification.

1. Multilingual stores – Polylang, translated commerce content,

language routes, and community language ownership.

1. Forms and autoresponders – submission inboxes, spam,

notifications, providers, and current runtime boundaries.

1. Sample form with uploads and redirect – customer-facing form flow,

file handling, and graceful post-submit navigation.

1. Push notifications – service worker, VAPID, subscriptions,

delivery integration, and browser testing.

1. Security – safe rollout of Free and Pro hardening across WordPress and

the static storefront.

1. SMTP and email delivery – mail transport, sender authentication, DNS, and

deliverability checks.

Ownership and availability

Area	Superfunky role	External owner
GTM/GA4	Pro build inputs and script injection	Google accounts, consent policy, tag/event design
Languages	Free default plus Pro community controls	Polylang and its GraphQL/WooCommerce bridges
Forms	Core private inboxes and Free protection/routing	Akismet, provider connectors, delivery transport
Push	Pro switch and public VAPID/subscription API; open storefront browser flow	VAPID private key and push sender
Security	WordPress controls and generated storefront headers	Host, proxy, CDN, WAF, backups, monitoring
Email	Pro provider fields and WordPress mail calls	Mailgun/SMTP service, DNS, reputation, bounce handling

Pro fields require the active Pro companion. Provider accounts, paid WordPress plugins, DNS services, and usage charges remain separate.

Before enabling an integration

1. Use staging with the same proxy, domain, and build process as production.
2. Back up WordPress and document a rollback path.
3. Assign an owner for provider access, billing, secrets, logs, and incident response.
4. Define what customer data is transferred and how long it is retained.
5. Configure the integration in one place; avoid duplicate analytics or mail transports.
6. Run an end-to-end test from the public storefront, not only WordPress admin.
7. Record the final working settings without copying secrets into project documentation.

Runtime coverage

The Control Center's Runtime coverage tab distinguishes settings consumed by current theme/runtime code from values stored for a companion or future integration. A saved field is not evidence that a third-party request, email, analytics event, or push message was delivered.

For static or hybrid deployments, settings used during generation require a new storefront build. Runtime WordPress settings take effect on the backend after saving, although caches and proxy configuration may still delay the result.

Next: configure GTM and GA4.