Don't duplicate addressfield element prefixes or use non-breaking space prefixes for inline elements

Note that this would also fix issue #1224562: Theming Address Field form is difficult

Has this been committed to the current release?

Much better. Thanks.

Closed #1224562: Theming Address Field form is difficult and moving my 'follow' over here. Patch is definitely RTBC by me as well. This is quite annoying for those who want vertical alignment of the fields; there is literally no way to adjust spacing in CSS. (Maybe some really hackish ways using line heights and such, but that's just wrong.

How does this affect rendering of addresses? (ie. the formatting part?) The renderable array is used for both.

Updated patch against latest -dev release (old patch wasn't working).

It's for the form, and not the rendered address. For example, if I want to line up the form field elements vertically, strange gaps appear between city/state/zip (american... really locality, province, postal or whatever):

See my notes in #1224562: Theming Address Field form is difficult for more.

...and if I apply the patch, then those spaces are gone, meaning I can actually space the form elements myself using CSS - padding, margins, etc. Before, I'd have to adjust line heights in weird ways, or use negative margins to get fields to line up. And I'd have to do that on labels and fields.

Example after patch applied:

I've just run into this issue when styling the forms but it is not something a simple space character should cause so I looked into the code and found the prefixes were not actually using a normal space character but some other funky unicode character. The browsers try to deal with this as best they can and creates a   element which inherits all kinds of styling.

My guess is this is an accident by the author probably from pasting the text from somewhere else and the character not showing in the author's text editor. For example, gedit does not show the character (just white space) but kate does. If you simply delete the character and put in a correct unicode space it should work fine in the browsers (a normal whitespace should not influence block elements nor inherit style).

If you are curious what the character is you can see it mapped in Drupal in the file includes/unicode.entities.inc line 135.

The addressfield author may have done this for a deliberate reason though as it has been used for prefixes throughout (including the name field (name-full.inc) plugin). If so I would like to know the reason?

If this issue is causing you problems and you don't want to edit the modules code you can probably work around it in your theme using either a form alter and editing the prefix or possibly in a pre-process. I've not yet attempted this though.

Hope you find this info useful?

Sorry really short on time but the patch doesn't fix:

plugins/format/name-full.inc still an ascii something

Thanks, #10 works for me to remove the extra space within City - State - Zipcode, and the comma after city is a good change. Tested in an Omega subtheme.

This patch is missing some occurences, in actual version there are 4 non breakable whitespaces:
in plugins/format/address.inc: lines 61, 88 and 362
in plugins/format/name-full.inc: line 36
(the last one is missing)

#10 is mostly good, except this code at the end of address.inc This adds space to postal code that might not be entered in form making space before city in address. There should be check if data exists before inserting prefix.

Patch could be updated with checking not only if mode == render but also if field to be rendered before current field is not empty, this would remove spaces in beginning of address lines.

  if ($context['mode'] == 'render' && !empty($address['postal_code'])) {
    $format['locality_block']['locality']['#prefix'] = ' ';
  }

Great Patch, helped a lot and made the form so pretty! :-)

Are their plans on rolling this into the next release?

Any chance we can get this committed and create a followup task for mansspams concerns in #16?

I'm utilizing #10 and it works wonderfully.

Ack, yes, can we have this committed please?

I can also confirm that #10 solves the extra whitespace issue.

#10 also fixed the issue for me

A word from the module maintainers at this point might be good. About to go live with the patched version here.

What, if anything, is this waiting on? Do we need to roll another patch to address #11/15/16, or can we handle those in a followup?

Works as advertised :)

#23 Works great for me. Just need to update the space prefix in plugins/format/name-full.inc to fix name form when using separate first and last name fields. Thanks!

@andyg5000 can you elaborate? is there something else that is needed for this patch to be commited?

Are the spaces (nbsp;'s) going to be removed after the first name, city and state? Spacing should not be included here. It makes for very inflexible styling of an address. Spacing such as this can be accomplished with CSS, and shouldn't be hard coded.

Status regarding this?

I've had to use this on the past two projects. Please commit :) R&TBTC

#28 works for me =)

For example, you can use custom module and hook_form_alter().

function tools_form_commerce_checkout_form_checkout_alter(&$form, &$form_state, $form_id) {
  unset($form['customer_profile_billing']['commerce_customer_address']['und'][0]['locality_block']['locality']['#prefix']);
  unset($form['customer_profile_billing']['commerce_customer_address']['und'][0]['locality_block']['administrative_area']['#prefix']);
}

As stated in #9 it isn't a space.

Marked these issues as (possible) duplicates:
#1945600: #field_prefix/#prefix behavior broken, inconsistent with #field_suffix/#suffix in rendered addresses
#1410612: Double #prefix problem
#1482802: Prefix Duplication in plugin

Also: this issue started as a 'space' issue, and #10 introduced the 'prefix' issues, which is already treated in the above issues.
Are we sure we aren't discussing 2 different issues?

I started #1945600: #field_prefix/#prefix behavior broken, inconsistent with #field_suffix/#suffix in rendered addresses after encountering the prefix issue which #28 will fix. Would love to see this patch make it into the project. What's the current hold-up? I don't see one on this issue since #28 was posted… I'd be glad to help tackle it.

Committed #28. I like how this one got sent back to RTBC after being reverted to needs work without the extra work being addressed. : P

In any event, sorry it took so long, and kudos to fearlsgroove for sticking with it long enough to get us to a good patch. Thanks to folks for reviewing and posting the success, too. : )

Commit: http://drupalcode.org/project/addressfield.git/commitdiff/bc78ab0

If you want to remove the inline class without touching the styling:

function YOURMODULE_form_commerce_checkout_form_checkout_alter(&$form, &$form_state, $form_id) {
  $ele =& $form['customer_profile_billing']['commerce_customer_address']['und'][0];
  unset($ele['name_block']['#attributes']['class'][0]);
  unset($ele['locality_block']['#attributes']['class'][0]);

  // Remove the   (don't use if you're using a version later than bc78ab0)
  unset($ele['name_block']['last_name']['#prefix']);
  unset($ele['locality_block']['locality']['#prefix']);
  unset($ele['locality_block']['administrative_area']['#prefix']);
  unset($ele['locality_block']['postal_code']['#prefix']);
}