[Résolu] the wpv-found-count result not consistent

[Auteur]

Publications

[Darryl]

I'm using an Elementor template with the display conditions set to all event single pages.

There's an Elementor shortcode widget that displays the Toolset Content Template (event-single-template) for the event.

All of the Toolset Views in the body of the page are in the Toolset Content Template. The Views in the sidebar are sidebar widgets.

[Beda]

OK, that has to be dissected first.
We cannot be debugging an issue that is eventually due to nested Templates in Elementor Templates
Note that the Plugins involved in this (Elementor, Toolset) are out of date, hence one of the first steps to be sure this is a replicable BUG would be to update the software involved.

I then need a page where this issue happens with Toolset only.
Then we can be sure it is a Toolset issue, and debug it.

I searched for the Content Template in the Elementor Template so I can get that View.
It took some time because I have no data to work with such as direct links or guidelines as of where the issue happens and with what it is built.
I found, the Elementor Single | Event Template as edited for example here: hidden link, has a Content Template ShortCode as you mention [wpv-post-body view_template="event-single-template"]

In any case, The Content Template event-single-template is edited here:
hidden link
I looked for the eventual View in it which displays the wrong count but have a problem with this:
==> The code on the front end tells me the counter is not even coming from a View HTML but from Elementor HTML, and that's not possible because the counter will only work if inserted in a View loop.
==> I see no view in the Content template hidden link

1. Please, can you help me by providing me the precise link to the View that you use to insert the wpv-count?
2. I will then take that View, duplicate it, minimize it to a minimal output, insert it in a native WordPress Page or event if it's related to events only, without Elementor or Content Templates at all.
3. Then we will see the issue either solved or happening, and can start technical debug

Thank you for your collaboration and your patience.

[Darryl]

I updated the template on the staging site that you have access to, located at hidden link to reflect the changes I've made (just cleaned things up a tish)

I also deactivated all plugins that weren't critical and set the theme to Twenty Nineteen.

I am still experiencing the issue

[Beda]

I notice that now things changed a little in behavior, so before I just needed to cmd+r (reload) to produce the issue, while now I need to either reload many times or hard reload from the cache with cmd+shift+r, which clears the cache and refreshes the contents of the browser forcedly. It seems that something became better - but did not resolve it.

The Content Template is still the similar as when I asked you to provide me the precise link to the View that produces this output so I can insert that on a page and start resolving the issue last week.
There are as mentioned 7 Views, 3 Forms, and a CT applied to that "template", which is the single Event post at hidden link.

I cannot work or resolve the issue like this, because it requires to analyze 71 lines of unrelated code in the Content Template, and 7 potential Views with counting lines of complex code.
I can however now see in the Content Template you use these Views:
[wpv-view name="event-intents-all"][wpv-view name="event-intent"]
[wpv-view name="event-smiles-all"][wpv-view name="event-smile"]

This still does not show me which View it is, however I was now able to extract the ID of the View that seemingly produces the count from the Front End HTML - which before did not show in the source for unknown reasons.

But the ID I found indicates you use hidden link, which is one of the Views indeed inserted in the actual Content Template, BUT does not feature any ShortCode to count items as provided by Toolset.

Please, can you indicated me the precise link to the View where you insert the wpv-found-count shortcode so I can check on that?

Please also consult my previous message here as I have expressed this doubt and difficulty before, it may help to understand why I need this information:
https://toolset.com/forums/topic/the-wpv-found-count-result-not-consistent/page/2/#post-1372887
Once I have that View, I will insert it to a single page to see what happens - and from there we can then Start debugging this issue properly.

Thank you.

[Darryl]

The theme is set to Twenty Seventeen.
The only two plugins activated are Types and Views.
One Toolset Content Template and one Toolset View inserted into that template.

Other than some HTML header tags, some text for explanation, and the Toolset shortcodes, everything has been removed.

Still the same issue.

The first time you view the page, wpv-items-count and wpv-found count report the correct number.
A regular refresh causes wpv-found-count to display zero. This is the same behavior all along for me, nothing in that regard has changed.

Link to page: hidden link
Link to Toolset Content Template: hidden link
Link to Toolset View: hidden link

[Beda]

Thanks, I can see now the View you use (hidden link)

- I've tried to turn of cache of the View ([wpv-view name="event-intents-all" cached="off"]) - that did not solve the issue.
- I've tried to insert it in the Post directly - that did not solve the issue.
- I've tried to remove the filters from the View - that did resolve the issue ONCE, after reloading, it immediately came back.
- I've tried a full new View of Posts in a new Page, hidden link - same issue.

These tests clearly point out there is a cache issue as we pointed out initially.
Views does flush the cache when anything related to it is updated. Hence that why after changing something in the Views filters, it works once.

I see still the must use plugin (atomic-platform.php) active and advanced-cache.php, object-cache.php Memcached

As mentioned in earlier replies and confirmed above, it's a cache issue, and those plugins are cache plugins, hence must be disabled to confirm the conflict.
I am almost 100% that disabling them will resolve the issue - but it would not yet indicate why
Several users use Toolset with those cache options without issues, so it could be a misconfiguration or a new conflict.

What I need to confirm and find the actual cause, is the precise steps about how to implement the precise cache you use, so I can try locally.
I do not exclude a problem in Views, however most likely it is similar to this:
https://toolset.com/errata/views-features-affected-by-servers-who-change-the-wp-object-cache/

I see you mention here https://toolset.com/forums/topic/the-wpv-found-count-result-not-consistent/#post-1360931 that you cannot rename those plugins on your server.
This is not ideal, as you are the site owner and admin, so the Host should to give you correct rights on the FTP too.
Please contact the host and ask them to either explain the restrictions, or to allow to modify/remove those files.
It would immediately indicate if this is the issue we face here.

I am not very experienced in cache plugins, but I know their setup can be very tricky and, I also know WordPress includes object cache natively, see here hidden link
It may be hence not required to have both files in your must use plugins. This might be the results of some plugins activated in an earlier time on your site.

I would also like to ask if it's possible to take/get a duplicate of this site - if everything above fails - inclusive the cache plugins, so I could try locally to see if I can replicate this.
(I already tried with Memcache active on my local, which provoked no similar issues, but as said, I might be missing something important)

Thank you Darryl for the continued patience.
I've enabled a private reply to allow you submitting the data securely if required.

[Beda]

I see it working there, correct?
It says "4" no matter how many times I update the page.

I see you removed the cache plugin, which hence confirms what I mentioned.

Now, to proceed, I need what I explained here:
https://toolset.com/forums/topic/the-wpv-found-count-result-not-consistent/page/2/#post-1377755

1. The steps to replicate this on any other site (the cache implementation, etc)
2. A copy of the (broken) site so I can - according to the steps - replicate this locally.

I want to ensure, that Toolset Views is not doing something wrong, which I cannot do online.

Thank you.

[Darryl]

Pressable came back with a temporary fix while they hunt for a solution.

The following needs to be added to the very bottom of the wp-config.php of the site having the issue.

global $advanced_post_cache_object;
if ( is_object($advanced_post_cache_object) ) {
clear_advanced_post_cache();
}

I'm calling it done, but if you still need a copy of the site, just shout.

[Beda]

That code simply effectively disables cache if cache is used.
Which points again towards an issue with the Cache plugins, but, as the issue is related to a Views item, and not any other Views item, we must be sure we do not do anything wrong here.

Yes, please - I would need precise steps to set the cache up, and if it is required to set it up, also a copy of the site.
If this cache can only be set up on certain providers or hosts, please add all required data for it because I can then contact them and workout a cooperation.

I want to be sure you understand my/our position:
- We (Toolset) must and will ensure that everything within Toolset is done right. If another software causes issues, it does not necessarily mean that software is doing things wrong (mostly yes, but not always)
- With precise steps, we can replicate the issue, and debug it. We can then open processes that lead to stable solutions which will allow you (and others) to proceed using the 3rd party with Toolset without having to use workarounds
- Sometimes it may seem that we try to pass the ball to other softwares - this is not the case. However, as you surely understand, we need to have a precise replicable issue to debug and either fix, or communicate a solution.

Unfortunately it is not possible for me to debug this "online".
But if it is only possible to replicate online, that is still fine, as long I can say to a developer "this is how you reach the issue: set up that, then do this, and click there."

Right now, I have only the "symptoms". I have no "steps" to those symptoms that allow me or a developer to replicate it on a clean site.
Steps are so important because they allow to recreate the issue at any time needed and often point to the "cause" of the problem

So, I suggest (if possible) that we keep this open in case you can provide me such steps, or even just in case the 3rd party finds an issue on their end to be fixed, it may still be required that we share information or cooperate on this.

All I want, is to be sure we do not leave any issue solved with a workaround while it might require work on Toolset code base.

Please let me know if you can provide such steps or eventually (if no local steps will help) the "online" steps to recreate this issue, and if needed the contacts of the host/cache/service that allows rebuilding this.

I will ensure we put all possible effort into solving this problem

Thank you.