[Résolu] Conditional remaining 'selection' BUG

[Auteur]

Publications

[Ljuba]

1) Same thinks happen with back-end and front-end (CRED form).

2) ACTIONS (Selection field > Conditional logic used)

User make conditional selection in the 'chain' of selection fields and if he decide to change (ie) second selection in the 'chain', all already selected options remain visible despite that is the contrary to conditional choices.

a) So, select - Country (US) > State (Texas) > City (Dallas) > Neighborhood (My borough)

b) Change - Country (EC) - it will remain > State (Texas) > City (Dallas) > Neighborhood (My borough) - contrary to conditions.

3) PROBLEM In view will appear too many selections, or user must manually to 'turn back' previous selections.

[Christian Cox]

May I log in to your wp-admin area to see how you have these fields set up? I would like to know how you have chained things together. Private reply fields are enabled here.

[Christian Cox]

I don't see that this is a bug, I see that either way this is handled could produce problems. Either the child fields are reset when the parent field changes, or they are not. If it's just one child field, then it's probably not a big deal if the child fields are reset. However, if there are 10 child fields, and the parent field is changed, then someone loses 10 child fields. There is no one solution that works for everyone. Unfortunately in your case I think custom code is required for this behavior, because you're effectively changing the value of one field based on the selected value of another field. That's not something Toolset conditional fields are designed to accomplish.

[Ljuba]

Unfortunately, it looks that youdidn't understand me well.

1) First, I didn't finished and I know that I will have 'extended chain' (10 or more fields).

2) I'm used to use Formidable (and Caldera) for forms and I didn't get such behavior. So, child fields (selected value) are reset ('cleared')after 'parent' choice switch.

3) Here is not at all about that "someone loses 10 child fields". CONTRARY, selected choices remain selected (instead to be 'cleared'). Unfortunately, I'm not in the stage to show you how HUGE PROBLEM IS THIS (I started topic as I think that it should be fixed and for that is need the time).

3) TEST and you will realize how serious problem is that. As you certainly have some site with FINAL POST VIEWS (front pages), you can quickly and easily to test next.

a) Make 3 generation 2 branch selected fields and apply the simulation form screencasts (you don't need CRED, back-end is enough).

b) Add to CPT View (Template) fields and see that ALL FIELDS IN PREVIOUSLY SELECTED STEP WILL BE VISIBLE (and they should not to be on the Post Page visible, as parent choice is changed). Example with tickets. If you changed that entrance is from today free for children, there will still be that they should to pay (ie) 5$ for ticket (as previously they paid).

QUESTIONS

1) Do you seriously think how such scenario is normal and possible on (ie) Yelp!, Booking, Expedia, .... ('swimming pool is free, but price is still 5$???').

2) Do you seriously think how average visitor/member (ie) 'business owner' will:

a) At first place, understand what is going on with his page, when he change 'parent' value? So, why is there still 5$ ticket, when entrance is free.

b) Get the idea how to fix it (manually to go back step by step)?

c) Website owner support team will do anything else than spend all the resources to help members to 'fix the issue'?

FINAL

1) I don't have the time to check, but I'm 99.99% positive that we will not get same problems with Pods (back-end). As I wrote before, that is not the case with front-end with (ie) Formidable. I faced this behavior only with Toolset. That also makes, your explanation, hardly 'firm'.

2) I don't have the time to check, but as it is possible to make form with Formidable (instead of CRED), I'm 99.99% positive that fields will be 'cleared'. So, front-end can to 'control' back-end fields, programatically.

2) "<e>That's not something Toolset conditional fields are designed to accomplish.". Unfortunately, this is 'logical negation'. Conditional mean that something depends on something. So, if 'child' field value output depends on 'parent' field value output in one direction (during selection), it by logic must to work also reverse. So, if 'parent' field output is empty, 'child' field cannot be under any circumstances to remain filled, otherwise, it is not conditional relation, by definition.

So, if field are not designed to accomplish definition requests of the conditional, they cannot be called conditional fields (eventually, 'partially conditional' or 'one way conditional').

However, I don't want to argue, I just want to know, did Tolset think to fix this HUGE BUG, or not.

P. S. Yes, this is the BUG, as far you will not expose arguments (facts) how conditional relation (fields) is possible in 'one way'. In other words, to be free to 'paraphrase', as you (Toolset) now have in your codes "IF", you 'forgot to place' in that code also ELSE.

[Ljuba]

I must to say that vs HUGE IMPORTANCE of issue I decided to try to test Pods. Pods do not support (native) conditional logic. Than I added to post test conditional fields with ACF (free version) and ..... same behavior as with Toolset.

So, now I must to wait (in this topic) official Toolset standing regards the issue. Hopefully nobody will argue how most likely outcome of massive 'mess' vs changing the choices by member's during the time is not a serious issue.

It is not reasonable to create membership based listing/classifieds site with such behavior of conditional fields.

[Christian Cox]

We disagree on how these features are intended to work. Your idea is that these are parent and child fields. This is an invalid assumption. I see your point, and I understand why it would make sense for things to be different in this case, but I don't think that's how it's intended to work. So I will reassign this ticket to Beda, who handles feature requests. He will evaluate your request to change the functionality of conditional fields and get back to you soon. Good day.

[Ljuba]

I actually just want to clear how in last reply I practically confirmed that your point of view could be considered as correct, by confirmation that ACF have exactly 100% same behavior as Toolset. So, I don't think that I'm unreasonable person to argue with two leading custom fields developers.

It is complete different issue that I disagree how such (above exposed some of scenario's) should not be considered like BUG (as I also don't think that anybody will argue how that is 'normal' outcome - to get FREE entrance with $5 ticket price).

Question is - is it BUG in 'conditional logic' or in my post (fields) concept.

Maybe is right approach to topic that my concept to create 'conditional chain' is wrong and that I should try to solve issue in other way - using 'chained' Repeating Field Groups. I'm afraid just how that will be complicated (for me) to create (as actually any of group should not to contain more than 2 fields).... I already have a headaches ....

Yeah, let see what Beda say.

[Beda]

The Toolset Conditional mechanism allows you to control the display of fields, in the backend, not the display of the fields value thru the ShortCodes, in the front end.

Toolset Types acts correctly - let me explain:

1. You have 3 single Line fields
2. The second field depends on the first, the third on the second's value to display in the backend, where you edit the post
3. You head to the post and match the condition of the first field, this will show the second field
4. Match that value too, it will show the 3rd Field.

This is fine until here and logically recognizable.

Now, once you break the condition of the first or second field, the subsequent and chained fields will not be shown anymore.
No GUI mentions some changes or automated population of values, we just speak of show the field conditionally.

That's it, and this works great.

To solve the issue you got as a consequence, you have to take advantage of HTML conditional and those Fields values.

Let's say, you have a post whereby mistake, the sub-field is saved but is not showing in the admin.
This would still show the Fields' value on the front end.

If you now wrap that ShortCode in an HTML condition that does the exact same as your backend-conditional, hence checking upon the first fields' value, and only if matching, it displays the second fields value and so on.

This avoids showing those "hidden" fields in the posts or content templates if their' "parent" conditional is not matched.

However, it is entirely upon the author to control his input, to make sure the data is correct.

As Christian already outlined, if we would reset the "child fields" in that chain, a simple mistake> in entering parent values would destroy all data added to child fields! and that is not nice either.

Here is the DOC for HTML conditions, if you need more help with this please let us know.
https://toolset.com/documentation/user-guides/conditional-html-output-in-views/

[Ljuba]

Sorry, your statement confusing me completely.

1) "Now, once you break the condition of the first or second field, the subsequent and chained fields will not be shown anymore."

Well, that is exactly the goal of topic and why I complaint, as it is not as you claim here. I prove it if you watch (top) video on home page of the link, you can see very clear that that subsequent field remain visible (in case of field, selected) and it should not to be, as you also confirm now.

2) Front-end, back-end.

a) I just confirmed that behavior on front-end is the 100% same as in back-end (as it should to be normally) and I know that front-end can be 'tweaked' to act different than back-end, but this topic is not about that.

b) "As Christian already outlined, if we would reset the "child fields" in that chain, a simple mistake> in entering parent values would destroy all data added to child fields! and that is not nice either."

So, what is now correct behavior? Child fields (subsequent fields) should be retained (visible) or not? Your statement here is completely opposite from that above (about subsequent fields).

<strogng> TOPIC

However, I don't want to argue and please forget above, as I confirmed that ACF have 100% same behavior as Toolset and I'm not started topic to argue, rather to solve the issue, that after breaking condition, subsequent field remain visible (selected).

So, I think that I know solution, but I at the moment don't have conditions to check (all behaviors, so also on CRED and Views), is it working or not. Also, some other questions raise from solution.

<strogng> SOLUTION

Toolset now applied 'Repeating Field Groups' and they are nothing else than 'hidden' child posts. So, my idea is to place each field what is the part of conditional chain in standalone 'repeating group' (only one field per group). Breaking condition, field will remain visible (selected), but relation of the posts should be broken and field should not to be anymore part of the parent (present) post. In other words, child field will be still visible in the back-end of the post, as 'repeating group' is the (visible in the back-end) part of the post, but relation is broken by changing parent choice and value of the field under any circumstances should not to be part of the post. Is it that what happen, can be only checked in the front-end (CRED and View of the post). So, please be kind and check it.

I hope so that nobody from Toolset will claim that when User change parent selection in conditional chain, subsequent field (in the 'repeating child group') should to belongs to the post.

If you can confirm me that solution working, I have some concerns and questions related to that.

[Ljuba]

As I thought, 'my system' theoretically works (even better than I thought). And now ... HUGE PROBLEM.

A) I started to create conditional system with fields within Repeatable Groups and it looks that Toolset allow creation of more than one (probably unlimited) 'repeatable group(s)' and they are also displayed in back-end, but fields in 'conditional chain' within 'second repeatable group' DO NOT APPEAR during post creation and WordPress (Toolset) not allow post creation as those subsequent fields are required (and reason is clearly displayed at the top of post page).

To be clear, I do not talk about 'nested repeater groups' (what looks as also available option), I'm talking about 'same generation' (level) of 'repeater group'.

B) Than I tried to separate those 'repeater groups' by creation of new Field Group for each, but as I guessed, it didn't worked as Field Groups are 'just metaboxes' within post. So, same result.

C) Finally, I removed 'parent conditional field' out of repeater group and it works as it should (subsequential conditional fields are displayed).

CONCLUSION(S)

1) 'My system' could to work fine, as when 'parent condition' is 'switched' (changed) all fields in subsequent condition disappear from back-end (so, also from post), but they are not deleted (from database), as if 'parent conditional field' is again switch back, they appear again.

So, we have behavior what Toolset (Christian and Beda) claim as important (removed subsequent values are not deleted from database), but we also have what I claim as important (removed subsequent values don't appear in the post), PERFECT (and more perfect can't be).

But. There is the HUGE PROBLEM (as I can see well - in group relationships).

2) Toolset is not capable to maintain more than 'one level' of the 'repeating field groups' relations if they contain fields with conditional logic.

But. Only is not capable to display those relationships, as Toolset yet follow well conditional logic values (he warning at the top of the post that fields are not filled.

For this, I believe, that it is the BUG.

In fact, I believe that ONLY ISSUE is that 'repeater field groups' are by default set with one-to-one relationship (I guess), instead many-to-many (than ll should to works well) and I can't see the option how I can switch that to many-to-many. Is it possible to change that relationship and how?

I created one Sitio post (Playa de Canoa) and you can try it yourself.

[Ljuba]

OK, as I can see that also can be solved (or maybe not?!?).

I should to change concept (structure) of the Posts/Field Groups, to be able to change relationships. In meantime, if you have some comment, please add it, as it can help me.

[Ljuba]

No chance to solve, as it is ... HUGE PROBLEM.

A) Creating more post types makes more problems itself. However, that not solve issue at all for vary simple reason - 'repeatable field groups' are custom post types (only hidden).

Even if I 'cut' all in peaces, no chance to display fields inside 'repeater group fields', as it is irrelevant are they single in the post or group field, only count that already 'second subsequent' field in conditional chain CAN NOT BE ADDED in 'repeatable field groups'.

Why, no idea. I can only repeat, that Toolset correctly 'read fields' wherever they are placed (as required fields), only don't want to display that fields (to be able to 'select as required'). It is irrelevant that I set parent/child post as many-to-many (as for 'repeatable field groups' there is no options for that - ??? - why not when they are also CPT???), it will not be displayed.

Also, Toolset 'grab' selection of the choice in 'repeater field group', but choice is not displayed anymore after saving the post (it is remembered, but not displayed).

I quit and wait for Toolset support reply.

[Ljuba]

'Repeatable Field Groups' not working with conditional logic at all.

With 'nested groups' I have same (slightly more positive or negative) situations like with conditional logic (depends of the case per case base (scenario per scenario). Mostly, scenario is worse. If visitor will forget to delete child (subsequent) choices, they will remain as duplicated (multiplied) options.

So, free entrance with $5 tickets are possible scenario.

Why conditional logic not working in 'Repeatable Field Groups'?

[Ljuba]

Actually, how I can solve this problem?

I simply cannot make website where user is free to change options and to after that appear mess, as basically NOBODY will cancel selections of choices step by step back as he activated final present outcome. If something was with tickets and now is free, they will directly switch to free (and price will remain).

@Beda talk about front-end/back-end difference. There is no difference. If data is not removed from post, it will be displayed in post. Yes, some supercharged 'codes' probably can solve that, but Toolkit allegedly should to be 'programming-less' tool.

Finally, both of you talk about 'loss of data'. What data will be lost. It is only about selected choices (in waste majority of cases) and all of them (including 'data') are useless if they are conditionally connected and than disconnected.

What sense makes to keep ticket prices of $5 in database (post), when there is no more tickets, as now is free?

Whatever.

How I can solve this problem?

[Ljuba]

"Now, once you break the condition of the first or second field, the subsequent and chained fields will not be shown anymore."

I agree, but it not working. Be free and try yourself in aggregated link > Sitios > Playa de Canoa > Admisión (metabox). See 'Boletos para jubilados'.