Skip Navigation

[Resolved] AJAX filter not working properly

This support ticket is created 7 years, 1 month 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.

Our next available supporter will start replying to tickets in about 2.90 hours from now. Thank you for your understanding.

Sun Mon Tue Wed Thu Fri Sat
- - 14:00 – 20:00 14:00 – 20:00 14:00 – 20:00 14:00 – 20:00 14:00 – 20:00
- - - - - - -

Supporter timezone: Asia/Ho_Chi_Minh (GMT+07:00)

This topic contains 80 replies, has 3 voices.

Last updated by nadavR 6 years, 8 months ago.

Assisted by: Beda.

Author
Posts
#596026

I apologize this delay.

There is no solution yet, however it's planned for the upcoming release (not the beta, but stable release).

I will update you here once it's done and please rest assured that I press weekly for this fix.
I know it is important to you.

#596027

Ok, thanks.

#606617

Hi,

Hope all is well. I just updated to Views 2.5.2. You mentioned earlier in this thread that the issue is planned to be resolved for this version. However, the filters we've discussed seem to not work properly even in this version. Please advise, thanks.

Nadav

#610493

Hi, can someone please respond to my last message here? I have sent it almost two weeks ago. The thread is open without a solution since October... Thanks.

#611042

I apologize my delay.

This ticket did not come back to my queue upon your reply, I will ask if we can change this so you do not need to wait each time, and contact us else how.

No, I have no news about this issue, unless what I shared already, which is, on one hand, the custom code solution, on the other hand, I have news from the Developers that this field, used in this way (saving 0 to the database) needs more review than initially assumed.

It is currently not working as expected and needs more development than expected to adjust this.

For now, the developers even suggest to use Taxonomies instead of that kind of field - something I cannot expect from you of course.

I try to prioritize this issue as much as lies within my possible capabilities.
I also asked for an erratum so to warn the users about the potential issue.

I also have tested internally a patch, that worked for me, but did not satisfy our QA Tester and the Developer also had concerns.
I am hence waiting for more details in regard, I cannot share with you a patch that is not considered safe to use and has shown issues during QA. I might have overseen these issues and it would be irresponsible sharing this here with you to apply.

For now, I cannot present any other solution but the custom code we initially shared here, or to change the setup of the site.

I know that this is not what you wish to read, and I apologize for the turn the ticket took.

As above mentioned, I will continue to ask to prioritize this, as possible.

#611793

We have an errata here outlining the possible current approaches to solve, or avoid this issue.
https://toolset.com/errata/checkboxes-that-save-0-are-interpreted-as-checked-by-views/

I know this is not what you are looking for, but it will:
- avoid other users to set this up with values of 0
- eventually help you with the code we already shared here
- we can communicate broadly there when it's finally fixed or enhanced.

I will also update you here once I have more news.

#619501

Hi Beda,

Another three weeks have passed and my client still can't use this main and critical feature. From your last response, it still isn't clear to me if you suggest that I use the hotfix or not, since on one hand you want this script to run once and then be removed from the code, and on the other hand, new artist profiles added after the script is removed get ignored by the script again.

I don't like mentioning this, but by now it's almost 6 months since I first alerted about this issue. This can't go on for much longer. My client has considered asking me to re-build the entire site without Toolset, but such a thing will cost them a fortune at this point, so we are all stuck and feeling very frustrated – at this issue and the abundance of other issues (see other support tickets by me, some of which have already gone up to the 2nd tier). The Toolset code makes the AICF site unstable with almost every update, and that's not what we signed up for.

Please let me know if there is any news and if a solution can be even further prioritized and receive the full attention of the development team until it is solved.

Thanks,
Nadav

#620448

I apologise for the delay in this problem.

The suggested solution to this problem currently remains to use another Field type or to not save 0 to the database if you use the same field type.

I discussed this with Amir(just now) and the Developers (during the Debug process).
We cannot easily fix this problem.

I can offer you these 3 possible ways to solve the problem:

1. If you are not planning to add more posts, the workaround in the Erratum is a valid solution:
https://toolset.com/errata/checkboxes-that-save-0-are-interpreted-as-checked-by-views/
But, this code needs to be applied after each time you add posts.

2. Change the Type of Field you use, and resave the posts with these new values from the new Field.
For example a Radio Field instead of a Checkboxes Field.

3. Change what to save for the Checkboxes field. Instead of 0, save nothing.
Then, as well, resave all your posts so to reflect this new values.

I personally suggest, to change the saved value, so the structure itself of the Field does not change from checkboxes to the radio field or anything else.
Checkboxes leave you more choices than Radio.

You have 2 options on how to update the Field's data for each post:
- manually
- programmatically

Depending on how many posts are affected (how many posts already exist) it is worth to craft a script to update all the fields in all posts at once programmatically.

I can try to help you craft a code that helps you to update all the posts already existing at once, and removing the 0, and saving nothing where nothing is checked instead.
Every future post then should be created only after you manipulated the Custom Field accordingly so to not save 0 anymore.

The View Custom Filter then eventually has to be resaved once, to have it all back working.

Do you agree with this solution?

If so, I will help you to craft this, and update you here afterwards.

#620548

Beda,

I'm confused.

The last course of action you suggested seems the most logical, I just don't understand if that causes any "damage" to us. Please explain the downside of the last option.

If there's no downside, that's the solution. I suggest that we do this online (skype etc), once on staging and only then on the live site.

Things to keep in mind:
1. There are artists that are adding new posts all the time. We will have to bring the site down while we make changes. That's one of the reasons I think we should do this when we're in conversation.
2. The structure of any of the custom fields cannot change, meaning, checkboxes will have to remain checkboxes etc. and all of the existing value must keep functioning after the fixing process. It must be seamless.
3. There are other current open tickets, some touch upon the Artists CPT. Please at least read over them and make sure that your solution does not conflict with anything else they (Toolset tech team) are working on.

Thanks for the help - I hope we can now solve this the most immediate timeframe. Today would be ideal - I'm available for the next 3 hours (until 12pm EST) or Friday anytime after 11am EST. Please let me know how to proceed.

Nadav

#620552

Again, my client reiterated to me that he wants a solution immediately. Can you solve this today?

#620560

The structure of any of the custom fields cannot change, meaning, checkboxes will have to remain checkboxes etc. and all of the existing value must keep functioning after the fixing process. It must be seamless.

As stated, this is not possible.

While I can help craft a code that will take old values, and save nothing for where 0 was saved, I cannot help you to have this same structure in future.

We would need to update all existing Posts (their Fields) and then, change the options settings for that Field in the Post Field Group.
So, all new posts will never again save 0 to the database but nothing, if not checked.

I cannot solve this today immediately, it is a large and complex code to write, we deal with Checkboxes, which are special arrays, and that requires some time.

My plan was, if you agree, to take the original Duplicator which I still have, run my script there, make a test by adding as well new posts, and check if this feature then works.

After, I will share the script with you, and you can test this on a staging site for example (it will be simple to test).

After, if you also confirm it's working, you can then go ahead and apply that once on the live site.

The Script will only influence the specific field that is of type Checkboxes, and it will only edit this field for one post type a time.
For other Post Types, and fields, we would need to alter the script slightly.

If this is OK for you, I assume I am able to provide you with this script by tomorrow, ready to be used and adapted to also other sites/types/fields of type checkboxes.

Doing this online is not really worth it, as it's simply about loading a certain URL in the front end, whereas the script will execute.

But if you wish, you can schedule a call here:
https://toolset.com/toolset-support-policy/ask-support-video-call/

Please let me know if you are OK with the outlined process.

#620568

I do not fully understand the implications to the site, thanks for the detailed explanation but I can't tell between the lines if this is going to make it harder in the future. What harm/damage will this be causing to the site? Or is this a safe operation where everything will work just as expected at the end - both on existing and any new artist posts? That's all I need to know at this point.

#620569

The script does update a field value.

Where before was saved 0, now will be saved nothing. The Field option simply will not exist in the database for this post.

This can have implications as in:
- if you actually had a search by those "0" values
- if you had a conditional HTML in place checking upon "0" values
- eventual Emails in CRED triggered if the value was 0
- etc

All places where you explicitly used that "0" value must be updated (manually) to now check upon "does not exist" or similar, as the value in the database will change.

Hence it depends how much you used that value "0" on your site to determine if it's a lot or not, and I cannot do that as I did not create the site.

It is the only solution thou if you want to proceed using Checkboxes, and proceed to add posts and proceed using this field in a search.

#620573

Which fields exactly are we talking about? Please list them all.

#620578

We are talking about the field reported in this very ticket, by you, as not working, which are Checkboxes Fields, where "0" is saved if nothing is checked.

As far I know, in your case, that was one field:
'wpcf-instrument','wpcf-music-genres'

At least, that is what was reported to us, and what we fixed with the custom code here in the ticket.

However here I see you added some fields:
https://toolset.com/forums/topic/ajax-filter-not-working-properly/page/4/#post-580727

It would be up to you to submit the list of all post types and their fields you want to change the script.

I would need to know exactly to what post type, and what field to apply the code.
(Slugs of Post Type and Fields, and their exact options too).

I can drag most of it out of the original duplicator if we refer to the originally reported Post Type/Fields which were one type and 2 fields.

If this is more, please can you present me the exact slug names of the Fields that you used with a 0 value?
And, if those apply to different posts, those slugs as well.

My code will need to be crafted exactly so to match the data as stored in the database.

I can do that now (so you have it tomorrow) for the fields and type I know of.

Any other field or type could then be added to the script eventually.