Skip Navigation

[Resolved] Show/hide custom fields for users based on age calculated from date field

This support ticket is created 4 years, 5 months 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
- - 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 5 replies, has 2 voices.

Last updated by MargeP6083 4 years, 5 months ago.

Assisted by: Beda.

Author
Posts
#1370469

Just starting out with Toolset and would like to conditionally show/hide custom input fields based on user age (under and over 18).
DOB field is stored in the custom post type.

(Also related to DOB field, is there a way to "lock" the field once the user enters submit?

https://toolset.com/forums/topic/calculate-age-based-on-date-of-birth-field/

hidden link

Thanks!

Marge

#1370549

DOB means Date Of Birth Field, is this so?

Toolset cannot calculate values, and does not offer any feature to allow age calculation based on fields in general.

What you can do is hide or show content based on other content - so for example you can show a field only if another field has value XY, or is not empty, or else.
This is done with HTML conditional, as elaborated here:
https://toolset.com/documentation/user-guides/conditional-html-output-in-views/

Hence, assuming your user is a logged in WordPress user, would like have the DOB saved as a User Field, and using that, you could wrap your content in HTML conditionals, that either check on that date or (with some custom code) calculate the time passed from that date (age) and show or do not show the content that is considered delicate.

Without real WordPress users, this will not be possible, as the user data cannot be retained - and that needs to be done so ether code can work on some existing data.

If your users do not log in but are just "guests", I would rather suggest to create a catch all solution, where the user - before he or she even reaches the page with the delicate content is asked wether or not they are 18 (example).
Then, depending on what they click (yes or no) you would redirect to certain pages or views that list full contents or not.
This still brings the risk that a User can reach the URL directly, as they are not logged in, you have no real chance to block them either (with Toolset Access for example), as the data they provide simply is not retained.

Maybe I can come up with a bette solution if I know more about the precise process you have in mind, and what the user will be (logged in or not)

In case you want to do this in a Toolset Form it is very similar:
You would use HTML Conditionals, but you will need real data, saved in the database, to have that working.
If there is no data saved, you will eventually have to fall back to Custom JS that is able to read data in the browser and update the content on the fly.

#1371171

Thanks Beda! The content is not sensitive, but just conditional. I want to be sure the user has parents' involved if they are logging in and we'll require parental info for a different field for members under 18. So, the conditional (show) field will be for parent contact information. The link you shared is exactly what I was looking for?

Is this the correct use? hidden link

Last question. If the above is correct, would I need to have a conditional as well on the form input and output shortcodes.

This will be a profile that's public for some paid members.

#1371613

I have not set up the user input form for this, but I am confused on the admin side. Are the conditionals not dynamic on the wp editor page? I was testing the conditional display feature and it doesn't seem to show or hide conditional fields on the admin page.

#1371941

Conditionals are not working in the backend, they are intended to work on the front end only.
Specially in Toolset Forms they will even show as "shortcodes" when "previewing" them in the backend when inserting the form.

However on the Front end they will evaluate properly.

Note that when using a Toolset Date field, you must return it as a Timestamp, so after you insert the condition with the GUI, you would have to edit the actual ShortCode for the Date Field so to return "raw" value, not a formatted date.

Then, it will work with the date evaluation.

I am also apologizing the delay you experienced here - my weekend was in-between our conversation.
I'm now back at work until Saturday 🙂

#1374831

My issue is resolved now. Thank you!

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