[Resolved] classic view filter with number or string fails-possible bug?

[Author]

Posts

[martinE-4]

I solved my problem of the failed filter by using a taxonomy filter and checking off the term I wanted to test for. I am creating a display/hide flag custom field to display or hide the post from my view.

I could only get it to work when I used a taxonomy. When I tried it with a string field with 'equal to' or 'like' constant of '1' it failed to filter. Also when I tried a filter with a number field with 'equal to' or 'like' constant of 1 (even with '1' ie I tried quotes and no quotes single or double) it did not work.

Maybe you could let me know if this is a bug when you try it. Thanks.

The second minor but concerning 'bug' (sorry didn't want to bother with another ticket) was that when I deleted my custom field, (in this case called 'Hide') it still showed in the pull down menu of the filter (see image attached). The expected behavior would be that it would be flushed out. Please check this too. Thanks.

I mentioned a few days ago that it would be nice if there was an area where we could check on existing bugs that are being addressed. Thanks to the dev team for all the hard work!

[Waqar]

Hi Martin,

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

1. The testing of query filters based on a custom field value would depend on the type of comparison operator and the actual data that is stored in the database.

Can you please create a test view where such a filter fails and add it to a test page, where it can be seen? You can then share temporary admin login details and the link to this page so that I can check the query filter and the available data and reproduce it on my own test website.

Note: Your next reply will be private and please make a complete backup copy, before sharing the access details.

2. If you've already deleted all custom field records with the key "Hide" from the database, but it is still showing in the list of available fields for filtering, you can use "Clear custom fields cache now" button at WP Admin -> Toolset -> Settings -> Front-end Content -> Cache.
( screenshot: hidden link )

3. We do maintain a publically accessible list of known issues at:
https://toolset.com/known-issues/

I hope this helps and please let me know if you need any further assistance around these points.

regards,
Waqar

[martinE-4]

Hi Waqar
Thanks for the ideas. I have not had time to create a test view page you can see. I'll work on it later today. Maybe I'll create a small local site and export it with duplicator?

Regarding the Cache, I tried that (both ways leaving auto and manual checked) and neither had an effect on the pull-down of a previously existing view which I wanted to change. Would that only effect a new view? In any case I think the plugin should manage cache better. Let me know if you agree.

Thanks and I'll get back later with a test for case 1. Glad to know at least that I am working on a new issue. Thanks for the known issues link. Perhaps that should be accessible from the Support page that we submit tickets on? (or did I miss it?)

[martinE-4]

Regarding the Cache issue, I've been thinking - I deleted the custom field from the custom fields area in Toolset and it warned me that data would be lost. But I kept the data records because they were fine with other fields I had defined. So maybe the system can't actually get rid of a custom field if a previous record exists that had something on it? Doesn't make a lot of sense. Maybe you can clarify or ask the devs. Thanks.

I'm going to work on reproducing the filter issue now. I'll create a new custom post put a number field in and try to filter on it. Can I just send you the toolset module for this assuming I reproduce it? That would be a lot easier than running duplicator etc.

[martinE-4]

I put the test toolset module here: hidden link

I verified using the following: (just Toolset plugins with GeneratePress)
custom post type: Test Filter
custom field group: Test Filter Group
custom fields: Display Number, Display String (also initially had Delete 1 and Delete 2 fields for the cache test).

Data contains 3 records with values as follows:
Display Number | Display String
null | null
1 | 1
null | null

Result with 3 record test: [ pass = success works as expected ; fail = does not show any records in view]
Using Block Editor to create view on page:

Filter: Field Display Number is a Number:
like 1 --> pass (shows 1 record)
not like 1 --> fail (0 records)
different from 1 --> fail (0 records)

Filter: Field Display String is a string:
like 1 --> pass (shows 1 record)
not like 1 --> fail (0 records)
different from 1 --> fail (0 records)

Using Classic Editor to create view and then put shortcode on page:
Filter: Field Display Number is a Number:
= 1 pass (shows 1 record)
like 1 --> pass (shows 1 record)
not like 1 --> fail (0 records)
different from 1 --> fail (0 records)

Filter: Field Display String is a string:
= 1 pass (shows 1 record)
like 1 --> pass (shows 1 record)
not like 1 --> fail (0 records)
different from 1 --> fail (0 records)
in 1 --> pass (shows 1 record)
not in 1 --> fail (0 records)

Please let me know what you think? Many thanks for looking at this. If it's not a bug, it is a pretty unexpected result in my humble opinion. Please clarify with devs.

Note: The cache does not clear either when trying to clear deleted custom fields. They continue to show up in the pull-down filter menu (see image attached showing both my Delete 1 and Delete 2 custom fields after they were removed from the custom field group and cache was flushed more than once). This happens even if I create a field and delete it before the first custom post type record is created (ie no data ever exists with the custom field). Pretty sure this has to be a bug.

[Waqar]

Thanks for writing back and sharing the updates.

1. Your detailed tests results confirm what is happening here with custom field filters and it is the expected behavior. This is not something specific to Toolset and let me explain why.

The way post meta or custom field Query works in WordPress, it ignores all posts where no custom field entry record exists with the participating key/slug.
( ref: https://developer.wordpress.org/reference/classes/wp_query/#custom-field-post-meta-parameters )

The following example will make this more clear. Suppose that I have 3 posts in post type Books, with the following state of custom field with key/slug "wpcf-book-price":

a). Book A: no custom field record exists with "wpcf-book-price" key/slug.
b). Book B: a custom field record exists with "wpcf-book-price" key/slug, but the value is empty/null
c). Book C: a custom field record exists with "wpcf-book-price" key/slug, with a value "100"

In this case, when we'll apply custom field filter to posts with key "wpcf-book-price", "Book A" will always be ignored, regardless of the comparison type.

This is also consistent with what your results show, provided that from "null | null" you meant that two of your posts had no custom field record for "Display Number" and "Display String" fields.

Important note: In our experience, the Toolset Modules package is not very useful for troubleshooting and investigations like these. It includes the Toolset components but doesn't cover the actual data and can't recreate the actual website's entire environment, as a whole.

If you still feel we're discussing a different point and something still needs investigation, you're welcome to share a duplicator package.
https://toolset.com/faq/provide-supporters-copy-site/
(I've set your next reply as private)

2. I understand that the main point of confusion regarding the drop-down for the custom field filter in question is that it is connected to the Toolset Types fields and field groups when it is not.

To generate that list of custom fields, the plugin gets all existing custom field keys available in the "postmeta" (custom fields) table and stores them in the cache.
( a cache is introduced here to enhance performance so that an expensive database query like this can be minimized )

This list is not limited to custom fields defined through Types, to allow users to apply filters based on custom fields added through other plugins and themes too.

To remove an item from that drop-down, it is important that:
- first, all custom field records with that key/slugs have been removed from the "postmeta" table in the database.
- then to quickly see the updated list, the "Clear custom fields cache now" button can be used which will regenerate the list.

It works the same for new or existing views.

Another important point to note here is that when a Toolset Type custom field is deleted from a field group or even the entire field group is deleted from the admin area, it doesn't actually delete the associated custom field records/entries from the "postmeta" table. To actually delete those, you'll have to either use some custom code or a database management tool like "phpMyAdmin".
( ref: hidden link )

I hope this makes it more clear.

3. You can reach to the known issues section through its link in the sidebar, at the new ticket submission page:
https://toolset.com/forums/forum/professional-support/

Screenshot: hidden link

[martinE-4]

My issue is resolved now. Thank you!

[Waqar]

You're very welcome Martin.

Please keep sharing your feedback, questions, and concerns - we're here to help!