Fields that are used for mapping between custom fields and LDAP fields are currently detected by
strpos($field, "field_") !== FALSE
This is only always true, when fields are created within the Drupal "Manage Fields" UI. However, if the fields are created by code, they don't necessarily follow this naming schema.
The more robust solution IMHO would be querying the field API:
$is_custom_field = field_info_field($field) != null || strpos($field, "field_") !== FALSE;
$is_custom_field = strpos($field, "field_") !== FALSE;
$fieldinfo = field_info_field($field);
if($fieldinfo)
{
if(array_key_exists('user', $fieldinfo['bundles']))
{
$is_custom_field = true;
}
}
Thanks for checking back.
Chris
Comments
Comment #1
johnbarclay commentedMakes sense. Patch is welcome. What module is this in?
Comment #2
christian.heckl@itonics.de commentedIts in ldap_profile.module
The patch is attached. It also fixes two other issues, i was just about to post:
1) with form field descriptions, where the description would not be accepted by the form api, if a field has a [LANGUAGE_NONE][0]['value'] field.
2) The description text always said "username" even though the same description was applied to all other LDAP fields. I've changed the text to a more generic "field".
[edit]
Just adapted the patch to fix a third issue:
3) The notice for the fields would not show if a admin user would open the profile form. Now it does, but leaves the fields editable.
See the patch below.
Hope this helps,
Best regards,
Chris
Comment #3
christian.heckl@itonics.de commentedPlease note: This patch supersedes the patch above.
Comment #4
kenorb commentedComment #5
grahlComment #6
grahlPatch is not in proper format, please reformat for use on drupal.org.
Comment #7
grahlSince we are querying the field api in alterLdapUserAttributes() this is fixed in 8.x-3.x as far as I can tell and this will not be added to 7.x-1.x either way. If someone needs this in 7.x-2.x, please reopen with a patch.