I use do_shortcode('[wpv-post-body view_template="confirmation-shell"]') in a PHP code file to pull some boilerplate text from a Toolset > Template record for emails send via the PHP code. Randomly, the record returned is not the "confirmation-shell" record, but instead a completely unrelated record that was created via the Modern Events Calendar (Lite) is returned. Once it starts fetching the incorrect record it will continue to do so for several minutes. Eventually it will start returning the correct record again. This has happened 4 times over the past several months.
The last time it started failing I was able to switch over to using render_view_template(16402) [where 16402 is the record id of the shell page] and got the same results. It fetched the incorrect record for several minutes and then started finding the correct record.
This problem never has happened when using '[wpv-post-body view_template="confirmation-shell"]' in Gravity Forms notifications.
I can't force it to happen. It just happens randomly once every 3-4 weeks.
Can you give me any ideas about where to look to address this issue?
Thanks...
Hi there,
That is a weird thing happening. It seems like the Modern Events Calendar (lite) plugin somehow hijacks the query from Toolset.
The fact that it is happening randomly also points to a possibility of some server Varnish or Object cache interfering with queries.
For both scenarios, I have suggestions for troubleshooting.
For the hijacking scenario, I suggest that you use the suppress_filters="true" attribute when you use the wpv-post-body shortcode.
That attribute disables any third-party plugin interference according to the documentation below:
https://toolset.com/documentation/programmer-reference/views/views-shortcodes/#wpv-post-body
For the server cache scenario, I suggest that you copy the website to a staging version. In the staging environment deactivate any sort of server-level cache that you might use.
Wait to see if the issue happens on the staging server or not.
These are the points that I could think of. Hope I could be of help.
Thank you.
Thanks for your response.
Here's so late-breaking news on this. Looks like every time a new record gets added to the MEC Calendar, the potential for the problem occurs. The actual problem appears to take a combination of a new MEC record and the email PHP script running within a few minutes of when the MEC record was created. The calendar is lightly used in our site and the PHP script only runs a few times a week. That's why it seemed so random.
When a new MEC record was added this morning I triggered a test of the PHP script and the problem occurred. I tried the suppress_filters suggestion but it had no effect.
I guess that means that means that this is some sort of a server cache problem but I don't see how there would be a cache issue since the MEC and my PHP processes are totally different.
Any new thoughts?
Thanks, again...
Hi there,
Now I am completely lost. I have no idea how this might happen. What I can suggest here is somehow general solutions.
Use XDebug:
Download your WordPress website to your local machine and setup Xdebug to trace the code of your PHP script by triggering it manually after you add a new MEC record.
That way you will go step by step to the ins and outs of the PHP code for both MEC and Toolset. There you might find something that can help.
Use a WordPress Query Monitor
A query monitor could help you understand what's happening when you run the PHP script. It can show you what queries are being run and where they're coming from. This could give you a better idea of why the wrong template is being returned.
Contact MEC support
Ask their support if there is any sort of general hook they use that might "hijack" a query from another plugin? Maybe a fix in the priority of a hook can help?
This is indeed something that the developer of the website should do custom debugging to get to the bottom of the issue as the use-case and the error is super edge case.
If you will need help for debugging the list below can help you hire such developers that have familiarity with Toolset:
https://toolset.com/contractors/
(The list above does not include MEC proficiency and you need to check with MEC support for that.)
Thank you.
