Question about custom endpoints

Hi @mighty_mt

Thank you for using our plugin!

The kind of (JSON-)data in the endpoint doesn’t matter for the WP REST Cache plugin. However, the plugin will not always be able to determine the type of data and cache it as type ‘unknown’. You can help the plugin to determine the data type by using the wp_rest_cache/determine_object_type filter. At this point it doesn’t matter that much that the plugin cannot determine the data type. But in a future release we will add code to flush the data type ‘unknown’ very frequently, because it can cause some errors.

But back to your issue: I have tested your dummy plugin on a clean WordPress installation with only your plugin and the WP REST Cache plugin activated. And the endpoint is cached correctly. So either you are doing something slihtly different than in your dummy plugin or some other plugin is causing some problems.

Please let me know if we can be of any more assistance!

Hello and thanks for your reply.

I did a little more testing and found that “WP REST Cache” works correctly on my local machine (XAMPP on Windows 10, PHP 7.2.4, MariaDB 10.1.31.0). The data from my dummy plugin shows up in “Endpoint API caches” with Object Type “unknown”.

However on my shared hosting account (cPanel, PHP 7.3.6, MySQL 5.6.44), nothing ever shows up in “Endpoint API caches” and also the wp_rest_cache/determine_object_type filter never gets called.
This occurs even on a clean install and with core endpoints like wp/v2/posts (data from wp/v2/posts does however show up in “Item API caches”).

Do you have any idea what might cause this behaviour?

Hi @mighty_mt

This might occur when the setup of the plugin was unable to copy its Must Use plugin to the correct directory. To fix this you can copy it manually from /wp-content/plugins/wp-rest-cache/sources/wp-rest-cache.php to /wp-content/mu-plugins/wp-rest-cache.php

Hi,

I just double-checked but that file was already in the correct location and also shows up in the WordPress admin under “Plugins” -> “Must-Use”.

Hi,

Hmm too bad, because that would be the easy explanation ??

Just to be sure some questions:

• Are you doing a GET-request? Only GET-requests get cached.
• Can you check your database in the wp_options table for the values where option_name = wp_rest_cache_rest_prefix and wp_rest_cache_allowed_endpoints? If either one of these is empty (or not filled correctly) it will cause caching to be skipped.

If none of the answers to these questions provide some insight into why the call isn’t cached, please try and disable the plugin and do a call to the REST API. Check what HTTP Status code you get back from the API, if it isn’t 200 than that is why it isn’t cached.

Thanks for you time and effort.

I just took about an hour to debug this and found the problem.

The skip_caching method in Endpoint_Api always returned TRUE for me which is apparently due to some kind of feature/bug when a server uses FastCGI (which is the case on my shared hosting account):

filter_input() doesn’t work with INPUT_SERVER or INPUT_ENV when you use FASTCGI

Source: https://stackoverflow.com/a/36205923

As soon as I replaced both calls of filter_input in class-endpoint-api.php with direct access to the appropriate keys in the $_SERVER array it all started to work.

I don’t know if this an ideal solution, maybe you can work out an official fix.

Hi @mighty_mt

Good catch! But now how to solve it… We don’t like accessing the $_SERVER array without filtering, but will discuss this internally and see if we can come up with a different solution.

Hi @mighty_mt

It took some time, but we just released a new version of our plugin which fixes this issue. Please let us know if you have any more issues.

I just updated to version 2019.4.1 and the caching works as expected. Thank you.