facebook-for-woocommerce

Description Removes the retired WooCommerce-hosted OAuth and token-exchange path that is no longer used by the current embedded onboarding and reconnect flows. This change: removes the legacy callback, token-exchange handler, URL and parameter builders, related constants, exception, and duplicate exception tests; removes the obsolete connection-failure retry notice; sends the Product Sync disconnected CTA to the plugin settings page; keeps the current embedded onboarding, app-store login, REST extras, webhook, and disconnect paths unchanged. This supersedes #4011 and #4012. Compatibility note This is a breaking developer-facing cleanup. The removed methods and filters have no callers in this repository, but third-party extensions may call them. Removed methods: , , , , , , , , and . Removed filters: , , , , , and . Type of change Break (change that can affect existing public API consumers) 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. [ ] I have checked plugin debug logs for new PHP warnings or fatal errors. [x] I followed general pull request best practices. [x] I have updated focused tests and all PHP and JavaScript unit tests pass locally. [x] I conducted repository-wide due diligence to ensure that this does not break existing plugin functionality. [x] Documentation changes are not required beyond the compatibility note above. Changelog entry Remove the retired WooCommerce-hosted connection bridge. Test Plan Completed locally [x] PHP unit suite on PHP 8.2, WordPress 7.1, and WooCommerce 11.0.1 — 1,995 tests and 143,294 assertions passed. [x] — 104 tests passed. [x] PHPCS on every modified production file — 0 errors and 0 warnings. [x] on every changed PHP file. [x] . [x] Repository-wide searches found no remaining references to the removed methods, class, callback, transient, or filters. cannot process deleted files and exits with ; PHPCS was therefore run directly on every modified production file. Manual verification Manual dogfooding remains to be completed: 1. Install the PR build on a non-production WooCommerce site. 2. Complete the standard embedded onboarding flow and confirm the connection succeeds and settings persist. 3. Invalidate the stored token and confirm reconnect routes through the current settings/onboarding flow. 4. Visit Product Sync while disconnected and confirm the CTA opens plugin settings rather than a WooCommerce-hosted OAuth URL. 5. Confirm the plugin debug log contains no new warnings or fatal errors. Screenshots Not applicable; this removes an obsolete notice and retargets an existing link.

🔎 Isolate the bug [ ] I have confirmed this occurs in the most recent version of WordPress, WooCommerce, and Meta for WooCommerce. [ ] I have confirmed this occurs when only WooCommerce and Meta for WooCommerce are active and when using a default WordPress or WooCommerce theme. This was observed and corrected on a production store running WordPress 7.0.4, WooCommerce 11.0.0, and Meta for WooCommerce 3.7.6. I have not reproduced it on a minimal installation, but the stale recurrence is directly visible in Action Scheduler and follows from the scheduling logic described below. ✍️ Describe the bug Meta for WooCommerce 3.7.6 defines the promotions feed generation interval as two hours: However, an existing recurring Action Scheduler record retained its older 3,600-second interval after the plugin was upgraded. only creates the recurring action when none exists: It does not compare the existing action's recurrence with . Consequently, stores upgrading from a version that scheduled this feed hourly can continue regenerating it hourly indefinitely, even though the installed code expects a two-hour cadence. On a store with a large coupon catalog, each hourly launch produced approximately 149 actions. WordPress then made repeated loopback requests to: Many queue-runner callbacks took several seconds, one exceeded twenty seconds, and the bursts correlated with origin-health latency alerts. There was no PHP-FPM worker-limit event during the examined incident. This appears related to the Action Scheduler volume and loopback behavior reported in #3874, but the specific defect here is that an existing recurring schedule is not migrated when the plugin's intended interval changes. 🚶‍♀️ Steps to reproduce 1. Install a Meta for WooCommerce version that creates with a 3,600-second recurring interval, or create an equivalent recurring Action Scheduler action. 2. Upgrade to Meta for WooCommerce 3.7.6, where returns . 3. Allow the plugin and Action Scheduler to initialize normally. 4. Inspect the pending recurring action using Action Scheduler or the table. 5. Observe that its serialized recurrence remains 3,600 seconds rather than changing to 7,200 seconds. 6. Allow the schedule to run and observe that promotions-feed generation still launches hourly. As a production correction, I canceled only the stale recurring action and recreated it in the same group with the same next-run timestamp and a 7,200-second interval. Readback confirmed the old action was canceled, the replacement was pending with the correct recurrence, and catalog synchronization remained enabled. ✔️ Expected behavior When the plugin's intended feed-generation interval changes, existing recurring actions should be migrated to the current interval without requiring administrators to discover and replace stale Action Scheduler records manually. A narrow fix could inspect the existing recurring action's schedule during plugin upgrade or feed initialization. If its recurrence differs from , replace only that recurring action while preserving the next-run timestamp, arguments, and group. 🗃 Logs Sanitized Action Scheduler evidence Environment: Before correction: Observed workload from one launch: After replacing only the stale recurring action: No credentials, customer data, request addresses, or private infrastructure details are included. Related reports: #3874 https://wordpress.org/support/topic/performance-issue-with-promotions-feed-generator-on-large-woocommerce-store/

🔎 Isolate the bug [X] I have confirmed this occurs in the most recent version of WordPress, WooCommerce, and Meta for WooCommerce. [X] I have confirmed this occurs when only WooCommerce and Meta for WooCommerce are active and when using a default WordPress or WooCommerce theme. ✍️ Describe the bug — the function that builds the feed payload, i.e. a read path — invalidates the store's full-page cache as a side effect, unconditionally, on every call. 3. Pick a product and run the feed preparation twice in a row, changing nothing in between: 4. Both calls log a purge, although the second wrote no meta at all. Without WP Rocket the same effect is visible by hooking directly. ✔️ Expected behavior Building the feed payload should not invalidate the storefront page cache. Concretely, either of these would resolve it: Preferred — drop from this path. on line 822 already satisfies the stated intent ("ensure fresh values are read") without touching any page cache. Otherwise — make it conditional. Collect the return values of and clear only when at least one write actually happened: It would also help integrators if the mapped-attribute write were separated from altogether — a function named "prepare" that persists meta and invalidates caches is surprising, and it is what makes the cost hard to find. 🗃 Logs Environment WordPress: 6.9 WooCommerce: 10.9.4 Meta for WooCommerce: 3.7.6 PHP: 8.4 Page cache: WP Rocket 3.23 + Cloudflare Object cache: Object Cache Pro (Redis) HPOS: enabled Related: #3900 (earlier code-review findings against 3.6.0 — this defect is not among them).