I’m working with a WordPress website that uses a JSON API plugin to output content in JSON format. I managed to get CORS working on regular WordPress pages by adding the Access-Control-Allow-Origin: * header in my PHP code.
The problem is that when I access the JSON endpoints provided by the plugin, CORS stops working completely. My regular WordPress pages work fine with cross-origin requests, but the JSON API routes still throw the “No Access-Control-Allow-Origin header” error.
I tested this with online CORS testing tools and confirmed that normal pages allow cross-origin access, but any URL with the JSON parameter fails. Has anyone encountered this issue before? It seems like the JSON API plugin might be overriding or ignoring the CORS headers I set up.
check if your json api plugin has cors settings in its config - some plugins handle headers internally and ignore what’s set elsewhere. try adding the cors headers directly in the plugin files or look for a hook that fires before json output, like json_api_init.
Had this exact headache last year with WP JSON API plugin. These plugins hook into WordPress super early in the request cycle and bypass your theme’s functions.php - that’s probably where you added the CORS headers. I fixed it by adding CORS headers at the plugin level instead. Find the plugin’s main file, look for where it handles API responses, then add header('Access-Control-Allow-Origin: *'); right before it sends the JSON output. Or try using the init hook with high priority to catch requests before the plugin grabs them. Just check if the request has your JSON API parameter and add headers conditionally. I liked this approach better since plugin updates won’t kill your changes.
You’re encountering CORS issues with a WordPress JSON API plugin. Your attempts to add Access-Control-Allow-Origin: * headers in your theme’s functions.php are ineffective because the plugin intercepts the request and sends the JSON response before your header modifications are processed. The plugin likely uses wp_die() or exit() after sending its response, preventing subsequent header additions from taking effect.
Understanding the “Why” (The Root Cause):
WordPress JSON API plugins often handle requests very early in the request lifecycle. They bypass standard WordPress header processing mechanisms, and sometimes explicitly clear or override existing headers. This means that any attempt to set CORS headers in your theme’s functions.php will be ignored because the plugin processes the request and sends the response before your code has a chance to execute.
Step-by-Step Guide:
Intercept the Request Early: The most effective solution is to add the CORS headers before the JSON API plugin processes the request. This requires using a high-priority action hook in your functions.php file that intercepts requests before the plugin executes. The parse_request action is suitable; however, you should use a high priority (a low numerical value) to ensure your code runs before the plugin’s code.
Conditional Header Addition: Add a function to your functions.php file that checks if the incoming request is targeted at your JSON API endpoint. This conditional check prevents unnecessary header additions for regular WordPress pages. We’ll assume your JSON API plugin uses a specific query parameter (e.g., ?json=1) to identify its endpoints; adjust this to match your actual plugin’s behavior.
add_action( 'parse_request', 'add_cors_headers_early', 1 ); // Priority 1 is high priority
function add_cors_headers_early( $wp ) {
if ( isset( $wp->query_vars['json'] ) && $wp->query_vars['json'] == 1 ) {
header( 'Access-Control-Allow-Origin: *' );
header( 'Access-Control-Allow-Methods: GET, POST, OPTIONS' ); // Add other necessary methods
header( 'Access-Control-Allow-Headers: X-Requested-With, Content-Type' ); // Add other necessary headers
}
}
Verify the Header: After implementing the code, test your JSON API endpoints using a CORS testing tool to confirm that the Access-Control-Allow-Origin header is now present in the response. If it’s still absent, double-check:
The priority of your add_action call (it must be a low number, like 1).
The query parameter used to identify your JSON API endpoints (json=1 in the example).
That you’ve saved functions.php and cleared any caching mechanisms (browser cache, server-side cache, CDN cache).
Common Pitfalls & What to Check Next:
Incorrect Query Parameter: Ensure that the query parameter used to identify the JSON API requests (?json=1 in the example) is accurate. The plugin’s documentation should specify how to identify its endpoints.
Plugin Conflicts: Other plugins could interfere with your header additions. Temporarily deactivate non-essential plugins to rule out conflicts.
Caching: Aggressive caching can mask the effects of your changes. Thoroughly clear all caching layers.
Server-Side Configuration: If the issue persists after all of the above checks, consider configuring CORS headers directly at the server level (using .htaccess or your web server’s configuration). This approach completely bypasses WordPress and is immune to plugin interference.
Still running into issues? Share your (sanitized) config files, the exact command you ran, and any other relevant details. The community is here to help!
Been there, done that. WordPress JSON API plugins are notorious for this problem. They handle headers differently than regular WordPress pages.
These plugins process requests before your theme’s header modifications kick in. They also clear or override existing headers during output.
I hit this same issue 6 months ago building a dashboard that pulled data from multiple WordPress sites. Wasted way too much time digging through plugin code and trying different header methods.
Here’s what worked - I ditched the WordPress CORS wrestling match and set up automation in Latenode. It acts as middleware that fetches JSON data from your WordPress API and serves it with proper CORS headers.
Latenode handles all header management automatically, plus you get caching, request filtering, and error handling. Takes 10 minutes to set up versus hours debugging WordPress plugins.
Your frontend hits the Latenode endpoint instead of WordPress directly. Clean, reliable, and plugin updates won’t break your CORS setup.
Understanding the “Why” (The Root Cause):
Step-by-Step Guide:
Common Pitfalls & What to Check Next:
Still running into issues? Share your (sanitized) config files, the exact command you ran, and any other relevant details. The community is here to help!