Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

REST API Issues #25541

Open
donnapep opened this issue Apr 24, 2017 · 19 comments
Open

REST API Issues #25541

donnapep opened this issue Apr 24, 2017 · 19 comments
Assignees
Labels
[Plugin] Super Cache A fast caching plugin for WordPress. [Super Cache] REST API [Super Cache] UI Admin Page settings screen for the Super Cache Plugin [Type] Enhancement Changes to an existing feature — removing, adding, or changing parts of it

Comments

@donnapep
Copy link
Contributor

donnapep commented Apr 24, 2017

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:

read-only-notice

@dbtlr
Copy link
Contributor

dbtlr commented Apr 25, 2017

I've added missing settings in Automattic/wp-super-cache#215, along with the following:

  • cache_disable_locking AND cache_mutex_disabled are the same thing, I've merged them into just cache_disable_locking.
  • cache_readonly AND cache_writable are notices returned by the notices endpoint.
  • httponly doesn't have a persistence setting, it only persists based on if the form was posted and should be handled with local state.

@dbtlr
Copy link
Contributor

dbtlr commented Apr 25, 2017

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.

@dbtlr
Copy link
Contributor

dbtlr commented Apr 25, 2017

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.

@dbtlr
Copy link
Contributor

dbtlr commented Apr 25, 2017

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. :)

@dbtlr
Copy link
Contributor

dbtlr commented Apr 25, 2017

@donnapep ^^^

@donnapep
Copy link
Contributor Author

donnapep commented Apr 25, 2017

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:

cached-files-uri

@donnapep
Copy link
Contributor Author

donnapep commented Apr 25, 2017

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!

@donnapep
Copy link
Contributor Author

donnapep commented Apr 25, 2017

I'm not sure if this work is still in progress, but here are some things I've noticed:

  • cache_gzencode returns null. Does that sound correct? I'd thought it would return either true or false.
  • cache_acceptable_files and cache_rejected_uri return an object whose values are true or false rather than strings.

These fields aren't being returned:

  • rejected_user_agent
  • lock_down
  • cache_direct_pages

If there are no notices, the endpoint returns:

notices-error

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.

@dbtlr
Copy link
Contributor

dbtlr commented Apr 26, 2017

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. :)

@donnchawp
Copy link
Contributor

I added compression warnings. The notice will appear if either of these are true (or both true):

  1. if WPSC_DISABLE_COMPRESSION is defined.
  2. if the function gzencode() isn't defined.

If the notice is given you can hide the compression setting.

@donnchawp
Copy link
Contributor

I need to remove cache_gzencode. Use cache_compression instead to enable or disable it.

@donnchawp
Copy link
Contributor

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)

@donnchawp
Copy link
Contributor

You can use cache_compression to tell if gzip encoding is enabled or not.

@donnchawp
Copy link
Contributor

donnchawp commented May 2, 2017

In 48c7f09 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 9f1072e I fixed saving of wp_cache_refresh_single_only (or refresh_current_only_on_comments)
In ca61ae4 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.

@donnchawp
Copy link
Contributor

The cache file listing looks similar to that above now (163bcfe) 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.

@donnchawp
Copy link
Contributor

As of bc9bba0 you can set cache_compression to enable or disable cache compression/gzip encoding.

@donnchawp
Copy link
Contributor

In 9ba185a 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.

@donnchawp
Copy link
Contributor

In 08917cd 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.

@donnchawp
Copy link
Contributor

I removed the cache_stats setting and added the cache_type setting.

@kraftbj kraftbj added the [Plugin] Super Cache A fast caching plugin for WordPress. label Aug 12, 2022
@kraftbj kraftbj transferred this issue from Automattic/wp-super-cache Aug 12, 2022
@jeherve jeherve added [Super Cache] Preload [Super Cache] REST API [Super Cache] UI Admin Page settings screen for the Super Cache Plugin [Type] Enhancement Changes to an existing feature — removing, adding, or changing parts of it and removed [Super Cache] Preload labels Aug 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Plugin] Super Cache A fast caching plugin for WordPress. [Super Cache] REST API [Super Cache] UI Admin Page settings screen for the Super Cache Plugin [Type] Enhancement Changes to an existing feature — removing, adding, or changing parts of it
Projects
None yet
Development

No branches or pull requests

5 participants