Skip Navigation

[Resolved] Incorrect count of posts when using "auto_fill_default" in [wp-control]

This support ticket is created 8 years ago. There's a good chance that you are reading advice that it now obsolete.

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
- 8:00 – 17:00 8:00 – 17:00 8:00 – 17:00 8:00 – 17:00 8:00 – 17:00 -
- - - - - - -

Supporter timezone: America/Sao_Paulo (GMT-03:00)

This topic contains 24 replies, has 2 voices.

Last updated by Adriano 7 years, 11 months ago.

Assisted by: Adriano.

Author
Posts
#373263

Bob

Using %%COUNT%% in a [wpv-control] view with an auto_fill_default for a custom field.
Field values are selected using a drop down selector.
The drop down selector is being populated using "auto-Fill".
When the default for the selector is active the counts of items meeting the custom-field values set by "auto-fill" only shows the count of those items in the current paginated view.
Other Items associated with other custom field values, show a count of 0 even though they form part of the current data set.
When an item other than default is selected from the drop down then the correct count shows for that custom field value as do the counts for other custom field values available in the drop down selector.

The [wpv-control] is as follows...

[wpv-control field="s2u-family" url_param="s2u-family" type="select"  auto_fill_default="All" auto_fill="wpcf-s2u-family" auto_fill_sort="asc" format="%%NAME%% (%%COUNT%%)"]

The view is set to "Update the View results every time an input changes" and "Always show all values for inputs".

I've created a quick video to demonstrate the issue...
hidden link

After making the video I realised it would probably be better if I created a new Duplicator for you as the database for the copy you have now does not have the additional posts.
So if you need a Duplicator copy to debug this let me know and I'll create a new one.

Thanks,

Bob

#373440

I guess we've fixed that already. Errata available: https://toolset.com/errata/wrong-counters-filter-taxonomy-parametric-search/

#373447

Bob

Unfortunately no.
That patched version of wpv-cache.class.php is the one I am using already and it fixed the double count issue only.
This further bug is that posts are not correctly counted when a default value is set and the view is rendered with the default value selected.

Watch the video for a demonstration of the issue.

Thanks,

Bob

#373780

I've watched your video and I can see the problem. I couldn't reproduce the issue in my local tests, maybe we fixed that problem already. Could you send a duplicator package, please?

#374058

It's difficult to download it, please provide credentials to your site.

#374339

Which View can I see the problem happening? Could you create a copy of this view and then insert it in a dumb page so I can play safely?

#374487

Bob

The views and pages I've setup for the access via the "toolset" menu are all sandboxed (non production).
You can freely work with those views and change settings.
Specifically the views are...
1. Toolset Element Search (parametric input view)
2. Toolset Element View (results rendering and sub-set filtering)

And the pages using those views are...
1. Toolset Element search
2. Toolset Element View

#374655

There was a problem on your filter element, I've just created it again and it's working fine:

[wpml-string context="wpv-views"]Vendor[/wpml-string]<br/>
[wpv-control field="s2u-family" url_param="s2u-family" type="select" auto_fill_default="All" auto_fill="wpcf-s2u-family" format="%%NAME%% - %%COUNT%%" auto_fill_sort="asc"]
#375284

Bob

Hi Adriano,
Unfortunately removing and re-adding a filter using the 'Edit filter' UI will only fix one filter.
I tried to edit a second filter in the View html ('s2u-source') and found that doing so overwrote the filter settings for the first filter ('s2u-family').
This resulted in the incorrect counts on one or the other of the filters (depending which was updated last with the 'Edit filter' UI).
You will also notice that if you attempt to edit the filter of the other filter (the one not recently updated) then the filter UI will not show any filter items to edit in the dropdown list.

So I did some debugging of Views over the weekend and it seems there are deeper issues with filter controls.

The issues are:
1. Filters in wpv-filter-query.php uses View settings 'filter_controls_mode' and 'filters_control_field_name' to define the generation of the native cache. The editing of a View filter settings currently replaces the last existing filter settings with the new settings rather than adding to the settings arrays.

2. If a filter is added using the "+ Add a filter" button in the View editor then the filter is not added to the Views filter Meta fields (filter_controls_enable, filter_controls_field_name, filter_controls_enable, filter_controls_mode, filter_controls_param, filter_controls_type, filter_control_values).

Thus when wpv-filter-query.php executes it only sees one filter type (if added using the 'Edit filter' UI) or even no filter if the filter was deleted/re-added using the "+ Add a filter" button. Thus the View does not get the posts according to the filters that the site developer believes they have set.

There seems to be quite some more work to be done in the editing/updating of filter controls in the Views meta....

You can use the sandboxed views associated with the toolbox menu on my site (still setup for you) to verify the above.

Thanks,

Bob

#375407

Bob

Hi Adriano,
I did some further testing on my localhost and by removing all filters from the View and then re-applying them using the 'New filter' UI button I was able to get the Views 'filter_controls_...' entries to be correctly populated.
The issue with adding a filter using the '+Add a filter' button still exists and that does not add entries to the Views 'filter_controls_...' meta ('_wpv_settings').

This means problem source #1 seems to be able to be worked around by clearing out all filters and re-applying.
However, problem source #2 still exists and the '+Add a filter' editor seems to not update the 'filter_controls_...' as it should.

I did not go through the toolset test sandbox setup on my live site with the same procedure yet.
I can try that later tonight if you don't get to it first.

Thanks,

Bob

#375878

I didn't get the 2nd issue. When you add a filter through + Add Filter it won't add the element in the Views filter section, it should be added manually.

Please give me steps to properly reproduce this issue.

#376083

Bob

OK.
I'm working on content updates for the live site at the moment so will be a bit of a delay.
I'll get a test setup and steps for you ASAP.
It would be helpful if you were able to inspect the _view_settings of a View CPT to see how the View settings are not being set when using the "+Add a filter" UI.
Do you have a tool to allow you to inspect the settings in a View? (stored in the "_view_settings" meta field of a View CPT)

Thanks,

Bob

#376355

Unfortunately not. We do have a debugger for Views for it just works on front-end and doesn't provide such information.

Ok, I'll be waiting for some steps to reproduce that problem. Thank you for your time.

#376386

Bob

Adriano,
OK. Seeing as you don't have a diagnosis tool this combined tool pair will be helpful to you for debugging.
This is much better than trying to use echo or var_dump (which in any case are not good for debugging AJAX issues as you know).

You'll need to use the Chrome browser for debugging to use this setup.
The two components of the setup are as follows.

A) Plugin for WordPress...
hidden link
You add PC::debug($var) into PHP to send data to debug console on Chrome.
Make sure to set the plugin settings so that the PC class is global and that a password is set.
Turn off any alerts etc. that you don't need to see on the client/browser side (in settings).

B) The Chrome PHP Console add-in that works with the WordPress/PHP module
hidden link

Don't load up too many PC::debug entries and be careful when sending large objects/arrays as that will load the interchange.

With the above setup you should be able to diagnose AJAX related issues (any lots more) far more easily/quickly.

I'll get back to you on the test setup for looking into the view settings issue for "+Add a filter" ASAP.

Cheers,

Bob

#377174

Bob

Hi Adriano,
I've just come back onto this issue now.

The steps to reproduce are actually quite straightforward...

1. Login to slidemagician.com using the credentials supplied
2. Visit the toolset menu and then click the SEARCH button when in the search view (no filters)
3. When in the display View select the Family: drop down
(you will see post counts that are currently incorrect)
4. Select the Source: drop down
(you will see post counts that are correct)
5. Next edit the View by deleting and re-inserting the Family and Source filters in the HTML section
6. Revisit the toolset set menu per #2 above
7. The post counts under Family: and Source: drop downs should now be correct for the moment
8. Now use the drop down filters by Family: or Source: once or more times
9. You should see the post counts become incorrect in the Family: drop down

Let me know how you go.

Thanks,

Bob

This ticket is now closed. If you're a WPML client and need related help, please open a new support ticket.