Skip Navigation

[Closed] What $cache keys does Toolset Views use?

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

Sun Mon Tue Wed Thu Fri Sat
- 9:00 – 13:00 9:00 – 13:00 9:00 – 13:00 9:00 – 13:00 9:00 – 13:00 -
- 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 -

Supporter timezone: Asia/Karachi (GMT+05:00)

This topic contains 7 replies, has 2 voices.

Last updated by Waqar 1 month, 1 week ago.

Assisted by: Waqar.

Author
Posts
#2689079

Here is my Chat GPT chat: hidden link
I have many Toolset Views in a single page. I need them all set to preload, so the pages loads many admin-ajax requests to views-frontend.js to pre-load. This takes 40 seconds. Granted it happen async after page load, so the user never notices. That's good. But at scale this is a big server load.

Now, these views do not change often, so we should be able to keep them cached and their preload cached. (I'd think Toolset views's caching should keep the pre-load cached, but okay, it doesn't.

So, let's cache the preload admin ajax request with Redis Object Cache Pro. All this seems doable, Chat GPT tell us how. But I need to know the $cache-keys of wp-views and views-frontent.js?

#2689083

Here is my attempt:
From Chat CGPT:
Your updated plugin looks mostly correct, but there are a few points to address:

Toolset Function: You need to replace 'your_toolset_function_to_fetch_post_views' with the actual Toolset function or method that fetches the post views data. This function should return the post views data as a string or another format that can be directly outputted and cached.

Error Handling: Ensure that you have appropriate error handling in case the Toolset function fails to fetch the post views data. The current code outputs a generic error message, but you might want to provide more specific feedback to assist with troubleshooting.

Cache Key Generation: The cache key generated in the cache_ajax_response function should be unique for each AJAX request to avoid caching incorrect data. Ensure that you include relevant parameters or variables from the AJAX request in the cache key.

Here's an updated version of your plugin with these considerations:

<?php
/*
Plugin Name: AJAX Cache Plugin
Description: Caches admin AJAX calls initiated from views-frontend.js using Object Cache Pro.
Version: 1.0
*/

// Enqueue JavaScript
function enqueue_custom_scripts() {
wp_enqueue_script('views-frontend', plugin_dir_url(__FILE__) . 'views-frontend.js', array('jquery'), '1.0', true);
}
add_action('admin_enqueue_scripts', 'enqueue_custom_scripts');

// Handle AJAX Requests
function handle_ajax_request() {
// Check if Toolset function exists
if (function_exists('your_toolset_function_to_fetch_post_views')) {
// Fetch post view data using Toolset's function
$post_views = your_toolset_function_to_fetch_post_views();

// Check if post views data is valid
if ($post_views !== false) {
// Cache the post views data for a specific duration (e.g., 1 hour)
wp_cache_set('cached_post_views', $post_views, 'post_views_cache', 3600);

// Output the post views data
echo $post_views;
} else {
// Error handling if fetching post views data fails
echo 'Error: Unable to fetch post views data';
}
} else {
// Error handling if Toolset function is not available
echo 'Error: Toolset function not found';
}

// Always exit after outputting the response
exit;
}
add_action('wp_ajax_custom_action', 'handle_ajax_request');

// Implement Caching
function cache_ajax_response($response, $action, $args) {
// Generate a unique cache key based on the action and arguments
$cache_key = 'ajax_' . md5($action . serialize($args));

// Check if the response is already cached
$cached_response = wp_cache_get($cache_key, 'ajax_cache');

if ($cached_response === false) {
// If not cached, cache the response for a specific duration (e.g., 1 hour)
wp_cache_set($cache_key, $response, 'ajax_cache', 3600);
}
return $response;
}
add_filter('wp_ajax_custom_action', 'cache_ajax_response', 10, 3);

Make sure to replace 'your_toolset_function_to_fetch_post_views' with the actual Toolset function that retrieves the post views data. Additionally, adjust the error handling according to your needs.

Please also tell the me $cache-key used (for another approach).

For this please fill in the missing and needed data.

#2689090

Here is another attempt:

<?php
/*
Plugin Name: OB Cache Views-Frontend Output
Description: When on page in an array of regex urls, and admin-ajax fires and hits 'views-frontend.js' intercept the output and cache it in object caching..
Version: 1.0
Author: Your Name
*/

// Define an array of regex patterns for target URLs
$target_urls_regex = array(
'/authors/',
// Add more URLs as needed
);

// Function to check if the current URL matches any of the target URLs
function is_target_page() {
global $target_urls_regex;

$current_url = $_SERVER['REQUEST_URI'];
foreach ($target_urls_regex as $regex) {
if (preg_match($regex, $current_url)) {
return true;
}
}
return false;
}

// Function to intercept admin-ajax requests and cache the output of 'views-frontend.js'
function cache_views_frontend_output() {
if ( defined( 'DOING_AJAX' ) && DOING_AJAX && isset( $_REQUEST['action'] ) && $_REQUEST['action'] === 'views_frontend' && is_target_page() ) {
// Get the output generated by 'views-frontend.js'
$output = ob_get_clean();

// Cache the output using WordPress object caching
if ( function_exists( 'wp_cache_set' ) ) {
wp_cache_set( 'views_frontend_output', $output, 'views_frontend_cache_group', 3600 ); // Cache for 1 hour (adjust as needed)
}
}
}
add_action( 'wp_ajax_views_frontend', 'cache_views_frontend_output' );
add_action( 'wp_ajax_nopriv_views_frontend', 'cache_views_frontend_output' );

#2689093

Please also tell me what cred forms ajax handler is.

#2689094

and wp-views ajax handler

#2689130

Waqar
Supporter

Languages: English (English )

Timezone: Asia/Karachi (GMT+05:00)

Hi,

Thank you for contacting us and I'd be happy to assist.

Before addressing your main questions, it will be helpful to explain how Toolset's built-in cache for view output works.

You can force the cached output of a view in these two ways:

a). In a view created using the Blocks editor, you'll find a "Cache View" option under the main "View" block's settings.

b). For a view created using the classic views editor, you can force cache through the cached="force" attribute in the views shortcode.

Example:


[wpv-view name="slug-of-view" cached="force"]

It is important to note however that there are certain conditions, that will force the view to not use the cached output:

- if the view is using front-end sorting controls
- If the view contains a query filter that listens to the URL parameter
- if the view contains a nested view or a content template
- if the view is set to show posts in a random order
- if the view contains the "conditional" block

Now, coming back to the question in hand, if your views used on the page are simple enough that none of the above conditions apply to them, then using Toolset's own views cache should be enough, and no extra layer of cache is needed in the first place.
( there will be no AJAX calls on the page load to load any dynamic data )

And if your views contain dynamic elements from the list shared above, then implementing a customized layer of cache that you're planning will result in challenges like:

a). inconsistency between the live and the cache data

b). Front-end search filters, sorting, and pagination controls of views will not work due to differences in the loaded DOM HTML at the time of page loading. You'll have to re-initialize all internal script-based functions related to these front-end controls, once the page loading has completed (or after search forms or search results have updated, due to front-end search fields, sorting controls, or pagination).

The implementation of a customized cache layer such as this is going to be not only challenging to implement, but it will also need to be carefully monitored and maintained in the longer run so that it remains compatible with Toolset changes and releases.

Customization of this scale is beyond the scope of support that we can provide over the forum. However reviewing the suggested code from the ChatGPT, those recommendations are only good enough for general PHP guidelines for cache handling. It doesn't fully understand the complete ecosystem of how different elements work together in the Toolset views/blocks plugin. And that is understandable since Toolset is a collection of commercial plugins and not an open source solution, whose source code is available online.

So to summarize, my recommendation would be not to implement a standalone cache layer to cache Toolset views output or involve AJAX requests.
( keeping the focus on improving the loading of static content like images, CSS and script files, etc. )

If a custom cache solution like this is required, then you can consider hiring a professional from our list of recommended contractors ( https://toolset.com/contractors/ ). That person will be able to understand the requirement and develop a solution after carefully studying the existing structure of the Toolset elements and the code.

regards,
Waqar

#2689230

views-frontend.js fires admin-ajax to jquery to jquery migrate to get the preload of 10 views on my page. Views are too slow without preloading, but takes so much time, when I have so many plugins loaded. Note I have offloaded most all from this page. But its jquery that seems to be slow.
hidden link

#2689429

Waqar
Supporter

Languages: English (English )

Timezone: Asia/Karachi (GMT+05:00)

Thanks for writing back.

If you could share the temporary admin login details of the website, I can take a look into the usage of those views and suggest possible improvements accordingly.

Note: Your next reply will be private and making a complete backup copy is recommended before sharing the access details.

The topic ‘[Closed] What $cache keys does Toolset Views use?’ is closed to new replies.