REST API Issues
TO DO
Notices
- More info should be added to the following notice that tells the user what steps they need to take to correct the problem:

I've added missing settings in Automattic/wp-super-cache#215, along with the following:
-
cache_disable_lockingANDcache_mutex_disabledare the same thing, I've merged them into justcache_disable_locking. -
cache_readonlyANDcache_writableare notices returned by the notices endpoint. -
httponlydoesn't have a persistence setting, it only persists based on if the form was posted and should be handled with local state.
With Cache Stats, are you talking about reformating this response:
GET /wp-json/wp-super-cache/v1/stats
{
"supercache": {
"expired": 0,
"cached": 0,
"fsize": 0
},
"wpcache": {
"expired": 0,
"cached": 0,
"fsize": 0
}
}
If so, I'm not sure what the URI property is supposed to return. Could you propose what the full response is supposed to look like here? We can definitely adjust this.
Regarding is_super_cache_enabled being set properly, this comes from the $super_cache_enabled global directly. This one definitely needs some input from @donnchawp, since he won't need to dig as much to find and answer.
In terms of the saving, I've refactored that endpoint a bit to be more explicit in the mapping of fields to saving methods and in the process uncovered some typos in these save field for is_cache_enabled.
The cache_mod_rewrite setting appears tied explicitly to the is_super_cache_enabled. I'm not sure why, maybe @donnchawp can comment on that as well. :)
@donnapep ^^^
With Cache Stats, are you talking about reformating this response:
GET /wp-json/wp-super-cache/v1/stats
I believe that is the endpoint for regenerating the cache stats, and it should return the updated cache stats with the structure defined below. The plan was to also return this data from the settings endpoint as well though because regenerating the stats can take awhile.
The format is as per the below:
cache_stats: {
generated: 60,
supercache: {
cached: 1,
cached_list: [
{
age: 3029,
uri: 'localhost/blogs/',
},
],
expired: 1,
expired_list: [
{
age: 4975,
uri: 'localhost/support/',
},
],
fsize: '69.78KB',
},
wpcache: {
cached: 1,
cached_list: [
{
age: 95,
uri: 'localhost/support-info/',
},
],
expired: 1,
expired_list: [
{
age: 81,
uri: 'localhost/blogs/',
},
],
fsize: '32.18KB',
},
}
If so, I'm not sure what the URI property is supposed to return.
URI would be the URI from the following screen capture of cached / expired files on the Contents tab:

In terms of the saving, I've refactored that endpoint a bit to be more explicit in the mapping of fields to saving methods and in the process uncovered some typos in these save field for is_cache_enabled.
To clarify, none of the settings were saving. is_cache_enabled was just an example. I did a bit of debugging on the plugin side and this line results in an empty array. I didn't debug any further than that, so I'm not sure if the problem is in the plugin, in Calypso, or both.
To save in Calypso, you can go to wpcalypso.wordpress.com and check the "Enable Page Caching" toggle on the Easy tab. That will trigger a POST request.
Let me know if you need more info. Thx!
I'm not sure if this work is still in progress, but here are some things I've noticed:
-
cache_gzencodereturnsnull. Does that sound correct? I'd thought it would return eithertrueorfalse. -
cache_acceptable_filesandcache_rejected_urireturn an object whose values aretrueorfalserather than strings.
These fields aren't being returned:
-
rejected_user_agent -
lock_down -
cache_direct_pages
If there are no notices, the endpoint returns:

UPDATE: Adding one more missing setting. ;)
cache_compression_disabled - If WPSC_DISABLE_COMPRESSION is false and cache_gzencode is also false, then a warning is shown to indicate that the "gzencode() function was not found." If cache_gzencode is true, the compression setting is shown. Otherwise, if WPSC_DISABLE_COMPRESSION is true, neither the warning nor the compression setting are shown.
The warning could be added to the notices endpoint and eliminate the need to pass cache_gzencode, but we would still need cache_compression_disabled to determine visibility of the compression setting.
Definitely a work in progress. The internals of WPSC don't lend themselves very well to this type of work, so it is going to be a lot of trial and error to get there. I'll go through all of these today with your Calypso branch and see what I can do to fix as many of these as possible. :)
I added compression warnings. The notice will appear if either of these are true (or both true):
- if WPSC_DISABLE_COMPRESSION is defined.
- if the function gzencode() isn't defined.
If the notice is given you can hide the compression setting.
I need to remove cache_gzencode. Use cache_compression instead to enable or disable it.
cache_rejected_user_agent is what you should use for the rejected user agents. cache_lock_down for lock_down status. You can set that now as well.
I fixed the "boolification" of those array settings (cache_acceptable_files and cache_rejected_uri)
You can use cache_compression to tell if gzip encoding is enabled or not.
In 48c7f0900539ea5058d4895be98f3c56515869ca I fixed saving of configuration settings. Update the settings on the preload page and preload_on and preload_taxonomies will be returned as bools.
In 9f1072e24fb70d7e57027592ce332266be3365b4 I fixed saving of wp_cache_refresh_single_only (or refresh_current_only_on_comments) In ca61ae4f40feea849f4a8b470c58104c426e63ec I added code to convert ossdl_https and refresh_current_only_on_comments to bools. refresh_current_only_on_comments has to be fixed this way because the error saving it as a string was in master for a long time so existing configurations will have that setting as a string. ossdl_https is saved as an option which returns a string.
The cache file listing looks similar to that above now (163bcfe52b9136793362c445cae8778cba17c437) but I changed it slightly so it shows directories instead of files, and lists the lower and upper age of file(s) in the directory. Deleting a directory (from wp-admin) deletes the supercache AND wpcache files in that directory.
As of bc9bba0c4600e47650b0586e584d40addd570756 you can set cache_compression to enable or disable cache compression/gzip encoding.
In 9ba185a705c16fe5abc67961c813cf9cf645f9e6 I fixed the problem with is_super_cache_enabled.
The plugin was setting it to false because of GET parameters in the URL. I fixed it by loading the configuration page in the "get settings" function. Had to take care of WPLOCKDOWN too, as it's a constant and you can't load constants twice without triggering a warning or error.
In 08917cd921cb331235ec1ce80a4da9f7888c9756 I added a "reset" API parameter that will reset the configuration, copying the sample configuration file over, and setting up some default garbage collection variables.
I removed the cache_stats setting and added the cache_type setting.