facebook-for-woocommerce

Summary Hardens the release automation so that a new release can't be started while a previous one is still in flight, and makes the Set Stable Tag workflow explain why it failed instead of leaving the operator to interpret raw diffs. Note: #3965 (a narrow "fail if an open PR exists for the current stable version" check) was already merged to . This PR replaces that merged step with a broader guard — the current-stable case is just one instance of "any open release PR", so the broader check fully covers it without the extra WordPress.org API call. The review-driven hardening from #3965 is folded into the broader check. Changes — block overlapping releases Removes the narrow step that landed via #3965 (). Adds a broader "Ensure previous release PR is merged" step (runs right after the branch-exists check, so it fails fast before any work is done). Lists open PRs targeting and fails if any previous release PR (head matching , other than the version being prepared) is still open. Each release opens a PR that's merged once published; starting a new release while one is open causes overlapping branches and changelog/version drift. Hardened against silent bypass (carried over from #3965's review): the step runs , fails explicitly if the API call fails, and validates the response is a JSON array before filtering — so a failed/garbled lookup can no longer make the guard pass with a false ✅. — clearer, actionable errors When the WordPress.org marketplace build doesn't match the release build, the workflow now detects which version WP.org is actually serving and, if it isn't this release, explains the most common root cause — the Release Plugin deploy hasn't published yet (often still pending Deployment-environment approval) — with step-by-step remediation instead of just a list of differing files. The "Validate SVN tag" step now gives an actionable message when is missing (the deploy hasn't run), refactors the version into an var, and logs a ✅ on success. Test plan [ ] Run Prepare New Release while a previous PR is open → fails listing the unmerged PR(s). [ ] Run with no open release PRs → logs ✅ and proceeds. [ ] Simulate a failure → step errors out instead of falsely passing. [ ] Run Set Stable Tag before the Release Plugin deploy has published → fails with the "WP.org still serving vX" guidance. [ ] Run Set Stable Tag with a missing SVN tag → fails with the actionable SVN-tag message.

Description Adds detection for whether a Pixel event is being fired from a cached page, and prevents stale event IDs from causing false deduplication across visitors on cached pages. When a caching plugin (WP Super Cache, WP Rocket, LiteSpeed, nginx fastcgi_cache, etc.) serves a cached page, the PHP backend does not execute, so CAPI events are not fired and fbc/fbp cookies are not set server-side. Additionally, event IDs baked into the cached HTML are shared across all visitors, causing Meta to incorrectly deduplicate distinct user events. Changes 1. Cache detection via agent string flag The server renders when the page is generated. When Pixel JS fires, it compares this timestamp against . If the page is older than 30 minutes, the agent string is modified from to (inserting after the WooCommerce version). This flag flows to Meta via both and . 2. Event ID stripping on cached pages On fresh pages ( 30 min old), JS strips the from calls to prevent the same stale ID from being reused across different visitors. This applies to both inline events (via ) and externally queued events (via ). Server-side CAPI event ID generation is unchanged — it only runs on fresh (uncached) requests anyway. Why 30 minutes? Most caching plugins use TTLs from 2 minutes to 7 days. A 30-minute threshold avoids false positives from slow page loads or tabs left open briefly, while catching any meaningfully cached page. Type of change Add (non-breaking change which adds functionality) Fix (non-breaking change which fixes an issue) Checklist [x] I have commented my code, particularly in hard-to-understand areas, if any. [x] I have confirmed that my changes do not introduce any new PHPCS warnings or errors. [x] I have checked plugin debug logs that my changes do not introduce any new PHP warnings or FATAL errors. [x] I followed general Pull Request best practices. [x] I have added tests (if necessary) and all the new and existing unit tests pass locally with my changes. [x] I have completed dogfooding and QA testing, or I have conducted thorough due diligence to ensure that it does not break existing functionality. [x] I have updated or requested update to plugin documentations (if necessary). Changelog entry Add cache detection flag () to Pixel agent string and strip stale event IDs on cached pages to prevent false deduplication. Test Plan 1. Fresh page — agent string has no , event ID is present 1. Disable any caching plugin or clear the cache. 2. Visit a product page. 3. Open browser DevTools > Network tab, filter by . 4. Inspect the Pixel request. 5. Expected: Agent string is (no ), and parameter is present. 2. Cached page — agent string has , event ID is absent 1. Enable a caching plugin (e.g., WP Super Cache, LiteSpeed Cache). 2. Visit a product page to trigger cache generation. 3. Wait 30+ minutes, or simulate by running in DevTools console: 4. Trigger an event (e.g., reload page for PageView, or add to cart). 5. Inspect the Pixel request in Network tab. 6. Expected: Agent string is , and parameter is absent. 3. Agent string format with server flags 1. If the site has option set (e.g., ), verify the format is on cached pages. 4. Verify uses the dynamic agent 1. View page source and find the call. 2. Confirm the agent is computed via an inline function (not a static string). 3. Expected: The third argument to contains . 5. Verify isolated execution path (pixel-events.js) 1. Enable the isolated pixel execution rollout switch. 2. Visit a product page on a fresh (uncached) load. 3. Expected: Events fire with in the fbq call. 4. Simulate cached page via console: 5. Trigger another event. 6. Expected: Event fires without . 6. CAPI events unaffected 1. On a fresh page, verify that CAPI events still include (check plugin debug logs). 2. Expected: Server-side event ID generation is unchanged.

Description This PR fixes a fatal error that can occur when validating variation sync eligibility after the parent variable product has already been removed (for example during trash/delete cascades, including WPML-related flows). Summary of changes Updated to explicitly treat missing/non-resolvable variation parent products as invalid for sync checks. Added a defensive parent type check before reading parent sync metadata. Preserved existing behavior for valid variation-parent relationships. Added integration coverage in for: orphan variation sync-field validation not fatalling, orphan variation being treated as not sync-enabled. Type of change Fix (non-breaking change which fixes an issue) Checklist [X] I have commented my code, particularly in hard-to-understand areas, if any. [X] I have confirmed that my changes do not introduce any new PHPCS warnings or errors. [X] I have checked plugin debug logs that my changes do not introduce any new PHP warnings or FATAL errors. [X] I followed general Pull Request best practices. Meta employees to follow this wiki). [X] I have added tests (if necessary) and all the new and existing unit tests pass locally with my changes. [X] I have completed dogfooding and QA testing, or I have conducted thorough due diligence to ensure that it does not break existing functionality. [ ] I have updated or requested update to plugin documentations (if necessary). Meta employees to follow this wiki). Changelog entry Prevent fatal error when validating orphaned product variations during trash/delete sync flows. Test Plan 1. Enable product sync. 2. Create a variable product with at least one variation. 3. Permanently delete the parent variable product. 4. Trigger product sync validation path for the remaining variation (or run the relevant integration tests). 5. Confirm: no PHP fatal occurs, variation is treated as non-syncable.