Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.
Hey Gordon! Haven't really thought about it yet, as I'd love to get to a 1.0 on D7 first... but I've been actively trying to clear out old issues to that end this past week. I'll keep ya posted and point other folks to this issue as well.
i’m currently trying to do a Drupal 8 port of this module. Now i’m stuck at the point where the form refreshes after the user changed the country. I always get the locality_block of the default country back instead of the locality_block for the selected country.
Maybe you can have a look in the code? Please give me a short response how i can transmit you the code which i’ve ported until now.
Well, for what it's worth, I can't really get behind any porting effort until we have a full release of this project. For example, right now I'm reviewing a patch that converts the module to define and use a new addressfield form element type in its field widget. After that, we need to address the need for configurable empty conditions (and the ability for the field to remain empty in general). Then I think I'd be ready to call it a full release, even without committing all the various regional changes.
Porting without at least those two or three big ticket items resolved seems premature to me. I applaud your efforts, though - if you've already resolved these things in the port, I'd be happy to review it.
These features are relatively new and had not been committed two weeks ago where we branched off. We have not introduced new features while porting. But clearly, if those features are included in 7.x-1.x version we are going to port them to Drupal 8.
I have an issue (created to keep track of all the patches are not in 8.x-1.x. I think it makes sense to add a tag to those issues or set them to "Patch (to be ported) and 8.x"
For Drupal 8 I have created the Address module.
Felt silly to keep the "field" suffix considering that other similar modules don't have it, and we now have an entity type, plugins, etc (it's not just a field anymore).
It is quickly gaining feature parity with addressfield. Just like Commerce 2.x, it requires composer_manager for installation (until we allow modules to be installed via Composer).
Comments
Comment #1
rszrama commentedHey Gordon! Haven't really thought about it yet, as I'd love to get to a 1.0 on D7 first... but I've been actively trying to clear out old issues to that end this past week. I'll keep ya posted and point other folks to this issue as well.
Comment #2
gordon commentedThanks, I am going to need this for a D8 project, and I may be able to put some time into this during December.
Look forward to seeing a D8 version.
Comment #3
MartiMcFlight commentedHi Ryan,
i’m currently trying to do a Drupal 8 port of this module. Now i’m stuck at the point where the form refreshes after the user changed the country. I always get the locality_block of the default country back instead of the locality_block for the selected country.
Maybe you can have a look in the code? Please give me a short response how i can transmit you the code which i’ve ported until now.
regards
Martin
Comment #4
webflo commentedHI, we have made good progress. Thanks to MartiMcFlight! I've just pushed the latest code in our sandbox. https://drupal.org/sandbox/webflo/2145945
Please start checking and testing.
@zszrama I would love to get your feedback. Especially on #2146041: Port addressfield formatter
Thanks!
Comment #5
rszrama commentedWell, for what it's worth, I can't really get behind any porting effort until we have a full release of this project. For example, right now I'm reviewing a patch that converts the module to define and use a new addressfield form element type in its field widget. After that, we need to address the need for configurable empty conditions (and the ability for the field to remain empty in general). Then I think I'd be ready to call it a full release, even without committing all the various regional changes.
Porting without at least those two or three big ticket items resolved seems premature to me. I applaud your efforts, though - if you've already resolved these things in the port, I'd be happy to review it.
Comment #6
webflo commentedThese features are relatively new and had not been committed two weeks ago where we branched off. We have not introduced new features while porting. But clearly, if those features are included in 7.x-1.x version we are going to port them to Drupal 8.
I have an issue (created to keep track of all the patches are not in 8.x-1.x. I think it makes sense to add a tag to those issues or set them to "Patch (to be ported) and 8.x"
#2146199: Missing patches in Addressfield Drupal 8
@Ryan: Are you ok with this process?
Comment #7
bojanz commentedOur D8 addressing plans are at https://drupalcommerce.org/blog/16864/commerce-2x-stories-addressing
The library itself is in good shape and Drupal integration is in progress.
This entirely new approach will power the 2.x branch, so I would say there is no need for a 1.x port.
Comment #8
bojanz commentedComment #9
webflo commentedI will maintain the 1.x branch on github https://github.com/webflo/addressfield until 2.x is public available.
Comment #10
bojanz commented@webflo
Thank you for your efforts.
Comment #11
bojanz commentedFor Drupal 8 I have created the Address module.
Felt silly to keep the "field" suffix considering that other similar modules don't have it, and we now have an entity type, plugins, etc (it's not just a field anymore).
It is quickly gaining feature parity with addressfield. Just like Commerce 2.x, it requires composer_manager for installation (until we allow modules to be installed via Composer).