D7 port

i second this motion.

subscribe

Hello,

will there be a port for Drupal 7 or is there another module that do this?

Best regrads
Frank

You can try http://drupal.org/project/legal

Hello,

Thanks for your answer. I will test it.

Best regards
Frank

Hi,

I've needed to convert this to Drupal 7 for my own use, so I thought I would post it here - pretty new to understanding Drupal development, but I have this updated module working smoothly on my development site. No idea how to get it up on this project page as a dev build, but if someone has access to do it then great :D

One change from the original is the inclusion of cookie that checks to see if the user has already submitted their date of birth. If the cookie exists and the age request was not enough for access, the cookie reports DENIED and sends the user to a restricted content page to avoid repeat attempts at trying a date of birth to get access.

Hello shane1090,

thanks for your work! maybe you should contact the developer (nicholas.alipaz and gwen) directly so they can make a dev version from your code.
I have test it and have this issue:

Warning: Parameter 1 to validateage_admin() expected to be a reference, value given in drupal_retrieve_form() (line 795 of /...../includes/form.inc).

when I go to "admin/config/people/validateage"

Any idea how to solve this?

Best regards
Frank

@fraweg I'm just creating a new version which has got a few bug fixes - I have found a temporary solution to the issue above which is editing roughly line 283 of validateage.module and remove the ampersand from the variable on the validateage_admin function call.

Hope to upload a newer version soon.

Shane, I quickly looked through the code you provided and am interested in bringing you on as a possible D7 maintainer. This is assuming we can work out some remaining issues I saw in the code.

Drupal Coding Standards need to be followed including using soft-tabs.

The issue you mention with cookie does not seem like an appropriate solution. This module originally used cookies to track and I moved it from cookies to sessions when becoming the maintainer. Sessions are better IMO since storing data on the user's browser is less secure and it requires them using cookies in their browser. Please review what code you changed moving from the D6 version and see if you can add the session tracking back in and remove the cookie tracking.

Thanks for the response, I'll take a look through the link you've provided.

With regards to the cookie, this was crucial for the site that I was modifying the module to work with. Tracking using sessions is OK, but the problem comes when your expecting repeat visitors - constantly having to re-enter your DOB to access the site limits it's accessibility and is frustrating. The change I made to use cookies came after a few weeks of testing in which most people testing got annoyed with it. With using cookies visitors can come back to the site without needing to re-enter their DOB (this was in-mind of visitors who didn't want to register to the site, as I'm aware that there is the facility already to bypass the validation if they are logged in).

What I am proposing is providing the option for the module to operate either by tracking session or cookies - providing the choice to the user of the module depending on how they are planning to use it.

Okay, that makes sense and I see how it could be useful. If that is the case then we would need to have a setting to enable cookie tracking and an explanation of its benefits in the description of the new setting field. I believe defaulting it to off on install would be best initially.

Well, i've uised the 6.x-1.1 and ported it to D7, without any new features.

Summary of Changes:

• Readme.txt: changed the paths, removed the D5->D6-Update part.
• .info: change core-version, remove the info added by d.o
• .install: remove hook_install(), remove the hook_update()s, make use of db_delete()
• .module:
  • hook_perm() => hook_permission()
  • adjust the paths in hook-menu
  • replace hook_user() with hook_user_delete(), hook_user_insert(), hook_user_preserve() and hook_form_FORM_ID_alter()
  • Add element-validation for the selected bod-field
  • Make the field required, so "please enter your @label" is not needed anymore.
  • validateage_admin() gets the parameter as value instead of reference, and seems to be fine with that (not sure why, but i've got notices it would get reference but value, and the value seemed to be empty anyway.)
  • Remove chekcs for the modules 'profile' and 'content_profile', since they aren't available for D7/at all.
  • Instead, get the fields of the user-entity, and check for date-fields, use them as options for 'validateage_field_id'
• validateage_autocomplete_node.inc: Replace the db_query(db_rewrite_sql()) with db_or and db_select, and use drupal_json_output() instead of drupal_json().

What i've tested:

• Choose the field of the user to check the date for. In my case it was a 'date_text', but all 'date_*'-types seem to store the date in the same format, which is 'Y-m-d'.
• Set age to 16
• Test dates (on 19.03.2014)
  • 20.03.1998 => couldn't register
  • 19.03.1989 => could register
  • 20.03.1989 => could register
  • 20.03.2013 => couldn't register

Well... I ported it myself, because i wasn't sure about the cookie-stuff in the other port, and didn't really need it, and since it wasn't final i didn't want to use it on a project.

I guess one could argue to use https://www.drupal.org/project/field_validation for D7 instead of porting this. Just validate for "maximum date: -18 years" and it seems to work just fine.