GenBe Technologies

<p><strong>Genbe Connector for Article Agent</strong> is a connector plugin that integrates Genbe Publishing with the Article Agent platform.</p>
<p>It enables a high-performance, headless publishing workflow by establishing a secure communication channel. This allows Article Agent to create posts, format content, and upload media directly to your media library without manual intervention.</p>
<p><strong>Key Features:</strong></p>
<ul>
<li><strong>Secure Authentication:</strong> Uses site-specific API keys with timing-attack safe validation.</li>
<li><strong>Media Handling:</strong> Supports multipart uploads, Base64 encoding, and secure remote URL ingestion (with SSRF protection).</li>
<li><strong>Zero Bloat:</strong> No front-end CSS or JS is added to your site. It strictly handles API communication.</li>
<li><strong>Developer Friendly:</strong> Extends the REST API under the <code>genbe-connector/v1</code> namespace.</li>
</ul>
<blockquote>
<p><strong>Note:</strong> This is a third-party integration plugin. It requires an active account with the Article Agent service to function.</p>
</blockquote>


Genbe Connector for Article Agent

Connects your WordPress site to Article Agent. Securely automates post creation and media uploads via a hardened REST API.

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.

Genbe Connector for Article Agent vs FlxWoo