Skip Navigation

[Resolved] Views API hooks only fire when Views debug mode is enabled

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 11 months, 1 week ago.

Assisted by: Waqar.

Author
Posts
#2672067

Tell us what you are trying to do:

I have several views that are displayed on pages using shortcodes, and I need to alter the query results before they're displayed. I'm using the 'wpv_filter_query_post_process' filter to target the view and perform the changes I need. However, the hook doesn't fire unless I have "Enable Views debug mode" turned on in Toolset settings. I stumbled on this by accident, as I've been trying just about anything to get my functions working.

I've tried with several different hooks, and none of them fire at all (verified with error_log()) unless that setting is checked. When I load the page normally, the filter doesn't fire and obviously has no effect, but when I turn on the debug mode and refresh the page, the filter then fires and alters the data correctly.

I've disabled everything but essential plugins, and the only things still active besides Types and Views are Oxygen Builder and the custom plugin with my filters.

Could you please let me know what may be causing this?

#2672475

Hi,

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

I've performed some tests on my website, but couldn't reproduce this behavior. The function hooked to 'wpv_filter_query_post_process' executes, even with the "Enable Views debug mode" option turned off.

To troubleshoot this, I'll suggest the following steps:

1. Please make sure that WordPress, active theme, and plugins are all updated to the latest versions.

2. It would be interesting to test this with all non-Toolset plugins disabled and a default theme like Twenty Twenty-One.

If it's fixed, you can start adding the disabled items, one by one, to narrow down to a possible conflicting one.

3. In case the issue persists, I'll need to see how this custom function and the relevant view are set up in the admin area. You're welcome to share temporary admin login details, along with the exact steps, to see the issue.
Note: I'll also need your permission to download a clone/snapshot of the website, in case it needs to be investigated on a different server.

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

regards,
Waqar

#2673067

Just a heads up, I need to re-enable plugins to continue working on the site while waiting for an answer. If you haven't taken a copy yet, you'll just need to disable everything again to put it in the state I described above.

#2674205

Thank you for sharing these details.

Just wanted to let you know that I'm still working on this and will share the findings, by the end of the day today.

Thank you for your patience.

#2674339

Thank you for waiting, while I completed this testing on your website's clone.

I noticed that the custom function attached to the filter 'wpv_filter_query_post_process' was working as expected. But, since the website has the 'WP_CACHE' set to true, the view's cached output was showing on the front-end.

This also is consistent with your observation of why the function seems to work once, after you've made changes to the view or the page containing the view.
( This clears the cache of the view, but after the first load, the subsequent reloads again use the cached output )

To avoid this, you can follow these steps:

1. From WP Admin -> Toolset -> Views, use the the 'Clean cache' button in the line with the view 'Auctions - Homepage'.

2. Next, in the homepage where this view's shortcode is used, include the attribute cached="off", so that it always calls the newly generated version of the view's output and not the cached version:
( ref: https://toolset.com/documentation/programmer-reference/views/views-shortcodes/#wpv-view )


[wpv-view name="auctions-homepage" cached="off"]

#2674419

Thanks so much Waqar. Somehow I missed that another plugin had left the WP_CACHE directive set to true in wp-config even after I had disabled the plugin completely.

One more question for you. I set WP_CACHE to false as a test, but the view still seems to be cached each time. It's not a big deal because I can set the cached attribute to "off" in the shortcode, but does Toolset have it's own built-in caching feature? I would have expected updating wp-config to eliminate the view caching altogether.

Thanks again for your help!

#2674421
Screenshot+2023-12-18+10.47.26.png

Quick followup - I updated the shortcode with the cached attribute set to "off":

[wpv-view name="auctions-homepage" cached="off"]

..but the behavior still persists. After I hit the "Clean cache" button next to the view on the listing page and reload the homepage, "Clean cache" reappears next to the view (shown in the attached screenshot) and I have to manually clear it again.

#2675367

Thanks for the update.

The availability of the 'Clean cache' button is not important, as long as your shortcode is using the cached="off" attribute.

Is your website using a server-side or CDN level cache? It is possible that a cache version of the page is showing even without querying the live page, for enhanced performance.

Also important to note here is that there are certain conditions, which will force a view to not use the cached version, for example:

- 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

I'll recommend including any of the elements from the list above to see if that makes any difference. If the issue persists, it has to be related to the server/hosting environment. It would be a good idea to test the website's clone on a different server (even a localhost), to confirm this.
( because I'm not seeing the same issue on your website's clone on my local test server )

#2675573

Fair enough, thanks Waqar. I assumed that because the button kept reappearing, that indicated Toolset was still caching the page, despite the shortcode attribute.

We're not using a CDN or any server-side caching, so it must be something else. I'll keep looking.

Thanks again,