Support an alternate street address field ordering for UK addresses

I'm not sure I see anything to be done here. The address fields as given aren't meant to be separated out as you've described. In xNAL the thoroughfare is designed to contain both the street number and name, and the premise is essentially a more specific address indicator that sits beneath the thoroughfare (i.e. apartment number, suite, P.O. box, etc.). We title the premise "Address 2" on the address form, but you can hide that label or disable that form element via hook_form_alter() entirely if you want - it's never required. Unless you actually need to subdivide a city, using the locality for village would work just fine.

If all you really wanted was to separate out the thoroughfare into street number / name, that would be out of scope for this module. We don't have a way to store that data separately anyways, so it would just be taking the two separate fields and combining them together into the single thoroughfare column in the database.

Sure, reordering fields is fine and dandy. It just sounded like you wanted to subdivide a column in a way that we wouldn't be able to support due to our field schema. fwiw, there are a lot of users in the UK, and no one has reported the ordering to be an issue. Maybe they're all just dealing with bad data, who knows? But it's going to be hard to establish a consensus one way or the other.

I'm going to try for a better issue title here, but really we might just need to close this out in favor of j0rd's meta solution in #1829900: [meta] Address Field 2.x needs pluggable administrative areas and an actual API, which was intended to tackle issues like yours. Maybe I'll just mark this postponed pending on that one.

I think the example in the Schema seems to adequately describe the normally expected order of the address for the UK; in place of house name you also have similar things for Flat 123 at a street address:-

<!--
 Mr. John W. Smith
       Russell House
       4395 Station Road
       Porchester
       FAREHAM
       PO16 8BQ
       UNITED KINGDOM
  
-->

I find it interesting that Thoroughfare itself can be split up by the way.

<Record>
 <xNL xmlns="urn:oasis:names:tc:ciq:xsdschema:xNL:2.0">
  <NameDetails PartyType="Person">
   <PersonName>
    <Title>Mr</Title>
    <FirstName NameType="GivenName">John</FirstName>
    <MiddleName Type="Initial">W</MiddleName>
    <LastName NameType="SurName">Smith</LastName>
   </PersonName>
  </NameDetails>
 </xNL>
 <xAL xmlns="urn:oasis:names:tc:ciq:xsdschema:xAL:2.0">
  <AddressDetails>
   <Country>
    <CountryNameCode Scheme="ISO 3166-1">DE</CountryNameCode>
    <CountryName>UNITED KINGDOM</CountryName>
    <Locality Type="Proximate Town">
     <LocalityName>FAREHAM</LocalityName>
     <DependentLocality Type="Town">
      <DependentLocalityName>Porchester</DependentLocalityName>
      <Thoroughfare>
       <ThoroughfareNumber>11</ThoroughfareNumber>
       <ThoroughfareName>Zypressenweg</ThoroughfareName>
       <Premise Type="Building">
        <PremiseName>Russell House</PremiseName>
       </Premise>
      </Thoroughfare>
     </DependentLocality>
     <PostalCode>
      <PostalCodeNumber>PO16 8BQ</PostalCodeNumber>
     </PostalCode>
    </Locality>
   </Country>
  </AddressDetails>
 </xAL>
</Record>

So if that's not obvious sorry.
Premise does make sense for the UK.
It is required to be available for some addresses (flats and the like).
But it is a field that is only relevant to those and a few other addresses.
It is always placed before the thoroughfare line in human presentation.

And to say it in code

Oh! And to make it worse. I noticed while looking up the correct wording to use that the UK addressfield has: Town/City (locality) and County (administrative area). This is out of date, the County is no longer required - well, for the Post Office at least. However they do sometimes need the subdivision on the town:- British English 'Post town' (or Locality - xNAL) is always required, and occasionally the, in British English, 'Locality' (the neighbourhood or district within a Post Town) (DependentLocality in xNAL) is also 'required'.

As I see you could create new formatter as I did for Estonia https://www.drupal.org/project/addressfield_estonia

The county is no longer required by addressfield.
The used and required fields are now a part of the address format and can be altered by hook_addressfield_address_formats_alter();

The ordering of fields on the form is not controlled by the format currently, it will probably need to wait for 2.x
I don't see any other actionable points in this issue.

I also found that this order is wrong for UK.

FYI the geocoder module in geocoder_widget_parse_addressfield creates a string from an address field like this (for all countries):
premise,
thoroughfare,
locality,
administrative_area,
sub_administrative_area, [seems like it should be before administrative_area but that probably doesn't matter as the addressfield project page says that this field is unused]
country,
postal_code,

The code is independent of country and so potentially decreases geocoding accuracy for almost all countries - the order displayed to the user and the order used in geocoding are different. UK users might end up with geocoding being done on a string containing the village followed the street.

This issue says

Support an alternate ordering

@bojanz says

The ordering of fields on the form is not controlled by the format currently, it will probably need to wait for 2.x

So closed (fixed) does not seem correct, and previous value of postponed seems more accurate. Or if you are going to close it, it seems like it should be closed (won't fix).

Fixed works for me, as the library for 2.x is already completed and supports the most current UK format. But we can't won't fix it as well since this is related to 1.x.

@rszrama Thanks for the update, and sorry if I am meddling unhelpfully with your issue settings. So it sounds like the accurate status is "fixed in version 2.x-dev", but the version field for that release has not yet been created. Maybe the working v2 release is in a private development environment.

The library is managed separately at https://github.com/commerceguys/addressing, and the next version of the module will be at https://www.drupal.org/project/address.

@rszrama Thanks for the extra info. I think other users of the module might be interested in these links too - maybe you could consider adding them to the project page? It looks like address is D8 only. Possibly address_field will not exist in D8? In which case hopefully there would be an automatic migration.

For anyone else who would like a D7 fix via hooks, here is what I used:

function HOOK_field_widget_addressfield_standard_form_alter(&$element, &$form_state, $context) {
  $element['street_block']['thoroughfare']['#title'] = 'Street';
  $element['street_block']['premise']['#access'] = FALSE;
}

You could reorder the fields in your hook, but then don't forget you would need to reorder them in the formatter too. If you already have some nodes with data for the premise field, then you need to remove that before adding the hook.