Dashboard labels request-specific failures as core REST API unavailability

Summary

The Revive Social dashboard reports that WordPress core REST API functionality is unavailable when one of its authenticated product-specific startup requests fails. The warning is expected to distinguish a failure of a Revive Social request from unavailability of the general WordPress REST API. Instead, a route-specific, authorization, response, or transient request failure can display the broad core REST warning, directing users toward unrelated security-plugin or hosting troubleshooting and obscuring the failing request.

Customer context

• Product / area: Revive Social dashboard used with the Pro Add-on
• Version: Pro Add-on 3.3.5; free/core plugin version not provided
• Environment: WordPress 7.1, PHP 8.3.21, managed hosting
• Integration / third party: WPML multilingual URL structure; JNews theme
• Reported error / symptom: Dashboard says core REST API functionality is unavailable while the general and language-prefixed REST indexes respond and Site Health reports REST API availability
• Impact: Misleading critical-looking configuration guidance and difficulty identifying the product-specific request that failed

Reproduction notes

1. Load the Revive Social dashboard as an administrator.
2. In a controlled test environment, make one of get_available_services, get_authenticated_services, or get_active_accounts return a rejected/non-2xx response while the general WordPress REST index remains available.
3. Observe that the dashboard displays the message claiming core REST API functionality is unavailable.

The failure path is source-confirmed in tag v9.4.2; no local browser reproduction was run. The customer's exact failing request and response were not provided.

Diagnosis

Conclusion

The warning condition and its message describe different scopes. The dashboard sets the warning for rejection of any Promise-based Revive Social API request, while the rendered text states that WordPress core REST API functionality is unavailable. This directly permits request-specific failures to be reported as general REST unavailability. The reported site demonstrated that its public REST indexes were available, although the exact rejected authenticated response was not captured.

Where this likely occurs

• vue/src/models/rop_store.js — Vuex actions.fetchAJAXPromise() lines 320–354: all HTTP rejection and catch paths commit apiNotAvailable with true without classifying the failure.
• includes/class-rop-i18n.php — Rop_I18n dashboard label construction lines 403–408: api_not_available states that core REST API functionality is unavailable and attributes likely causes to security plugins or server configuration.
• vue/src/rop_main.js — dashboard created() lines 27–31: startup dispatches get_available_services, get_authenticated_services, and get_active_accounts through the shared Promise action.
• includes/admin/class-rop-admin.php — Rop_Admin::enqueue_scripts() lines 307–327: the client receives a product-specific REST route generated from /tweet-old-post/v8/api/ and a WordPress REST nonce.
• Git commit 55c777de introduced the warning mechanism in 2018. The behavior is present in tag v9.4.2; tags containing the introduction begin at v8.0.9. This establishes long-standing behavior, not a verified regression.

Engineering notes

The dashboard implementation belongs to the free/core Codeinwp/tweet-old-post repository; the inspected Pro repository does not contain a competing production dashboard state path. The Pro Add-on version reported by the customer is v3.3.5, but the paired free/core version is unknown. The same client action handles several authenticated product-specific operations, so the warning does not identify which operation or failure class triggered it. WordPress core REST behavior was not inspected from local source; the scope mismatch is established by the plugin's own request target and warning text.

Test coverage status

No relevant coverage was found during inspection for rejected dashboard startup requests or warning classification. tests/e2e/specs/dashboard/general-settings.spec.js lines 6–38 exercises a successful dashboard load and settings interaction but does not simulate a failed Revive Social REST request or assert warning content.

What to verify or explore next

• May be worth reproducing each of the three startup request failures independently while the general /wp-json/ index remains available.
• May be worth recording the status and response body for authorization, route-specific server error, malformed response, and transient network cases.
• If reproducible, checking the Playwright dashboard suite with controlled REST responses would establish the exact visible warning for each failure class.

Unknowns / follow-up

• The customer's exact failed authenticated request, HTTP status, and response body are unavailable.
• The customer's installed free/core Revive Social version is unknown.

Confidence

Confidence: 96/100

Repository inspection confirms two independently testable dashboard defects in the current tagged free-plugin source: request-specific failures are mapped to a core REST API warning, and the shared warning flag is not cleared by later successes. No matching open GitHub issue was found.

---

Source: HelpScout #3447403104
Generated by bug-report-triage (ID: bug-report-triage_6aa31a6d08a988.40680962)