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.
My site displays a single search form and multiple lists of posts, one per taxonomy. Each post list displays 10 items, with Previous/Next buttons and manual AJAX Pagination. The Post List View had caching and pre-loading activated, functioning as expected. It is a fairly complex series of Nested Views, functioning as follows:
2. Taxonomy View obtains Selected Taxonomy Terms > calls Post List View for each taxonomy term
3. Post List View takes taxonomy term, finds posts for that term, creates an AJAX manual paginated list.
But I digress...
Prior to Views 1.10, I was able to perform a Parametric Search of post title and post content data and then reset the search with no adverse effect on pagination results. I'd run a search, the Post List View would display the results, and AJAX pagination would work with caching/pre-loading, for speedy forward/back operation. I'd hit the Reset button, the system would refresh the results with the original page load, and then I could navigate the original post lists via pagination.
After 1.10, with its new caching features, I run a parametric search, go to the next page on a searched Post List to obtain results, hit reset, then navigate the same Post List to the next page of what should now be non-searched results... and the search results (cached) are presented... not the original set of non-searched results that were presented on initial page load.
Loading each view with 'cached="off"' does NOT seem to correct the issue. Editing each view and under Pagination and Sliders Settings > Options for manual pagination > Advanced options and removing "Cache pages" and "Pre-load the next and previous pages" results in a slower site, but the issue is temporarily resolved.
In a nutshell... hitting Reset for Parametric Searches may not entirely be resetting everything as expected...
As an FYI, my main development site (currently "under construction") *IS* on a hosting provider using various caches, but my local system development site with NO custom caching solution achieves identical results.
On what may or may not be a side note, as of 1.10, I am occasionally seeing an unusual entry on Post List View front-end output... ALL forms have an "action" and "data-action" attribute set to what appears to be the output of a [wpv-post-field] item (a web link) from one of the (hundreds) of Post List View items on the page. Everything appears to function normally... but why that parameter is there... is just odd. For example...
<form autocomplete="off" name="wpv-filter-200956-CATTR82fc65d2a3c3f8cdbbff6994d57489d8" action="<em><u>hidden link</u></em> WEBSITE.COM/~G/WEBSITEDIRECTORY/~2/C15rlH33_I3/WEBSITE_STORY.php" method="get" class="wpv-filter-form js-wpv-filter-form js-wpv-filter-form-200956-CATTR82fc65d2a3c3f8cdbbff6994d57489d8 js-wpv-form-full js-wpv-ajax-results-enabled" data-viewnumber="200956-CATTR82fc65d2a3c3f8cdbbff6994d57489d8" data-viewid="200956"><input type="hidden" class="js-wpv-dps-filter-data js-wpv-filter-data-for-this-form" data-action="<em><u>hidden link</u></em> WEBSITE.COM/~G/WEBSITEDIRECTORY/~2/C15rlH33_I3/WEBSITE_STORY.php" data-page="1" data-ajax="enable" data-effect="fade" data-maxpages="354" data-ajaxprebefore="" data-ajaxbefore="" data-ajaxafter="tt3" /><input type="hidden" class="js-wpv-view-attributes" data-wpvfeedsource="source" /><input id="wpv_column_sort_id" type="hidden" name="wpv_column_sort_id" value="post_date" /><input id="wpv_column_sort_dir" type="hidden" name="wpv_column_sort_dir" value="desc" /><input id="wpv_paged_max-200956-CATTR82fc65d2a3c3f8cdbbff6994d57489d8" type="hidden" name="wpv_paged_max" value="354" /><input id="wpv_paged_preload_reach-200956-CATTR82fc65d2a3c3f8cdbbff6994d57489d8" type="hidden" name="wpv_paged_preload_reach" value="1" /><input id="wpv_widget_view-200956-CATTR82fc65d2a3c3f8cdbbff6994d57489d8" type="hidden" name="wpv_widget_view_id" value="0" /><input id="wpv_view_count-200956-CATTR82fc65d2a3c3f8cdbbff6994d57489d8" type="hidden" name="wpv_view_count" value="200956-CATTR82fc65d2a3c3f8cdbbff6994d57489d8" /><input id="wpv_view_hash-200956-CATTR82fc65d2a3c3f8cdbbff6994d57489d8" type="hidden" name="wpv_view_hash" value="eyJuYW1lIjoiZGduRkQiLCJ3cHZmZWVkc291cmNlIjoiYWxpc3QtZGFpbHkifQ==" />
This may have nothing to do with the former issue... or may be a clue.
As an FYI to my last update, the "action" and "data-action" attribute content being added to the forms is the permalink associated with the last post added to my WordPress website. This partially follows, as it's outputting $url, which is just a placeholder for get_permalink(), and the WordPress documentation states...
"Note that when used outside The Loop on a posts page (index, archive, etc.) without the ID parameter, it will return the URL of the last post in The Loop, not the permalink for the current page."
Consider this a secondary issue...
Thank you for providing a detailed overview of the issue. The caching options are newer in Views. Although Views Developers have developed this after much research and efforts, but I agree there may be some expected compatibility issues.
Can you please provide following information, in order to understand a few more things about the issue?
- Example URLs to the site for a review
- Is your live site hosted on a WPEngine solution? Or can you determine what kind of caching solutions are in use by the server?
Please let me know, so I can proceed with further investigation - thank you.
My site is still in development behind a construction barrier. I can provide an admin login, or I am willing to provide a copy of my local development site (ran with DesktopServer), as the caching issue is a potentially very serious issue.
Right now, I'm hosting the main site on MediaTemple's (mt) managed WordPress service, which currently uses at least Memcached and APC Object Cache, behind-the-scenes (I'm used to frequent "Flush Cache" operations occur for occasional portions of site development). However, I also see the identical caching errors on my local development website, which runs off my local Windows 7 development box, with absolutely no memory and performance caching mechanisms (or caching plugins) whatsoever. That leaves only three caching mechanisms... WordPress, MySQL, and now, Views 1.10 with its changed caching mechanism. This issue was noted with the change to Views 1.10.
Thank you for providing the details. Since you are using a local copy, I think you can provide a Duplicator Package (https://wordpress.org/plugins/duplicator/). So I can install it here and can try to identify the issue.
I have set your next reply as private, please create a duplicator package and upload somewhere. Then send me the URL to download in the next private message, thanks.
FYI: for the package, you can omit large image files. I suggest creating a copy of site on local machine, remove un-necessary data and then create a package - to keep the download size smaller.
Let me know when you have the dev copy installed, I have *greatly* simplified things down to a single, non-nested, single Taxonomy view to illustrate that caching/pre-loading and pagination, when combined with a parametric search of post subject and content, is very, very, verrrry broken... at least with my site.
Thank you for providing the package. I have downloaded all the files you mentioned.
Please allow me some time to work on this and I will update you as soon as I found a solution.
Okay. If you have issues recreating it, I can export a now simplified non-nested Posts View of a single Taxonomy to enable you to more quickly identify the issue.
I was able to install and login from the package. I am trying to identify the issue and will update you soon on this.
Although I am trying my best to understand the correlations and based on this, trying to examine Views/CPTs. However, if you can provide some to the point Views/CPTs names and some test cases, this will greatly help me do things fast.
I have set your next reply as private, so the information is kept safe.
Thank you for the details. Please allow me some time to look into these. I will update you as soon as I find a solution.
Sorry for the delay in this matter, I was on vacation and just back to work. I will resume my work on this today and will update you as soon as possible.
Thank you for your patience and cooperation.
First of all, please accept my apologies for delay in this matter. In fact I spent some time to understand the overall setup. However, coming back to the point you mentioned in https://toolset.com/forums/topic/views-1-10-caching-nested-views-with-parametric-searches-with-pagination/#post-335687 - please consider followings:
- I did not find a devSearchFD or devSearchFB View and/or Page in the setup, so I had to create it. I created these along the exact same lines you mentioned in the message. Even I copied the content for Filters and Loop Output sections.
- I then tested the page as per the instructions. I was able to identify the issue.
- In fact, it is not an issue. But this is a new feature in Views 1.10 - Caching. By default, views caches information for faster results. I suggest reading https://toolset.com/version/views-1-10/ for detailed information on this.
- The problem you see with the results, is actually due to the caching system (native to WordPress). This is a transient cache, which may confuse sometimes. However, since this is a brand new feature for Views Plugin, I accept there may be some issues. But these are under continous improvements and you will see these working as expected in upcoming versions (hopefully very soon).
-The solution to this is very easy. Rather you edit your view or system to turn off the caching. You can simply turn the cache for a particular view by using cache="off" parameter. As shown in following example code:
[wpv-view name="devSearchFD" wpvfeedsource="eurogamer-net" cache="off"]
So when this certain view is loaded, it always executes new queries (means doesn't take from the cache). I tried this and view works just fine (as expected by turning caching options off from view's configuration).
I hope this explanation and reading stuff at https://toolset.com/version/views-1-10/ will help you understand several new things about Views 1.10 (and upcoming versions).
1. This is why I seethingly loathe PUBLIC support forums. Some information, I don't want to discuss in public at this time, yet there is NO OTHER RECOURSE FOR SUPPORT. Please mark YOUR reply, 336831, private.
2. After 13 days, in which the ticket SAT not being worked on while you went on vacation (someone should have taken over...), you have failed to grasp either of the two issues I pointed out, and decreed the problems are "by design". Your "solution" is to run with caching OFF... and thus run without performance enhancements. That were working CORRECTLY in PRIOR versions of the Views product until they were "enhanced" and CHANGED in 1.10. Basically, you're telling me "sorry, you're S.O.L.".
Great PAID SUPPORT answer.
3. Let me simplify the primary issue...
With "caching" on...
ORIGINAL CONTENT is displayed and segmented into multiple pages
A parametric search is applied to the ORIGINAL CONTENT
SEARCH RESULTS are displayed and segmented into multiple pages
SEARCH RESULTS are then CLEARED via a "Reset Button"
The first page of ORIGINAL CONTENT is displayed again... however... now in version 1.10...
Navigating to subsequent pages *STILL* displays *CLEARED* SEARCH RESULTS
Have a developer examine this. It is NOT behavior that should be occurring.
4. The cached="off" parameter was NOT working... this was ALSO mentioned earlier in the thread. However, you wrote cache="off"... which is it? Documentation (https://toolset.com/documentation/views-shortcodes/#wpv-view) shows the parameter with a 'd'.