Skip Navigation

[Résolu] Views 1.10 Caching / Nested Views with Parametric Searches with Pagination

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.

This topic contains 25 réponses, has 3 voix.

Last updated by davidT-8 Il y a 5 années et 11 mois.

Assigned support staff: yuri.s.



Languages: Anglais (English )

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

I apologise for any inconvenience in this matter. I have asked my seniors about their suggestions around it. I will update you as soon as I hear back.

Thank you for your patience and cooperation.



Languages: Anglais (English )

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

After some discussion with my seniors, I have escalated this thread to our 2nd tier support. I hope they will be able to sort it out soon and will update you accordingly.

Thank you for your patience and cooperation.


OnTheGoSystems has SERIOUS Customer Support and Technical Support issues. As a corporation with a global presence and reputation of excellence, I expected prompt, courteous, knowledgeable technical support, with professional communications and status updates. I expected technical support staff to actually support each other, and an overall supervisor to ensure that support requests were acknowledged, assigned, understood, examined, and mitigated, or otherwise rectified in a timely manner. That did not happen. Reading numerous other PAID SUPPORT FORUM posts, it appears as though that doesn't happen very often. It appears as though serious support issues frequently take weeks to resolve.

I reported my issue 77 days ago. In that time frame, I explained, multiple times, the VIEWS PLUGIN CACHING BUG, introduced with 1.10, that I have encountered. I patiently waited and expected my issue was being addressed, only to discover that the SINGLE technical support representative who acknowledged my support request went on vacation for two weeks, wherein my issue went entirely unaddressed and unresolved, finally received NO acknowledgement of actual understanding of the issue by the technical support representative who claimed it was likely expected behavior, who then proceeded to ignore my privacy request, ignored my request to correct the issue, and finally informed me that it was being escalated... 52 days ago. Now, there has been COMPLETE silence on the issue from OnTheGoSystems. The entire situation is unacceptable.

I am going to update to Views 1.11 and continue perform search/cache testing. On an isolated DesktopServer system. Then, I am going to encounter the next Views issue on my production development site... which runs on GoDaddy/MediaTemple systems.

Interestingly, OnTheGoSystems claims that GoDaddy/MediaTemple "changes the WP Object Cache"... which is possible. Based upon what I've closely examined, GoDaddy/MediaTemple, and MANY OTHER PROVIDERS of "high performance" WordPress websites, run a load balanced set of web servers and a distributed APC Object Cache and Batcache architecture. See hidden link and for more information. I do know that if these are not properly configured, a race condition is possible when it comes to WordPress cron jobs and even some database write operations (those were fun logs...).

But I digress... I will provide an update with the results of Views 1.11 testing. I expect OnTheGoSystems will learn from this, and implement a professional ticket tracking system, provide real supervision of technical support requests, and perhaps split PAID TECHNICAL SUPPORT requests from PAID BUILD MY SITE FOR ME requests that seem to be the clear majority of forum posts. Note, I'm not suggesting those be refused... there's valuable information that is posted all the time. However, when real issues fall through the cracks, or appear ignored, it damages the reputation of OnTheGoSystems as a company that provides solutions, and that supports them.


I have updated to Views 1.11. My original cache-related issue, remains. The good news is, that I've played with it on my MediaTemple/GoDaddy website, and my results are *identical* to my development system's DesktopServer-hosted development site that is using NO chaching mechanisms outside of raw WordPress.

I am, however, now PLAGUED with the new "Browser History Integration with AJAX Pagination" feature which results in "automagically updating the current page URL to reflect the pagination state." Please allow me to express my extreme displeasure at the deliberate new "feature," as it ENTIRELY defeats one of the core reasons that AJAX exists; preventing a massive mess in the browser's URL input box. It might be okay for the "feature" to exist, as long as it IS OPTIONAL, or DOES NOT result in altering the web browser's URL input box. Forcing such a major change on your customer base was highly unprofessional.



Languages: Anglais (English )

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

I apologize for the delay in this matter. This issue has already been escalated, however, I have just escalated it again. I hope you will hear from one of the team members soon Today.


...and ANOTHER MONTH has gone by...

...No contact or acknowledgement from support or their MANAGEMENT of the Views issue

...No apology or mitigation for the FORCED browser navigation alteration by Views upon AJAX navigation that defeats one of the primary the reasons AJAX is used on websites!

What is happening with OnTheGoSystems?


Hi David, I'm very sorry for the delay in attending to this ticket. We are making an effort to reduce support times and avoid lack of communication when situations like this happens.

Since you have noticed that Views 1.11 has a different behavior in your host server then your local system I am gonna address the ajax paging browser history. I've requested that our developers verify what direction the plugin will go in regards to optional browser history on ajax and as soon as I have an update I'll let you know.

If you need anything else in regards to the caching issue please let me know.



Hi David, I just got word back from our Views developer and he told me that for our next Views release there is an option in place on the ajax configuration that will allow the ajax routine to not update the browser history.

We are currently in the QA/testing phase for this new release and are aiming for a release at the end of next week. As soon as it's out you should see it available in your plugin page.



1. Please mark Waqas' reply, 336831, private.

2. I appreciate you staying on top of this matter. Thank you.

3. I have downloaded Views 1.12b1 and will be beating that up, pretty thoroughly. Among a plethora of items addressed, Views 1.12b1 includes multiple fixes and tweaks related to pagination, caching, AJAX, and browser history. My issue(s) were directly addressed, including ones I am likely to encounter at the next stages of site development and deployment.


Hi David, thanks for the confirmation.

I'm closing this ticket now but don't hesitate to contact us if you need further support.



The resolution to this ticket has been thoroughly tested. It's definitely resolved.

In a nutshell, Views 1.12 took care of the pagination/caching/AJAX issue, and partially resolved the browser history issue. There are still two outstanding "segments" to the browser history issue, though I've been able to develop my own custom-source code revisions as a temporary (and very frowned upon!) stop-gap.

I would still like post reply 336831 marked private, though. Not sure why that request has been repeatedly ignored.