WordPress 7.1 — PHP warnings “Undefined array key type”

  • Resolved aiyanna777

    (@aiyanna777)


    3 days, 2 hours ago

    After the automatic update to WordPress 7.1, I’m getting repeated PHP warnings in my Apache error log on REST API requests:

    PHP Warning: Undefined array key "type" in /…/wp-includes/rest-api.php on line 2266
PHP Warning: Undefined array key "type" in /…/wp-includes/rest-api.php on line 2275

    What’s affected: My page-optimization service (FastPixel) uses the REST API to post optimized pages back to the server, and it has stopped working entirely since the update — its requests fail. The warnings above appear in my logs on requests from that service’s IP.

    This is happening on two separate sites, on two separate servers, both of which auto-updated to 7.1. Nothing else was changed on either site.

    What I’ve already ruled out:

    • Deactivated every plugin individually and retested — warnings persist
    • Switched to a default theme (from Divi) — warnings persist
    • REST API is not restricted — /wp-json/ returns the full JSON response normally
    • All plugins and core are fully up to date
    • No security plugins installed; no firewall blocks; service IPs whitelisted

    Environment: WordPress 7.1, Apache, Cloudways hosting. Site A runs PHP 8.1, Site B runs PHP 8.2 — the identical warnings appear on both, so this doesn’t appear to be PHP-version-specific.

    Since the warnings originate in core’s rest-api.php and reproduce with all plugins disabled and a default theme active, this looks like it may be a core issue with 7.1’s REST API handling rather than a plugin conflict. Has anyone else seen this since updating to 7.1?

Viewing 4 replies - 1 through 4 (of 4 total)
  • Moderator threadi

    (@threadi)

    2 days, 18 hours ago

    No, I’ve never seen that before. The error messages refer to the validation of a value in a REST API schema, where it seems an important value is missing on your end. Since you’ve already ruled out quite a few possible causes, I suspect the database is the issue. As far as I can tell, the function is also used to validate the output of content. And if that content is incorrect, the error message could be caused by a database issue.

    What still confuses me, though, is how you’re using FastPixel. Is it running through their plugin, or does it run completely independently of everything else? If it’s the latter, it might be triggered by their requests to the REST API if the information in it is incomplete.

    If that’s not the case, you’ll need to debug it further to find the cause. xdebug might help, but it requires the appropriate configurations on your hosting server.

    Thread Starter aiyanna777

    (@aiyanna777)

    2 days, 9 hours ago

    Thanks for looking at this.

    To answer your question: FastPixel runs through their WordPress plugin, which is installed on both sites. Their servers then make requests to the REST API to post optimized pages back. So it’s both — a plugin and external requests hitting the REST API.

    Worth noting: I did test with the FastPixel plugin deactivated, and the warnings still appeared, which is part of why I suspected core rather than their plugin.

    On the database angle — that’s a useful thought, and I hadn’t considered it. Both affected sites are on separate servers with separate databases, though, which makes simultaneous database corruption on both seem less likely. But I’ll run a database repair/optimization on one and report back.

    Is there a way to identify which content or REST route is failing validation? If the warning could tell me the endpoint or the post being validated, that would narrow it considerably. I’m on Cloudways so xdebug isn’t straightforward, but I could add temporary logging if there’s a sensible hook to target.

    Thread Starter aiyanna777

    (@aiyanna777)

    1 day, 8 hours ago

    Solved — and it turned out not to be a WordPress 7.1 issue after all.

    Posting the resolution in case anyone else lands here with similar symptoms.

    The cause was Cloudflare blocking the optimization service’s postback request. FastPixel optimizes pages on their servers and then POSTs the result back to the site via a REST endpoint — in this case /wp-json/fastpixel-website-accelerator/v1/update. Cloudflare’s security layer was blocking those POST requests, so pages would queue for optimization and then error out.

    This is why nothing on my end isolated it: the request never reached WordPress. It also explains why both sites failed simultaneously despite being on separate servers with different PHP versions — they share the same Cloudflare layer in front of them.

    FastPixel provided the cf-ray ID, timestamp, and blocked path from a failed request. Because I use the Cloudways Cloudflare add-on rather than a standalone Cloudflare account, I have no access to Security Events or WAF settings myself, so I passed those details to Cloudways support and they whitelisted the rule on their end. Caching resumed immediately.

    On the PHP warnings in wp-includes/rest-api.php — those appear to be a separate, unrelated issue. They’re still present in the logs but weren’t what was breaking the caching.

    @threadi — thanks for taking the time to look at it. Your question about whether FastPixel runs through a plugin or independently was what pushed me to look more carefully at the external request path, which is ultimately where the problem was.

    Moderator threadi

    (@threadi)

    1 day, 3 hours ago

    I’m glad you were able to find it, and thanks for your feedback 🙂

Viewing 4 replies - 1 through 4 (of 4 total)

You must be logged in to reply to this topic.