Customization of field titles and help text

I agree. tried using string overrides to change the "State / Province" field title to "County" but it's being overriden by the js (I think). Was able to change the field labels on other fields using string overrides....such as "additional".

I understand wanting to have further customization for each field's menu. Currently the hook will not allow for this type of interaction but it is something that I'm looking to do in 2.x when I restructure the project.

We are having difficulty with the presentation of the information as well, particularly in views, despite fiddling around with tokens. Would this be resolved by breaking out all the theming /presentation information into tpl files? This could make this module really flexible - but I do accept that it would be a major effort.

cmorrish,

For 2.x we could certainly add this in after the initial release. Is this something you would be interested in aiding in?

Erm .... if you would be tolerant of my learning curve! It's something I am only beginning to play around with - but why not.

All the Best
Cliona

Cliona,

I always appreciate help - lets look at this after 2.0 is released and evaluate the work-load

I required this functionality, so I went ahead and added it to the module -- patch attached.

This approach should provide compatibility with modules providing 'extra' fields without requiring any modifications on their part or API changes. To modify each field element's visibility setting, size, label, or help text simply navigate to the Manage Fields -> Addresses Field Configuration section for your node type.

I have only tested this lightly, but seems to be working on my end. Feedback is welcome.

A few minor fixes.

Sorry - I'm juggling a patch to the javascript that should not have been included. Hopefully this is the last update.

I just noticed that both the Admin Settings page and the CCK Field Setting hook both make use of the exact same form function. As I had not considered the effect on the Admin Page, the updated form elements are not saving there -- this doesn't impact your ability to customize each field instance per content type individually, but the 'overall' configuration is broken. I will look into it this weekend and get an updated patch posted once I have it resolved.

ISPTraderChris,

Isn't that patch for 1.x? I like it, but I think it should go against 2.x as cody mentioned. I have not yet looked into 2.x because... I did not have the time yet. 8-)

Somehow 2.x is twice smaller! I'm not too sure why that would be... But 2.x should have fields 100% dynamic instead. So you can create new fields just like in the profile module. That is my vision at least. I'm also wondering since if we support CCK we don't really need to have all that dynamism inside Addresses. On the other hand, to have an address book, we cannot use CCK.

Thank you.
Alexis

The patch is against 6.x-1.08 -- this is the only stable release version available at the moment, and it is the version we are using in production. It is also the version that the majority of the Addresses users are using.

The importance of this module, for me, is that it provides a standard set of addresses fields AND a consistent set of Country and Province information. Anyone can create a set of address fields in CCK - but it is much harder to manage due to the large number of individual fields required -- and it is time consuming to manage all of the country and province information manually. When you add to this a requirement for MULTIPLE sets of addresses within a node type, the individual-field cck approach becomes a nightmare (you have to try to use the experimental CCK multigroup) -- and the database becomes a mess (one table for every field).

I have not looked at 2.x yet, but from your brief description I would think this patch would not be needed there. However, for the time being, I think it will be very useful to users of the 1.x branch. I would not really consider this patch as providing new functionality, simply configuration options. As CCK users, we are accustomed to being able to set certain basic parameters for our form elements (Label, Help Text, Size) but in the case of Addresses, we were previously not able to do this.

It would be useful, I think, to have the flexibility to add certain custom fields to the addresses block, but I also think its important that there are a standard set of always-available fields. I am currently developing a module that will be dependent on addresses, and maintaining a core set of fields would be pretty much essential for this to maintain interoperability with other modules. I think where you will have some difficulties with the 100% dynamic solution for 2.x is when you start to consider views integration -- it can be done, but it will be complex. You would be essentially recreating CCK functionality.

Here is the updated patch. The previous patch had basically broken the settings for the addresses_user module -- this has been remedied. You may now customize the addresses field elements both for CCK and for Users.

Hi ISPTraderChris,

Could you explain this one to me? Who is going to set that #field_info.#field_name element?

+  $settings = empty($form['#field_info'][$element['#field_name']]) ? variable_get('addresses_user_settings', array()) : $form['#field_info'][$element['#field_name']];

Also, you cannot generate a patch using the -b flag or we lose the proper tabulation in many places. I generally use -dur (which is the French word for "hard".) You could use -dru which is the beginning of Drupal. 8-)

Thank you.
Alexis

Alexis -

Administrators will configure settings either in admin/settings/address (this configuration is used for displaying the addresses field for users) or in admin/content/types/node-type/fields/addresses_field (this configuration is used for displaying the addresses field for cck). If cck is rendering an addresses field, it will add $form['#field_info'][field_name] to the $form parameter -- this will contain all of the cck field settings we require. If we don't find this field, we assume the addresses field is being rendered for users, and we then pull our settings from the addresses_user_settings variable.

I have attached an updated patch per your request.

ISPTraderChris,

I have a little concern with the following loop:

  foreach(array_keys($fields) as $ftype) {
    if (!empty($settings[$ftype . '_select'])) {
      $fields[$ftype] = $settings[$ftype . '_select'];
    }
  }

It seems to me that if the variable_get('addresses_user_settings', array()) still includes fields that were removed, then that loop will add them to the list of fields. I think we could test with the addresses_extra module. Add the module, setup the fields with different names, etc. and then uninstall the addresses_extra module. At that point, this loop should have a problem.

I would imagine that the CCK fields will be just fine since they use the list of fields as expected.

What do you think?

Thank you.
Alexis

ISPTraderChris,

Another question. You limited the label and description to 255 characters. Is that because of CCK? If not, I'd prefer to remove that limit.

Thank you.
Alexis

ISPTraderChris,

There is a problem still.

The card being generated uses <dd> which by default is hidden from view. The labels that you define in the settings are not put in those tags. Instead, the default field label is used.

The function concern is in the addresses.module file. The $object is the field which should have its 'aname' changed to the user specified name and translated.

function addresses_token_values() {
  [...]
         $values['addresses_'. $field .'_'. $format] = theme('addresses_'. $module . $field, $object, $format);
  [...]
}

Thank you.
Alexis

ISPTraderChris,

Hmmm....

I checked in your patch after I created 6.x-1.09 so my other fixes won't be included with yours.

However, at this point, I cannot make the CCK widget work. When I go to create a new page with an address_cck field, it does not appear at all. Any idea what could cause that? I have to say, I did not think of testing before applying your patch. 8-)

However, the change in the CCK was very very small so I really don't understand why it breaks so much.

For further patches, please, use the new -dev version. 8-)

Thank you.
Alexis

Alexis -

I'm just getting back from a weekend holiday and getting caught up.

#16) The $fields variable is passed through to this function via $element['#fields'] -- this should only return active fields that are provided by the core and contrib modules. This was not something I modified. It is true that the variable may still include settings for fields that were disabled, but this doesn't matter because we are only adding data for fields provided by $element['#fields'] (active fields). These 'inactive' variable field settings will go away the next time the admin updates / saves field settings.

#17) The 255 limit for the label is a CCK restriction (if you check content_field_instance you will see the label field is varchar(255)). The description, however, is mediumtext -- so we do not need this limit. I will remove it.

#18) This will require a further update -- I did not consider integrating my update with tokens.

#19) I will apply my changes against 6.x-1.x-dev and re-test the cck widget. At this point I'm not sure what might be causing this.

Alexis -

Here is a patch that addresses #17, and #19 against 6.x-1.x-dev.

Regarding #18 -- I think I am not entirely clear on the issue after reviewing the code. The cards are generated via token replacement. Each field has a theme function that wraps the token (field) value in a span tag with a hard-coded class name. There are no field labels displayed unless the administrator customizes the country format to include labels along with the tokens. It seems to me that if labels are to be changed, they should be changed by the administrator when setting up country formats. We don't want to change the class names as they are required by the hCard format.

Okay, this is checked in. Still wondering about the CCK but that's probably a different problem.

Thank you for your efforts!
Alexis

I'm adding this here in case someone's having as hard a time as I did just trying to simply change the name of a label in the cck addresses form field. My solution is as follows.

/**
 * Implementation of hook_form_FORM_ID_alter().
 */
function mymodulename_nodtype_node_form_alter(&$form, &$form_state) {
  $form['cck_address_field_name'][0]['#pre_render'] = array('_address_prerender_callback',);
}



/**
 * Callback for Address Element Pre Rendering
 * @param $element
 * @return the changed element.
 */
function jllask_address_prerender($element) {
  
  //Bad coding. We need to know too much about the specifics of the addresses field object.
  //But, the addresses module doesn't give us any options.  This could easily
  //Be handled by creating a pre-process hook that can be invoked with an array of
  //parameters to be changed.
  $element['city']['#title'] = 'Popcorn';
  return $element;
}

Hopefully this will save someone hours of research :(
And, hopefully in the the future there will a more sensible way of making this simple
modification to the generated form.