Separate Components of Address field

This would be a nice addition. Currently I am hacking the code to remove the name field.

Absolutely +1

This module only does one thing, but does it correctly: store international postal addresses.

Ryan,
Are you using this http://drupal.org/project/name module?

+1.

Attached is a patch that adds that option and updates the preprocess and templates. The maintainer may have a more elegant way to deal with the first_name / last_name but this is here for what it is worth.

(first git patch on d.o.!)

#6 works for me.

I was working with this mod several months ago and ended up switching to Location in large part because of this particular issue. There are numerous instances where address fields are needed but there is no need for a name field that is attached to the address in this way. It can make for an awkward node form, for one thing, by forcing a layout that's not necessarily appropriate.

There are two small problems.

1) patch leaves addressfield-formatter.tpl.php untouched. Shouldn't it modify default template too?
2) leaving name field empty template inserts BR tag before address

Was working with this today and did a small patch similar to above that just changes the addressfield.module - however, it adds the last missing option. So now we have the range Full Name, First and Last, Name and Company, Just Company, Nothing.

Didn't touch the .tpl, will try and submit an additional patch for that. If one of the maintainers indicates if this is something they are interested in and it makes sense to work more on it will add that later on.

+1 for this. I echo the sentiments in comment #2.

#10 seems to be working for me. Thanks.

What about hiding these?

Postal code
Neighborhood
Complement
Number
Address

Is this out of the scope of this module? In my case, I just need the city. The country will always be the same, and so will the State.

+1 for no name field

I'm going to give that patch a try in the mean time.

+1 / Subscribe - Location module had almost too much customization for location fields, but at least I could hide fields I absolutely didn't need... :)

Patch in #10 needs review.

Works for me

Quick question....If there is an option to disable the name field won't that mess around with the the needs of the commerce module which requires this module?

I think a possible alternative would be for this module to be patched to support tokens for default values so that if we already have a first name, last name, etc field that it pulls the data in but the user can still change it.

I need this as well. Ryan if you could give us a little direction on the route youd like to take as maintainer: required token support (if necessary) or something similar to the patch in #10. One of us will happily patch this up for your review.

I got around this by just modifying the template file and removing the line break logic.

This allowed me to hook_form_alter the form to remove the Name field to the user and still display it properly. I had to alter it anyway to adjust some labels.

I love the module, thank you for sharing!

@rump: while this addresses display it ignores the form collection issues which still have to be FAPi'd out of there too.

Closed duplicate: #1181618: Optional Full Name.

Echoing #12 - is hiding other field components, or adjusting granularity of what is collected, out of scope of this module?

I'd love to be able to limit what can be stored with this field, especially postal code, etc. I just need city, state/province & country on the sites I'd use addressfield on. I'll form_alter it if possible (is anyone doing this?), but adding the ability to specify what to collect to the field settings seems useful. I know that's getting into location module territory but I think it's useful enough to consider :)

I'll form_alter it if possible (is anyone doing this?)

Yeah, I've just been altering it. I set a default value for country and let the others just stay empty.

function mymodule_form_formid_alter(&$form, &$form_state, $form_id) {
  $elements = $form['field_address']['und'][0];

  // Hide.
  $elements['#type'] = 'container';
  $elements['country']['#type'] = 'hidden';
  $elements['name_line']['#access'] = FALSE;

  // Change.
  $elements['thoroughfare']['#title'] = t('Address 1');
  $elements['premise']['#title'] = t('Address 2');

  $form['field_address']['und'][0] = $elements;
}

Then I also hijacked the template file to modify its output:

function mymodule_theme_registry_alter(&$theme_registry) {
  $theme_registry['addressfield_formatter__US']['path'] = drupal_get_path('module', 'mymodule');
}

Awesome. Thanks for this.

Damien, what direction do you want to take with this? I can spend some effort on this if you let me know how you want it completed.

I think minimally we should patch the templates with conditionals so if a user doesn't input a field (name for example), there wont be broken line breaks when viewing the node.

Please advise,

Potential solution #983240: Suggested modification to addressfield-formatter.tpl.php.

sub

The -reloaded branch has been merged. The name and organisation fields are now completely optional.

Damien, what about the other fields? What if I just want to collect the state, and leave the Country with a fixed value?

In that case, use a Text Field or a drop-down. So why you need this module, if you want to collect only states?

So I'm able to integrate it with OpenLayers using this module features.

same here, just want to collect city, state, zip, country and skip the address fields

@mototribe another option for you might be to use http://drupal.org/project/field_collection to build fields for the City, State, ZIP, and Country. You could also use CSS to hide the address fields.

Will be great if components of address also become optional.

Couldn't create a patch with additional files, so attaching the module.
When i tried to create a patch by reading http://drupal.org/node/1054616
$ rebase origin/7.x.1.x

fatal: Needed a single revision
invalid upstream origin/7.x.1.x

Separated the main address-form(country-specific) into :

• Postal Code
• Address 1
• Address 2
• Address Form (country-specific)

@webankit,

The remote is 7.x-1.x not 7.x.1.x.

Thanks @rump
Created a patch for separate address-form components:

• Postal Code
• Address 1
• Address 2
• Address Form (country-specific)
• Organization
• Name

Will this be added into core?

It just alters the form, not the database table... I think you can safely use this.

#37 does not apply cleanly to the latest dev.

I agree that this module should behave more like Name Field and provide ways for people to create customized "presets" for both the edit form and display:

The changes should be touching only the UI - the db should should be left alone so we keep the main purpose of this module intact:

This module only does one thing, but does it correctly: store international postal addresses.

If people think this is way too much overhead, this can live as a submodule ("address_fields_manager" ??) or even in contrib if the maintainers choose to not support this.

PS: if this did get accepted, some issues could be removed from the queue as duplicates:

#1316788: Do not display country in address block if only one country option is available
#1337656: Use only one address field
#1368532: Remove address1 and address2 only use country, city, state, and zip
...more???

Is there a way to render an address like:

Street
City, State, Zip

I looked at the addressfield example module, but wasn't sure if what I was looking at was the way to do it.

@KevinQuillen, yes, its possible, using field_view_field() and passing in some display settings, but its tricky. Gotta dig up some code from a prior project if I can remember where it is.

Anyone got the patch in #37 working on the latest dev?

What about we split up address data in different groups/layers (by specificity), say country > administrative area(s) > city > address > adressee (although there's a discussion to remove addressee support from this module). If layer has a default value, and so does its preceding less specific layers, its form element can be made optional or disabled. Example:
* If the country is set, it can be made optional.
* To disable the city field, the country, administrative area and the city fields need default values.

This approach ensures every stored address is usable and should exist in the real world, because even if some fields are optional, we enforce default values. We do however allow some fields to be be targeted at residents of a specific city or neighborhood, by allowing fields to be optional or hidden.

The separation in layers also allows other modules to easily use and configure address fields, even if the services they use do not know how to handle all kinds of international fields. A Dutch or Belgian service may offer international address processing, but it may not support a specific state field, simply because those countries don't have states and the service's makers never thought of how handle those for other countries. Layers allow such modules and services to tell an address field how specific an address they want, without having to know about all the little details.

Format handlers can be rewritten as well, because the addressee is one layer of specificity and whether it's an organization's or a person's name (or both), doesn't matter from an API point of view. We can rewrite form handlers as a list of layers with optional default values that can be made optional or disabled.

What if I just want to collect the state, and leave the Country with a fixed value?

That's exactly my use case.

This approach ensures every stored address is usable

This validation doesn't currently exist. It's already possible for users to create address field instances with only a country value, a country and city with no state, etc. Giving administrators the ability to remove fields that can already be left empty doesn't seem to introduce any new complications for modules using those fields, since those modules already need to confirm fields contain the expected data.

Additional validation might be useful, but I think it can and should be addressed as a separate issue.

I've been using #34 version, and it works. Have not tried #37 since it appears not to be working.

What are the next steps for moving this forward?

Hello,
I have downloaded your attachment addressfield.zip . It works well.
But in Germany, the postal code before the city are (e.g. 74072 Heilbronn). What can I do to ensure that the postal code comes first and then the location.

Thanks for your answer.

regards

Fred

Thanks to rump's post, I was able to unrequire and remove the "Address 1" and "Address 2" fields from the form. Here's my example:

/**
 * This removes both the "Address 1" and "Address 2" fields and
 * makes the "Address 1" field unrequired even though 
 * the entire Addressfield is set to required.
 */
function mymodule_form_formid_alter(&$form, &$form_state, $form_id) {

  // Change "field_address" to match your field's machine name.
  $elements = $form['field_address']['und'][0];
	
  // Don't require the "Address 1" field.
  $elements['street_block']['thoroughfare']['#required'] = false;
  
  // Hide the "Address 1" field.
  $elements['street_block']['thoroughfare']['#access'] = false;
	
  // Don't show the "Address 2" field.
  $elements['street_block']['premise']['#access'] = false;
  
  // Change "field_address" to match your field's machine name.
  $form['field_address']['und'][0] = $elements;
  
}

I assume that with "Separate Components of Address field" functionality will come also functionality for views fields that every address field will be available as view field. No I can use only whole address field in views fields.

I need display just one field country and in another field only city. I do not need address line or ZIP.

I'm actually not sure why this issue is still alive. The original post was from the early alpha days requesting functionality that got included in the beta rewrite. It's now fully possible to have an address field that does not request any name information at all - you simply uncheck the name line handler in the field settings. It looks to me like the original request got abstracted out to make any part of the address optional, and that's the gist of the 2.x roadmap in #1829900: [meta] Address Field 2.x needs pluggable administrative areas and an actual API. I'm going to mark this a duplicate of that and link to the patch in #37 from there. It won't apply any longer and is probably not the direction we'd go, but linking it in will preserve the discussion that's taken place if necessary.