International name field

RedHen has its own name "property" rather than a field. You can change the order of the first/last name field forms with a form alter call. Or, you could hide the display of this property, add your own name field (using the name module), and then use some glue code or a Rule to keep the RedHen name property in sync with the values in your own name field on creation/editing of a RedHen contact.

It would be a pretty big change for us to remove the RedHen name property and add the Name module as a RedHen dependency. At this time, we are not planning on making that change.

I can confirm that seanberto's proposed solution works, although only to a certain extent. You can hide the relevant Name (and E-mail) fields from being displayed (effects both the user and admin side), but you can't prevent them from showing up in the Edit sections. That last bit is not a problem admin side, but if you allow users to edit their own RedHen Contacts (at ../user/[%user]/edit/redhen_contact), it is not what you want them to see (not in my case anyway).

Also for the benefit of others looking to do something like this, a bit of a longer write-up after the break.

---

I am working with East Asian names and languages on my site and looking for similar flexibility sought by bubu above. 'First Name' and 'Last Name' are confusing once you get Chinese (or Japanese, or Korean...) name orders into the equation. Apart from this, I am also seeking flexibility with regards to display of the RedHen default e-mail field, which is also locked. Here is how far I got so far, and by what route:

I am using a number of customised Drupal Commerce check-out panes (or pages) to collect the relevant information from customers. The Fieldgroup Module is instrumental in this. There is an excellent screencast on how to do that, here:
http://commerceguys.com/blog/commerce-module-tuesday-commerce-fieldgroup-panes-screencast#comment-353

Note though that in that screencast however, everything from the Checkout form(s) goes into the Drupal Core user profile. That is a good start, but we (also) want stuff getting into RedHen Contacts.

By the way, there is no reason that any of this should be limited to Commerce with Checkout Panes. I'd say this could be implemented at any kind of (registration) form process, as long as it works with Rules.

So either way, I:
1. added another Action for creating a new RedHen Contact to the relevant Rule (in my case, the 'Create New User Account on Complete Checkout' Rule) The Action will of course be to 'Create a New Entity' of the 'Contact' type. When you add this Action, you will be asked to map the relevant (first_name and last_name) RedHen properties to data fields you have collected in your form.

Note that at this point, you can (actually: must) also set a (cache) variable for the newly created entity (ie, the new RedHen Contact). This will allow you to refer to it in other Rules, and implement more actions immediately after.

2. added more Actions to the relevant Rule (same as in 1 above) to save other collected information (fields) into RedHen as required. This uses the 'Set a Data Value' rule action. For example, you can set the data value of the "redhen-entity-created:user" data (the first part is the variable you have just set), and map this to the relevant form field value that contains the new user's e-mail address. Since the RedHen 'user' is what gets used to connect RedHen Contacts to Drupal User Accounts, this is a good starting point if you want to keep those two baskets in sync.

Now.... getting back to the point about hiding fields. This works insofar the RedHen display of data is concerned. Per the above, I can create custom RedHen text fields that are for example called 'Given Name' and 'Family Name.' I then have my custom Checkout (or whatever other) form to collect those two values from my customers. And then I can use the Rules described above to populate my custom RedHen fields AS WELL AS the standard RedHen 'First Name' and 'Last Name' when this information gets submitted (or more accurately in my case: when Checkout is completed).

I then hide the standard RedHen 'First Name' and 'Last Name' fields, so that when anyone checks their RedHen Contact Info (at ../user/[%user]/contact, they only see my custom RedHen 'Family Name' and 'Given Name' fields, which I have made visible of course.

So far so good, but coming back to the start of this post, there is one bit where this doesn't work , and this is when a user wants to edit his/her RedHen Contact (at ../user/[%user]/edit/redhen_contact). For the edit form, the hidden/visible setting is ignored and all RedHen fields (bar admin fields like engagement and state) are shown, including those set to be hidden.

I am not sure if this expected behaviour or not, but will be brooding over a way to hide them there too.

Insights (I might be making much more complicated than needed) or comments very welcome of course.

Hard-code solution (not elegant, I know):

Got where I wanted to get to by setting the #type variable to 'hidden' for the relevant form types (First Name, Middle Name etc) in ../all/sites/modules/redhen/modules/redhen_contact/includes/redhen_contact.forms.inc.

This will hide those fields in the user's RedHen Contact edit form. They (and you) will loose the ability to edit the RedHen default name fields, but I have no problem with that (as I have created alternative name fields that they can edit, and how often does one change name anyhow).

The "visibility" options when managing fields through the UI only applies to those fields' display options, not the data entry forms. There are field-level permissions modules that could also remove them from the add/edit forms.

If you are looking for a code-based solution, rather than edit the RedHen code that presents the forms, consider implementing hook_FORM_alter().