Acato
Forum Replies Created
-
Forum: Plugins
In reply to: [WP REST Cache] Caching endpoints with query paramsHi @adamhammad
Although that piece of code prevents the error from happening, it is not the correct way to solve this problem. The object type is needed for the plugin to have the ability to flush (or delete) caches automatically if the object is edited/deleted in the wp-admin.
So for instance if your endpoint contains the custom post type
productsand there is a cache for product ID = 42 and that product is edited in the wp-admin. The plugin should check for caches with object type = ‘products’ and ID = 42 and flush those. Your code now simply states it is anObject, which means the plugin will not know it has to flush the cache if the product is edited.(I hope I am making myself clear 😛 )
I already have a solution in mind, which I first need to test. So if this indeed solves the problem I will release a fix somewhere in the upcoming days.
Forum: Plugins
In reply to: [WP REST Cache] Manually flush cacheHi @adamhammad
Yes, there are multiple ways of manually clearing the cache:
- Clear all caches, by clicking the ‘Clear REST Cache’ button in the wp-admin bar (top of your screen)
- Clearing a selection of caches, by going to Settings > WP REST Cache > Endpoint API Caches, select one or more caches and then Bulk Actions > Flush Cache > Apply
- Clearing one single cache, by going to Settings > WP REST Cache > Endpoint API Caches, hover over the cache you want to flush and click ‘Flush Cache’
I hop this answers your question.
Forum: Plugins
In reply to: [WP REST Cache] Caching endpoints with query paramsHi @adamhammad
Thank you for using our plugin. Yes it is possible to cache custom endpoints with query parameters. All you have to do is register your custom endpoint for caching like this:
function wprc_add_custom_endpoint( $allowed_endpoints ) { if ( ! isset( $allowed_endpoints[ 'myapi/v1' ] ) || ! in_array( 'products', $allowed_endpoints[ 'myapi/v1' ] ) ) { $allowed_endpoints[ 'myapi/v1' ][] = 'products'; } return $allowed_endpoints; } add_filter( 'wp_rest_cache/allowed_endpoints', 'wprc_add_custom_endpoint', 10, 1);If you use query parameters they will be cached as well. So a call to
myapi/v1/productswill result in a different cache than a call tomyapi/v1/products?category=apparelI hope this answers your question.
Forum: Plugins
In reply to: [WP REST Cache] Where to add custom domain codeHi @afurnisstap
I have just added two filters which allow you to change the headers for the cached response:
Add the cache control header if it is not present:
/** * Add Cache-Control header if not present. */ function wprc_filter_headers( $headers, $request_uri ) { if(!array_key_exists('Cache-Control', $headers)) { $headers['Cache-Control'] = 'max-age=3600'; } return $headers; } add_filter('wp_rest_cache/cache_headers', 'wprc_filter_headers', 10, 2);Set the max-age to 3600:
/** * Set max-age to 3600. */ function wprc_filter_header($header_value, $header_name, $request_uri) { if($header_name == 'Cache-Control'){ return 'max-age=3600'; } return $header_value; } add_filter('wp_rest_cache/cache_header', 'wprc_filter_header', 10, 3);A new version of the plugin is now available. Please note: the headers are also cached, so you will have to clear the cache in order for the filters to work.
- This reply was modified 7 years, 4 months ago by Acato.
Forum: Plugins
In reply to: [WP REST Cache] Where to add custom domain codeHi @afurnisstap
Given the fact that there are already cache-entries for the
/wp-json/acf/v3/pages/endpoint, I don’t see any reason why that one specific response isn’t cached. The only reason why a response is not cached by the plugin is if the original call is returning an error by either returning a HTTP Code other than 200, or if the returned JSON isn’t valid JSON.About the pagespeed test: It could very well be because of the max-age. When we developed this plugin it was not to score on pagespeed tests, but to speed up the WordPress REST API. I will add it to a list of possible improvements of the plugin and discuss it internally. As a quick fix I will try to (later today or at least this week) implement a filter hook so you can change the max-age value.
Forum: Plugins
In reply to: [WP REST Cache] Where to add custom domain codeHi @afurnisstap
We try to alter the response as little as possible, so the max-age is untouched (for now, maybe we should consider to change it). There are two ways to check if the request is using the cache:
- Check the reponse headers for
X-WP-Cached-Call, if it is present and is set toserved-cachethan the cache is working. - Check if your request is in the list wp-admin > Settings > WP REST Cache > Endpoint API Caches.
Forum: Plugins
In reply to: [WP REST Cache] Where to add custom domain codeHi @afurnisstap,
Thank you for using our plugin.
It is bad practice to edit a plugin, since your changes would be lost when the plugin is updated. Most frequently custom code is simply added to the functions.php of your theme, but keep in mind if you are not using your own theme these changes might also be lost when updating the theme. If so, another option is to create a child theme for all your custom code. See: https://developer.wordpress.org/themes/advanced-topics/child-themes/ for instructions on how to create a child theme.
Forum: Plugins
In reply to: [WP REST Cache] How to exclude endpointsYes you can! Use the hook
wp_rest_cache/allowed_endpointslike this:/** * Unregister the /wp-json/wp/v2/comments endpoint so it will not be cached. */ function wprc_unregister_wp_comments_endpoint( $allowed_endpoints ) { if ( isset( $allowed_endpoints[ 'wp/v2' ] ) && ( $key = array_search( 'comments', $allowed_endpoints[ 'wp/v2' ] ) ) !== false ) { unset( $allowed_endpoints[ 'wp/v2' ][ $key ] ); } return $allowed_endpoints; } add_filter( 'wp_rest_cache/allowed_endpoints', 'wprc_unregister_wp_comments_endpoint', 100, 1);Is this what you were looking for?
Forum: Plugins
In reply to: [WP REST Cache] Automatically flush comments cacheHello @imranp
Thank you for your feedback! And yes, the cache should automatically be flushed when approving/unapproving comments. This turned out to be a small bug, which we immediately fixed. A new version of the plugin has just been released, which should fix the issue.