How to Fix the WP API Returning Invalid User Id Issue

We recently got a client support request for a fix regarding an issue they were constantly experiencing while trying to edit or publish a post on their WordPress news site.

It seems that now and then, the Author was locked out of the post and had to re-login to continue editing the post. Every time the Author experienced this glitch, one of the following warnings was displayed on his post-edit page.

“Updating failed. The response is not a valid JSON response.”

or

“Updating failed”

After creating a staging site, we tried and finally managed to experience the issue ourselves. The first thing we did to troubleshoot the issue was to disable any Security plugin installed and activated on the WordPress staging instance.

While testing the staging site, we didn’t notice any similar issues. Hence, it was time to start debugging the live site and training the Apache and server error logs looking at the timestamps which belonged to the JSON issue as the WordPress site owners reported them.

Once we got a new report of the issue, we trailed down the Author’s IP within the server access log, and we found out that the following URL reported a 404 warning:

GET /wp-json/wp/v2/users/14?context=view&_locale=user

The next thing we did was access the site’s error log and track the line with a similar timestamp; this is what we got:

/ds-divi-extras/ds-divi-extras.php:268 agsdcm_process_module_query():
You’re Doing It Wrong! ET_Builder_Module_Posts_Carousel_AGSDCM::$shortcode_atts is deprecated. Use ET_Builder_Module_Posts_Carousel_AGSDCM::$props instead.

Even though this shows a connection between the JSON warning and the DIVI itself, it was worth visiting the wp-json URL and seeing if our browser output a 404 warning.

This was the output on our browser:

{"code":"rest_user_invalid_id","message":"Invalid user ID.","data":{"status":404}}

While this was the Chrome Inspector Debug Console output:

These types of warnings are related to either restrictions and throttling applied by the hosting provider for security reasons or through a WordPress security plugin. Even though we have disabled Security-related plugins on the WordPress installation, one of the admins seemingly re-enabled the Wordfence plugin.

Since Wordfence was still disabled on the staging site, which we kept on testing without any issues, we disabled it on the live Web App and tried to access the direct wp-json user URL. The response on the browser was the following:

It seems that once we disabled Wordfence, we could access the wp-json call for the users. The next step was testing the live WP installation through the authors who kept posting new articles. After several posts were published, not one JSON or “Updating failed” warning was reported, so we seek a way to a. enable Wordfence once again and b. avoid being blocked by its security rules.

Since this was a live WordPress site instance, we resumed our troubleshooting on the staging one; we re-enabled Wordfence and searched for a setting that blocked access to the WP API user list.

After visiting Wordfence’s “All options” page, we randomly searched for the “API” keyword and the first, and the only result was about the “Prevent discovery of usernames through ‘/?author=N’ scans, the oEmbed API, the WordPress REST API, and WordPress XML Sitemaps” which was enabled by default. The next step was to disable this rule and revisit the wp-json user URL.

The browser output was successful since the user details showed the app, and there wasn’t any 404 warning.

We applied the same setting on the live site WordPress instance, accessed the direct URL successfully and asked the Authors to monitor for any JSON-related issues.

After two days of monitoring the WordPress site post-publishing backend, all JSON issues were gone!