rickey29

<p>FlxWoo is a WooCommerce infrastructure plugin. It adds a REST API layer, server-side checkout rendering, and Stripe Checkout integration on top of standard WooCommerce — without replacing WooCommerce’s core order, payment, or inventory systems.</p>
<p>It is designed for agencies and developers who need full control over checkout presentation while continuing to rely on WooCommerce for order management, tax calculation, coupon handling, and payment record-keeping.</p>
<h4>What FlxWoo Is</h4>
<ul>
<li>A REST API layer for WooCommerce checkout state (namespace: <code>flxwoo/v1</code>)</li>
<li>A server-side rendering layer for checkout and product page templates</li>
<li>A Stripe Checkout integration with server-side session management and webhook handling</li>
<li>A fallback-safe product page rendering layer: falls back to native WordPress/WooCommerce templates when the Render service is unavailable or the product type is not supported</li>
<li>An admin dashboard for operational monitoring: Overview, Settings, and System Status pages</li>
<li>An infrastructure layer that extends WooCommerce without replacing it</li>
</ul>
<h4>What FlxWoo Is Not</h4>
<ul>
<li>Not a WooCommerce fork or replacement</li>
<li>Not a page builder or visual checkout designer</li>
<li>Not a payment processor — payment remains in WooCommerce and Stripe</li>
<li>Not a headless CMS</li>
<li>Not a replacement for WooCommerce’s admin, order management, or product system</li>
</ul>
<h4>Who FlxWoo Is For</h4>
<ul>
<li>Agencies building custom checkout experiences on WooCommerce</li>
<li>Developers who need REST access to WooCommerce checkout state</li>
<li>Projects requiring server-side rendered checkout templates</li>
<li>Teams integrating Stripe Checkout while keeping WooCommerce as the order system</li>
</ul>
<h4>Architecture</h4>
<p>FlxWoo registers a REST namespace (<code>flxwoo/v1</code>). Checkout state endpoints (cart, order, coupon, customer) return JSON. Render endpoints (<code>/render/checkout</code>, <code>/render/thank-you</code>) return server-side rendered HTML. Product pages are intercepted at the template layer and rendered through the external Render service, with automatic fallback to native WordPress/WooCommerce templates if the service is unavailable or the product type is not supported.</p>
<p>WooCommerce remains authoritative for all order, cart, tax, and payment data. FlxWoo reads and writes through WooCommerce’s standard APIs without modifying its data structures or core behavior.</p>
<h4>Features</h4>
<ul>
<li>REST API under the <code>flxwoo/v1</code> namespace</li>
<li>Cart and checkout state endpoints returning JSON</li>
<li>Stripe Checkout integration — server-side session creation and webhook handling</li>
<li>Duplicate order prevention at the checkout session level</li>
<li>Concurrent submission guard</li>
<li>Session-independent Stripe return flow (order identity carried via URL, not session state)</li>
<li>Server-side HTML rendering for checkout and thank-you templates</li>
<li>Product page rendering via external Render service, with automatic fallback to native WordPress/WooCommerce templates</li>
<li>Product type gate: only simple products (including virtual) are routed to the Render service; variable, external, and unrecognized types use native templates</li>
<li>Structured logging for checkout and payment events</li>
<li>Operational event store tracking webhook failures, Stripe connectivity issues, and auth denials</li>
<li>Health endpoint at <code>GET /wp-json/flxwoo/v1/health</code> for uptime monitoring</li>
<li>Admin Overview page with operational health summary and last-payment/last-webhook signals</li>
<li>System Status page with diagnostics across environment, Stripe, cache, webhooks, checkout failures, and database</li>
<li>Automated data retention: scheduled cleanup for idempotency records, Stripe events, checkout sessions, and operational events with defined retention windows</li>
<li>Preserve-by-default uninstall policy: data is retained unless explicitly opted out in Settings</li>
</ul>
<h3>Cache and CDN Configuration</h3>
<p>FlxWoo endpoints are session-sensitive and stateful. They must not be served from a cache layer under any circumstances.</p>
<h4>Why This Matters</h4>
<p>FlxWoo checkout endpoints read and write live session, cart, and payment state on every request. If a caching layer returns a stale or shared response, the result is incorrect behavior — not a gracefully degraded experience. Common symptoms include stale cart totals, duplicate checkout attempts, broken Stripe sessions, and session data surfacing to the wrong customer.</p>
<p>Any FlxWoo endpoint returning a cache <code>HIT</code> response header is a production defect.</p>
<h4>What Must Bypass Cache</h4>
<p>Three route groups must bypass cache at every layer — page cache, CDN, reverse proxy, and any optimization plugin that operates on HTTP responses:</p>
<ul>
<li><code>/wp-json/flxwoo/*</code> — all FlxWoo REST API endpoints (cart, checkout, payment, webhook, health)</li>
<li><code>/checkout*</code> — the WordPress checkout page and all trailing-slash or query-string variants</li>
<li><code>/thank-you*</code> — the order confirmation page and all variants</li>
</ul>
<p>FlxWoo emits <code>Cache-Control: no-store</code> headers via PHP on both the REST API and the HTML pages. However, CDN-level rules such as Cloudflare’s “Cache Everything” can override PHP headers at the edge before they reach the browser. PHP-level headers alone are not sufficient — explicit CDN bypass rules targeting these paths are required.</p>
<h4>Common Systems That Require Configuration</h4>
<p><strong>WP Rocket</strong> — Add <code>/wp-json/flxwoo/</code>, <code>/checkout</code>, and <code>/thank-you</code> to “Never Cache URL(s)” in the Cache settings tab. WP Rocket uses substring prefix matching, so these entries cover <code>/checkout*</code> and <code>/thank-you*</code> including trailing-slash and query-string variants.</p>
<p><strong>LiteSpeed Cache</strong> — Add <code>/wp-json/flxwoo/</code>, <code>/checkout</code>, and <code>/thank-you</code> to the “Do Not Cache URIs” list under Cache > Excludes. LiteSpeed URI exclusions also use prefix matching, covering <code>/checkout*</code> and <code>/thank-you*</code>.</p>
<p><strong>Cloudflare</strong> — Use Cache Rules to bypass cache for paths matching <code>/checkout*</code>, <code>/thank-you*</code>, and <code>/wp-json/flxwoo/*</code>. If using Automatic Platform Optimization (APO), verify that checkout and thank-you URLs are in the APO exclusion list. Cloudflare’s “Cache Everything” page rule must not apply to these paths.</p>
<p><strong>Nginx / FastCGI</strong> — Add <code>fastcgi_cache_bypass</code> map entries for <code>/wp-json/flxwoo/</code>, <code>/checkout*</code>, and <code>/thank-you*</code> at the server or location block level.</p>
<p><strong>Varnish</strong> — Add pass conditions in <code>vcl_recv</code> for <code>/wp-json/flxwoo/*</code>, <code>/checkout*</code>, and <code>/thank-you*</code>.</p>
<p><strong>Aggressive optimization plugins</strong> — Verify that no plugin is buffering, combining, or caching REST API responses or HTML responses for FlxWoo routes or page wrappers.</p>
<h4>What Is Safe to Cache</h4>
<p>Static assets (CSS, JS, images), non-dynamic pages, and REST endpoints that explicitly return <code>Cache-Control: public</code>. FlxWoo’s own endpoints never set public cache headers.</p>
<h4>Full Configuration Reference</h4>
<p>Detailed per-system instructions, verification commands, and symptom diagnostics are in <code>docs/cache-configuration.md</code>.</p>
<h3>Requirements</h3>
<ul>
<li>WordPress 6.0 or later</li>
<li>PHP 8.0 or later</li>
<li>WooCommerce (active; declared as a required plugin)</li>
<li>Stripe account with Checkout enabled (for payment features)</li>
<li>MySQL 5.7+ or MariaDB 10.3+</li>
</ul>
<h3>Operational Notes</h3>
<ul>
<li><strong>Health endpoint:</strong> <code>GET /wp-json/flxwoo/v1/health</code> always returns HTTP 200 when the plugin is active. Suitable for uptime monitoring and deployment verification.</li>
<li><strong>Logging:</strong> Structured logging for checkout and payment events. Useful for incident response and debugging in production environments.</li>
<li><strong>Database setup:</strong> Required tables are created automatically on activation. Schema migrations run silently on upgrade — no manual steps required.</li>
<li><strong>Data on uninstall:</strong> Data is preserved by default when the plugin is deleted. To remove all FlxWoo data, enable <strong>Delete all data on uninstall</strong> in FlxWoo Settings > Data before deleting the plugin.</li>
<li><strong>Idempotency:</strong> Checkout idempotency is database-backed, making the system safe for concurrent requests and browser retries.</li>
<li><strong>Stripe return flow:</strong> Order identity is carried via URL parameters after Stripe redirect, not session state. This makes the return path resilient to session loss between payment and confirmation.</li>
</ul>
<h3>Security</h3>
<ul>
<li>All REST endpoints enforce WordPress capability checks before processing requests.</li>
<li>Input is validated and sanitized at the API boundary and within the service layer.</li>
<li>All PHP files include an ABSPATH guard to prevent direct execution.</li>
<li>Database queries use prepared statements throughout.</li>
<li>PHP CodeSniffer with WordPress Coding Standards and security sniffs is enforced as a release gate.</li>
</ul>
<h3>Limitations</h3>
<ul>
<li>Requires WooCommerce to be active. FlxWoo will not initialize without it.</li>
<li>Stripe integration requires an active Stripe account with Checkout enabled.</li>
<li>Server-side rendering requires a live PHP execution environment. Fully static deployments are not supported.</li>
<li>All FlxWoo REST endpoints must not be behind a full-page or CDN cache layer.</li>
<li>Product page rendering via the Render service is currently limited to simple products (including virtual). Variable, external, and other product types fall back to native WordPress/WooCommerce templates.</li>
</ul>


FlxWoo

WooCommerce infrastructure plugin providing a REST API, Stripe Checkout integration, and server-side rendering for headless checkout workflows.

Jason Bahl

<p>WPGraphQL for Advanced Custom Fields is a free, open-source WordPress plugin that adds ACF Fields and Field Groups to the WPGraphQL Schema.</p>
<h4>Create ACF Field Groups</h4>
<p>Create ACF Field Groups and Fields using the ACF User Interface, register them with PHP, or leverage ACF local JSON. Each field group and the fields within it can be configured to “Show in GraphQL.”</p>
<h4>Query your fields with GraphQL</h4>
<p>Once your field groups and fields are configured to “Show in GraphQL,” they become available in the GraphQL Schema for querying.</p>
<h4>Supported Field Types</h4>
<p>WPGraphQL for ACF provides support for most built-in field types of ACF (free & PRO) and extends support to most field types from ACF Extended (free & PRO).</p>
<h3>Updating</h3>
<p>If you are updating from WPGraphQL for ACF v0.6.* or older, check out the <a href="https://acf.wpgraphql.com/upgrade-guide" rel="nofollow ugc">Upgrade Guide</a></p>
<p>For non-major version updates, automatic updates usually should work smoothly, but we still recommend you back up your site and test on a staging site.</p>
<p>Before updating WPGraphQL for ACF, review the release notes on <a href="https://github.com/wp-graphql/wpgraphql-acf/releases" rel="nofollow ugc">GitHub</a>.</p>
<p>We follow Semantic Versioning (Semver) for meaningful releases:</p>
<ul>
<li><em>MAJOR</em> version for incompatible API changes,</li>
<li><em>MINOR</em> version for backwards-compatible functionality additions,</li>
<li><em>PATCH</em> version for backwards-compatible bug fixes.</li>
</ul>
<p>Learn more about Semver at <a href="https://semver.org" rel="nofollow ugc">semver.org</a>.</p>
<h3>Support</h3>
<ul>
<li><a href="https://github.com/wp-graphql/wp-graphql/discussions" rel="nofollow ugc">General Help Requests</a>: For general questions and help requests, create a new topic in Github Discussions</li>
<li><a href="https://www.wpgraphql.com/discord" rel="nofollow ugc">Discord Community</a>: The WPGraphQL Discord is a great place to communicate in real-time. Ask questions, discuss features, get to know other folks using WPGraphQL.</li>
<li><a href="https://github.com/wp-graphql/wp-graphql/issues/new?assignees=&labels=&projects=&template=bug_report.yml" rel="nofollow ugc">Bug Reports</a>: Report a bug in WPGraphQL</li>
<li><a href="https://github.com/wp-graphql/wp-graphql/issues/new?assignees=&labels=&projects=&template=feature_request.yml" rel="nofollow ugc">Feature Requests</a>: Suggest an idea, feature, or enhancement for WPGraphQL.</li>
<li><a href="https://github.com/wp-graphql/wp-graphql/security/advisories/new" rel="nofollow ugc">Report a Security Vulnerability</a>: Report a security vulnerability.</li>
</ul>
<h3>FAQs</h3>
<p><strong>Does this work with ACF Extended?</strong></p>
<p>Yes! WPGraphQL for ACF allows you to query for (most) fields created with ACF Extended.</p>
<p><strong>Can I filter and sort queries by ACF Fields using WPGraphQL for ACF?</strong></p>
<p>At this time WPGraphQL for ACF does not support filtering or sorting queries by ACF Fields. “Meta Queries” are often very expensive to execute, so we currently do not support filtering by ACF fields out of the box, but are exploring options for supporting it without the performance penalty.</p>
<p><strong>I think I found a bug, where do I report it?</strong></p>
<p>If you think you found a bug, please open an issue on <a href="https://github.com/wp-graphql/wpgraphql-acf" rel="nofollow ugc">GitHub</a>. The more details you provide in the issue, and the more clear your steps to reproduce are, the higher chances we will be able to help.</p>
<p><strong>Can I use ACF Free or Pro with WPGraphQL for ACF?</strong></p>
<p>Yes! WPGraphQL for ACF works great with ACF Free and Pro. The Pro version of ACF has some additional features, such as Flexible Content Fields, Repeater Fields and Options Pages that are supported by WPGraphQL for ACF.</p>
<p><strong>Do I have to use Faust.js to use WPGraphQL for ACF?</strong></p>
<p>No! While <a href="https://www.wpgraphql.com" rel="nofollow ugc">wpgraphql.com</a> and <a href="https://acf.wpgraphql.com" rel="nofollow ugc">acf.wpgraphql.com</a> are built using <a href="https://faustjs.org/" rel="nofollow ugc">Faust.js</a> and Next.js, you can use WPGraphQL for ACF with any GraphQL client, including Apollo, Relay, Urql, etc.</p>
<p><strong>I have an ACF Extension that adds a new field type, will it work with WPGraphQL for ACF?</strong></p>
<p>WPGraphQL for ACF supports the field types that come with ACF (Free and PRO) as well as the field types in ACF Extended (Free and PRO). Support for additional field types can be added by using the “register_graphql_acf_field_type” API.</p>
<p><strong>Do I need WPGraphQL and ACF to be active to use this?</strong></p>
<p>This plugin is a “bridge” plugin that brings functionality of ACF to WPGraphQL. Both WPGraphQL and ACF need to be installed and active in your WordPress installation for this plugin to work.</p>
<p><strong>How much does WPGraphQL for ACF cost?</strong></p>
<p>WPGraphQL for ACF is a FREE open-source plugin. The development is sponsored by <a href="https://wpengine.com/atlas" rel="nofollow ugc">WP Engine Atlas</a>.</p>
<p><strong>Does WPGraphQL for ACF support GraphQL Mutations?</strong></p>
<p>GraphQL Mutations are not yet supported. We are working on adding support for Mutations in the future. We are waiting for the GraphQL “@oneOf” directive to be merged into the GraphQL spec before we add support for Mutations.</p>
<p><strong>Does this work with Field Groups registered in PHP or JSON?</strong></p>
<p>Yes! You can register ACF Field Groups and Fields using the Admin UI, PHP or JSON. WPGraphQL for ACF will detect the Field Groups and Fields and add them to the GraphQL Schema. If using PHP or JSON, you will need to set the “show_in_graphql” setting to “true” to expose the Field Group and Fields to the GraphQL Schema. There might be other settings that need attention at the field group or field level that might impact the schema or field resolution.</p>
<h3>Privacy Policy</h3>
<p>WPGraphQL for Advanced Custom Fields uses <a href="https://appsero.com" rel="nofollow ugc">Appsero</a> SDK to collect telemetry data upon user confirmation, helping us troubleshoot problems and improve the product.</p>
<p>The Appsero SDK <strong>doesn’t collect data by default</strong> and only starts gathering basic telemetry data when a user allows it via the admin notice. No data is collected without user consent.</p>
<p>When you opt in, each telemetry request is sent to Appsero and a duplicate is sent in a non-blocking request to WPGraphQL-operated infrastructure at https://telemetry.wpgraphql.com (the same categories of data as described for Appsero below).</p>
<p>Learn more about how <a href="https://appsero.com/privacy-policy/" rel="nofollow ugc">Appsero collects and uses data</a>.</p>


WPGraphQL for ACF

WPGraphQL for ACF seamlessly integrates Advanced Custom Fields with WPGraphQL.

FlxWoo vs WPGraphQL for ACF