{pods_wh_team_member_whte_gender} and {pods_wh_team_member_whte_gender:value} return the same result, namely “Female” or “Male” (instead of “1” or “2” as before).
Well, I was hoping that my like for your workaround was clear enough as an answer…
But that’s the point: Your workaround worked for some months, and now it has stopped working. Querying that type of Pods field used to return the part BEFORE the pipe symbol, now it returns the part AFTER the pipe symbol.
but in my workaround we talked about using the contains operator as the field value is stored in an array syntax in the DB. And we were talking about string values (like option-1, option-2 and so on) instead of just integers (1, 2 and so on). Now you’re using the == operator and integer values. So obviously something has changed on your side.
Have a look at the second example (field: whmr_equipment): There I have set it up exactly as you told me (IDs as strings), and there I am using the contains operator (no screenshot, but you can trust me). That’s the way I did it for «Multiple Select» fields.
The == operator and integer values used to work fine with «Single Select» fields – like in the first example (field: whte_gender).
So: Both of these examples worked for several months, and now they don’t. I am the only admin on this website, and haven’t touched neither the Pods fields nor the Bricks conditions.
These functions simply do not return the same result as they used to. And it’s easy to proof since if I change the condition to the following, I works again:
we’ve fixed this issue in Bricks 1.9, now available as a one-click update in your WordPress Dashboard.
You can get the label by using the dynamic tag without a filter (e.g. {pods_gender}) and the value by using the :value filter (e.g. {pods_gender:value}). You probably want to use the latter for your conditions.
Please let us know if you are still experiencing issues.
