!first_name and !last_name are empty when provisionning is integrated with the content_profile module

There was a typo in the code. I committed the fix which works for me. Please verify it.

I'll add a report to this as well, with a request for any help that you can provide!

- I have the latest (from the 'v.6 tags' - which is the same as "HEAD" for ldap provisioning) versions of both content profile, ldap integration and ldap provisioning from CVS. (My working version of ldapprov.module is 1.53 )

I'm attempting to debug my way through to find where in the code the problem might be arising, but I'll add my description of the problem as well. I installed a clean version of Drupal (core) and the modules in question to make sure I'm looking at what I think I'm looking at...

1) I installed LDAP Provisioning, which works perfectly out of the box with the LDAP server.
2) I installed cck and content_profile, then created a content profile with two fields:

field_first_name ("Required")
field_last_name ("Required")

3) I add these fields to the

UPDATE: I found where the issue here lies; perhaps with a change in the Content Profile (Registration) module?

At any rate, I noted in the ldapprov_register_submit function where the values are taken from the submitted registration form:

ORIGINAL: $values = $form_state['values'];

... however, the actual data does not appear to be in that array. Looking at the data passed in to the register_submit function, I see that the data entered in the form appears here:

MODIFIED: $values = $form['user_registration_help']['#post'];

If I assign the variable '$values' to the second value, the registration process works. Now, there has to be a better way (I'm not an experienced Drupal developer, obviously) to access that data, but it appears that somewhere along the lines the submitted form data has been moved.

Last time when I was integrating ldap_provisioning with the content profile, I have used version content_profile-6.x-1.0-beta3.tar.gz. So ldap_provisioning should work with a beta3 (could you verify that the bug you're describing does not occur with the beta3?).

Once a new release of content profile is out I will adjust ldap_provisioning to it.

Confirmed this bug exists with content_profile 6.x-1.0-beta4 and ldap_provisioning 6.x-1.0-beta1

Attached is a patch against 6.x-1.0beta1, which implements what ChadAtKrell suggests above. In addition it adjusts another section of code since the content_profile fields no longer come through the values array they need to be accessed at "FIELDNAME[0]['value']". There may be more sections that need similar adjustment.

Apply with 'patch -p0 < 442788.patch' from where your ldap_provisioning module is located.

Woah, this is old... though it still seems valid. Marking as "needs review".