Forum Replies Created

Viewing 15 replies - 376 through 390 (of 518 total)
  • Plugin Author Richard Korthuis

    (@rockfire)

    Hi @solhan

    Thank you for using our plugin!

    We just released a new version of our plugin which enables you to use the rest_route parameter and have the response cached.

    Plugin Author Richard Korthuis

    (@rockfire)

    Hi @viviansolide

    Thank you for using our plugin!

    I am sorry to hear you are having trouble using it. However your error message isn’t telling us much we can work on. It appears to be a GraphQL error, which is not related to our plugin. Possibly something in the output of our plugin is causing the error, but without further information there isn’t really much we can do.

    Plugin Author Richard Korthuis

    (@rockfire)

    Hi @gumbert

    Clear, in that case: no our plugin can not help you with that. All we do is return it in a GET request, we have no support for a POST request to alter the data.

    Plugin Author Richard Korthuis

    (@rockfire)

    Hi @sphykik

    Thank you for using our plugin!

    At this point we don’t have the option to implicitly deny all request except the ones you can specify yourself. I do however like the idea of being able to specify a specific header which will make sure that request is being cached. I am going to discuss it with my colleague and see if we can implement it.

    By the way: I am also curious about the buggy behavior and unreliability when editing blocks. Can you elaborate on that? Tell me what you are doing and what is not working as expected? That is something we want to inspect and possibly fix.

    Plugin Author Richard Korthuis

    (@rockfire)

    Hi @zaheerahmad

    Thank you for using our plugin!

    I am sorry to hear you are having troubles, however your error message isn’t giving me much details about what could be the cause of this. Could you check your server error log to see if there is a more specific error message?

    Plugin Author Richard Korthuis

    (@rockfire)

    Hi @gumbert

    Thank you for your question, however I am not completely sure what you mean? If you set up a description for a page or post in Yoast SEO, it will be available through the REST API if you use our plugin. See our screenshot, where you can see the og:description tag: https://ps.w.org/wp-rest-yoast-meta/assets/screenshot-1.png?rev=2045273

    Plugin Author Richard Korthuis

    (@rockfire)

    Hi @arindam4u

    I am sorry to hear you are facing this error. It appears you are encoutering a timeout, due to the fact the plugin is trying to delete all created caches when you deactivate the plugin. And you are probably having a lot of caches, which makes this a process that takes a lot of time. Thank you for reporting this issue, we have to look into it and come up with a permanent solution for this.

    You could try and delete them all via Settings > WP REST Cache > API Endpoint Caches. This is however a lot of work, since you cannot simply delete them all at once. Or you could add the line:
    set_time_limit(0);
    In wp-content\plugins\wp-rest-cache\includes\class-deactivator.php before line 29. (This is a quick fix and we will look into a better fix for the future.) And then deactivate the plugin (Deactivating will take some time, but the timeout should be prevented).

    Plugin Author Richard Korthuis

    (@rockfire)

    Hi @healthy-lawn-dude

    No our plugin will not help you with that. If you don’t use the WP REST API, our plugin is not something for you. I am not completely sure, but I think what you want can be done with Yoast SEO itself, so I would visit their help-pages and/or their forum.

    Instead of connecting to the database directly, wouldn’t it be better to use the WooCommerce REST API: https://woocommerce.github.io/woocommerce-rest-api-docs/ ?

    Plugin Author Richard Korthuis

    (@rockfire)

    Hi @euroxwamsa

    Thank you for using our plugin!

    I just did a fresh install of bedrock, installed and activated our plugin and then visited some REST endpoints. All requests were cached as expected. So whatever is causing problems for you doesn’t seem to be an issue with bedrock. Not to my surprise, since we use a bedrock-similar approach all the time.
    Are you sure you don’t have any other plugins or code installed which is affecting the REST output?

    Plugin Author Richard Korthuis

    (@rockfire)

    Hi @efbi

    Yes, that should work. Or are you still having problems?

    Plugin Author Richard Korthuis

    (@rockfire)

    Hi @shyamla

    And that object type, is it a (custom) post type or a (custom) taxonomy? (Just double-checking)

    I just did some tests and for me the endpoint caches are all being deleted just as expected. So I suspect there is some other code which is causing this behaviour. We can try to have the cache deleted even sooner by changing the priority of our add_action. Could you try and edit /includes/class-plugin.php on line 144 it says:
    add_action( 'delete_post', [ $caching, 'delete_post' ] );
    could you change that to:
    add_action( 'delete_post', [ $caching, 'delete_post' ], 1 );
    and then retry if the cache is deleted once the post is deleted?

    Plugin Author Richard Korthuis

    (@rockfire)

    Hi @shyamla

    Well that is step 1, you have told the plugin to also cache your custom endpoint. But when you visit Settings > WP REST Cache > Endpoint API Caches in you wp-admin and search for a cache record for your custom endpoint, what do you see under “Object Type”? If it says unknown it still isn’t able to determine the correct object type.
    If it displays the correct object type, then we have to look further as to why it is not being deleted correctly. After deleting the record how do you determine the cache is still there? Did you look at Settings > WP REST Cache > Endpoint API Caches in you wp-admin and was is still there?

    Plugin Author Richard Korthuis

    (@rockfire)

    Hi @radha2914 and @shyamla

    Thank you for using our plugin!

    If we are talking about the default WordPress endpoints, the cache record should be automatically deleted by our plugin. So for instance if you delete a page with ID = 42 and there is a cache for /wp-json/wp/v2/pages/42 then this cache should automatically be deleted by our plugin. Is this not the case for you?

    If we are talking about a custom endpoint then there are multiple solutions / causes for the problem:

    1. Does your endpoint contain a (custom) post type or (custom) taxonomy? Then please make sure the plugin can detect the correct object type. See our FAQ about how you can help the plugin detect it correctly. Once that is done the plugin should be able to automatically flush or delete the cache (depending whether it was edited or deleted).
    2. If that is not possible for you, you could trigger the deletion of the cache yourself. Upon deletion of the record you can tell the plugin to delete all related caches: \WP_REST_Cache_Plugin\Includes\Caching\Caching::get_instance()->delete_related_caches( 42, 'my_custom_post_type', true);

    Please let us know if you need more help, or when it is not working (correctly) for you

    Plugin Author Richard Korthuis

    (@rockfire)

    Hi @efbi

    Sorry for not responding any sooner. We just released a new version of our plugin, which includes a filter to filter te allowed request methods. You can use it like this:

    function wprc_filter_allowed_request_methods( $allowed_request_methods ) {
    	$allowed_request_methods[] = 'POST';
    	
    	return $allowed_request_methods;
    }
    add_filter( 'wp_rest_cache/allowed_request_methods', 'wprc_filter_allowed_request_methods', 10, 1 );

    Please let us know if this works for you!

Viewing 15 replies - 376 through 390 (of 518 total)