WordPress plugin 1.0.0: proxy drops Content-Type (all events rejected) and inline SDK is always rejected #610

The WordPress plugin (v1.0.0) doesn't track anything on our site, because of two bugs in openpanel.php.

1. Proxy drops the Content-Type header, so every event is rejected

collect_request_headers() only forwards $_SERVER keys starting with HTTP_. PHP stores the Content-Type under CONTENT_TYPE, without that prefix, so the proxy never forwards it. The API then rejects every event:

POST /wp-json/openpanel/track → 400 {"status":400,"error":"Error","message":"body/type Invalid input"}

The same request sent directly to api.openpanel.dev/track returns 200.

Fix in proxy_request():

$content_type = $request->get_header('content_type');
if ($content_type) {
    $incoming['Content-Type'] = $content_type;
}

2. The inline op1.js always fails validation, so the plugin falls back to the CDN script, which ad blockers block

is_valid_javascript_content() rejects any script that matches /on\w+\s*=/i. op1.js contains r.onload=, r.onerror= and this.options=, so the inlined SDK is rejected on every page load. The plugin then loads https://openpanel.dev/op1.js, which Safari and ad blockers block, which defeats the purpose of the proxy.

Fix: remove on\w+\s*= from the pattern. op1.js comes from your own HTTPS endpoint, so the check doesn't protect against anything.

if (preg_match('/(?:javascript:|data:|vbscript:)/i', $js_content)) {

With both changes, events arrive correctly, including from browsers with tracker blocking.

Smaller issue: proxy_request() passes the raw upstream body string to WP_REST_Response, which JSON-encodes it again. The browser therefore receives "{\"deviceId\":...}", a JSON string rather than an object. Decoding it first (json_decode($bodyOut)) would fix that.

Disclaimer: I wrote this Issue Description with the help of AI