Reopen and reassign Countries project

the other project didn't have any code, so I unpublished it.

Two requests:

1) Assess if there is room in DO for a simple generic Countries widget for Drupal 7+

My personal reason for this was:

We've used one of these on about 20% of the projects that we have developed, and on half of these, one of the more complex regional modules were used, and on the other half, a custom FAPI select element was used. From Drupal 7, most of these will require Country widgets instead, which is no longer just a simple 5 line idiom that an average programmer could do in their sleep.

2) It is possible to reactivate this project and have ownership transferred to myself?

After deciding yes to #1 myself, I checked CVS for a namespace conflict and programmed up a module to do this. It was only after committing that I discovered the dead project conflict.

I do not know what the original module attempted to do. My new version provides four country related tasks / goals.

• A countries database with an administrative interface.
• A way to alter Drupals core country list via hook_countries_alter().
• A country FAPI element.
• A countries field.

The only outstanding thing is i18n, but way too early to consider starting this as i18n port is not yet started.

Full details and a partial module comparison (the comparison is a bit rough) can be found in the projects readme.

http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/countries/R...

The module should be functional against HEAD.

Thanks

@Alan D.: You are not the maintainer of the project anymore (and you don't have access to the project CVS too); why should the ownership be transferred to you?

@Alan D: sounds like your widget would make a great feature request for the countries_api module. I'm unclear why you consider it was not a good idea.

@KiamLaLuno - I never was. The namespace was free on CVS and I committed there thinking that it was free. It was not. The original maintainer never committed to CVS so there were no locks in place from preventing my commit. Look at the $Id$ headers

$Id: README.txt,v 1.2 2009/10/11 08:12:09 aland Exp $

@Damien - The purpose of the countries_api is to convert between the various codes. To quote from the countries api project page

This is a utility module for converting country code data from one format to another.

I think that the main use of the countries api is a duplicate, like its usage with country flags, etc. As soon as the data is editable, the countries api core functionality would be void. Many lookups are name > iso2.

The main purpose of mine would be to provide an editable countries database, with the additional widgets, and the control of the internal countries list. The main reason that I made the names editable here to prevent crazy long country names upsetting many themes, like "Congo, the Democratic Republic of the" when I prefer the Drupal 7 "Congo (Kinshasa)" naming.

I'm hoping that more developers use the core internal system, as at least 10 modules provide an internal countries database, something that can be replaced using:

<?php
  include_once DRUPAL_ROOT . '/includes/locale.inc';
  $countries = country_get_list();
?>

Personally I don't really care one way or the other what happens, the community can decide if this is worth it. Trying to take ownership of this abandoned one forces the question into the community, which is a good thing IMHO. A stronger argument was put forward here, #597748: Integration with new core Drupal 7 features & simple field elements? but I think that I may have pushed to hard.

It is a useful module that we be using a lot internally, I just thought that I would share ;)

@Alan D.: as you describe it yourself, there are two parts in the code you have been working on:

- an UI around D7 countries list: the country list and the UI deprecates most of what Countries API is doing right now. That means that your UI could fit perfectly in a refactored Countries API for Drupal 7
- a D7 field and widget for a country. This could be a great addition to the Countries API (as a feature request). The idea could probably be backported to D6 as a CCK field, as (at least from your list) no such thing exists in Drupal 6 yet.

In a nutshell: (1) there is no need for two overlapping countries module for Drupal 7 and (2) Countries API will need a upgrade path anyway. Please collaborate with the maintainer of Countries API.

I contacted them directly, but I have had no response.

I don't really have the time to much around with this that much, and I do not want to install 3 or 4 modules to do what this does. Too many modules is such a performance drag. I'm closing this ticket and leave it to them to consider implementing these features. There will be an issue if there is an interface for the countries api; using the core functionality to map countries with external APIs, as per the reason for the countries_api, will mean that users either break the relationships with these external services or that they are forced to maintain the unwanted existing names.

If anyone is interested, we will be running with this internally and I'll try to remember to keep the CVS up to date even though there will be no project.

Thanks to everyone that took the time to give feedback.

We don't close the issue reports; then I would leave the task to change status (it could be marked as won't fix) to a webmaster.

Hi Tom

This would be a significant shift in the way that the countries api works, but it would also open up a large potential user base. At our work we would use a single country element about 10% of the time, which scaled up would translate to a potential usage of 20,000 based on the current Drupal stats. This is likely to increase if profiles become fieldable.

The module that I wrote is about 3 times larger (ignoring regions and services) and only has two getters for country data, get_country(iso2) & get_countries(iso2, return_property). Everything is based on iso2, as everything else is editable. If you are interested, I can look at back porting this to Drupal 6. After some free time over the last couple of weeks, things have gotten crazy at work, so this would be at least a couple of weeks away.

Also with these additional features, it would not just be an API anymore, maybe you could ask for the country namespace ownership if you run with this. This would provide a great way to isolate and develop without risking the current project

Also, I forgot to mention this and didn't get time to create a patch, but the ISO data should be complete in countries.csv file in cvs. (For the iso3 / num3 codes). Have you ever checked the legality of maintaining a database of these extended codes? These are so common on the web but they are not publicly available from the ISO site.

Right, must get onto some work. Major release on Wednesday...

Cheers Alan

Sadly, I am not going to have the time to port this backwards to D6, but feel free to use any bits you want. It would be a damn shame if none of these features get into the community!

I just done a very rough back port to Drupal 6. It contains a lot of the Drupal 7 code simply commented out with the corresponding Drupal 6 code added. Since the d.o countries namespace is a unpublished project, I can not branch from the HEAD version in CVS and I do not want to commit over with the back-ported code, so attaching the D6 zip of it here. It has had very limited testing.

For D7, I think making this fieldable would be the way forward. If I get time, I'll do this against HEAD. I've just done a couple user based fieldable objects and it's not too hard. I've got a project to push out in about 2 months and it is 50-50 call on going to D6 or D7. Loving D7 (except for the overlay module) but too unstable atm. Each update between CVS versions is creating bugs that are unique to that upgrade path.

Are you still interested in combining any of the features? I would fully recommend creating a major version change if you do as the overlap is minimal, just like the amount of testing done with the D6 version & D7 version hasn't been updated in 3 months.

What happened to this cool idea. It sounds good, thank you for sharing with us.

@mrfelton: I see your project hasn't been updated in 20 weeks. Did you decide you're not open to collaboration with him? Are there any plans to reconsider?

@Alan, have you implemented your idea elsewhere. Can you please consider sharing it as a vendor branch outside of drupal.org for those of us interested in it, or as an entirely different module. I see how it's beneficial and would like to see it being maintained somewhere for us to use.

There was an offer to merge, but the API was completely different and I gave up with the negative feedback. The attached zips were as far as I got, feel free to continue the cause as it is a bit hard for me to do this from internet cafes in Mexico. :)

Get ready for an abrupt closing of this issue by the powers above.....

@Alan, No worries, I got the zip. Thank you for that ;)

Get ready for an abrupt closing of this issue by the powers above.....

It was you who actually closed this issue report on comment #8. I don't think site maintainers abruptly close issues, nor do they close an issue without a reason.
The fact there are two different issue reports for the same project that have been opened from different users shows there is no consensus on what to do.

The issue was two very different modules that had no overlap and neither party having the time to do anything to merge. Happy to help look after my version, but I have limited time as I'm traveling through Central and South America for the next 8 months.

Sorry kiamlaluno - i didn't mean any offense! I was simply referring to the deadlock.

The CVS version is updated to alpha 7, but the field formatter AJAX is broken, so I couldn't test this. Also fixed some file encoding issues with the csv import files.

http://drupalcode.org/viewvc/drupal/contributions/modules/countries/

It was a rainy day, so I extended it so that the countries now belong to a bundle and they can have additional fields attached to each country. This is a bit of a performance hit, so this may need refactoring.

The iso2 is no longer the primary key as an integer key is required to attach fields to a bundle. (Although the code hasn't changed much)

No upgrade path, the module must be uninstalled and reinstalled.

The status of this code is at the late alpha stage or early beta stage.

I'm still getting regular requests about this, two requests in the last two weeks, so it would be great to get a final call on it.

I'm on the road for at least another 6 months, so I have no time to merge, but I would probably have time to maintain this version.

A brief overview of the api overlap of countries_api / countries.

This includes all countries_api functions and about 5% of the countries functions.

Getting a countries array or property
------------------------------------------------
COUNTRIES_API
function countries_api_get_country($code)
function countries_api_iso2_get_country($code)
function countries_api_iso3_get_country($code)
function countries_api_get_name($code)
function countries_api_iso2_get_name($code)
function countries_api_iso3_get_name($code)
function countries_api_iso2_get_iso3($code)
function countries_api_iso3_get_iso2($code)
function _countries_api_iso_get_country($value, $format)
function countries_api_get_list()
function countries_api_get_array($key_format='iso2', $value_format='printable_name')
function countries_api_get_options_array($first_element = array('' => 'Please Choose'))

COUNTRIES
function countries_get_country($iso2, $property = 'all')
function countries_get_countries($property = 'all')

Personally I do not like the proliferation of these helper functions that make up 75% of the functions defined by the countries_api

Misc
-----
COUNTRIES_API
function countries_api_help($path, $arg)

No UI functionality is provided, so why is there a help hook?

Formats
----------
COUNTRIES_API
function countries_api_get_formats()
function countries_api_validate_format($format)

COUNTRIES
No comparative functionality.
Using field formatters or just check_plain($country->XXX). The only property that I considered complicated enough for this was iso3 number code, for which the formatter is theme_countries_number() to ensure that the int value is converted to a 0 padded string.

Installation type functions
---------------------------
COUNTRIES_API
function countries_api_csv_import_countries($offset=1)
function _countries_api_flush()

COUNTRIES
A similar import, but no _countries_api_flush() as dealing with user data! A revert function could be useful for individual records.

So if I took over and converted this to Drupal 7, I would want to drop 80% of the module and then be lumped with supporting the other functionality that I have no interest in. Thus maybe it is best for a clean start, new module, new api.

Seeing as how D7 is in RC it would be really nice to get this resolved. I've tested out the countries module and found it to be a fantastic module with very little overlap with countries_api. This is especially true considering that core now includes countries data. What is left are some helper functions and services integration. How about this as a way forward:

1) countries project is re-activated with Alan D. and mrfelton as co-maintainers.
2) countries_api is dropped for D7 onwards.
3) As time allows what is left from countries_api is merged into countries and a migration path is provided.

Aside from the issue of maintainership and history, "countries" makes more sense considering that a combined module would no longer be just an API. It also makes sense considering that a D7 version is now available and that D7 is the obvious way forward for all future development.

Thoughts? @Alan D. and @mrfelton?

Sounds like an easy upgrade. Personally I would assign mrfelton as the project owner, due to his history with this area, so he still has primary credit (if he still wants it).

As for an upgrade, any module (for the countries side of things), would just switch to Drupal cores' API or make this a dependency and add the required fields to the bundle if required.

Eg: To move Countries flags across, steps would be to add an image field to the countries bundle and to prepopulate this with the icons (maybe 1 image field per map icon set, allowing multiple sets). I think that the formatters would peculate through to the end field that uses the country field. This would automatically provide the ability to add a country flag to any bundle - node, user, term, etc, by simply using a country field to the bundle.

Unless the module adds an attribute to the country data, there is no reason to add a dependency to any module for country data.

I guess one question still remains, is the newer version doing to much? Thoughts?

@Alan - I didn't find that the module did too much but maybe that's just my taste. I could certainly see the need to split into multiple modules should services support and other functionality be added. The closest parallel I can think of is how date module has grown to provide a whole suite of date related modules.

One more point in favor of this module is the detailed and helpful README that compares the many modules in this space. The author certainly looked at the landscape and decided that these was no other module doing what countries does. See http://drupalcode.org/viewvc/drupal/contributions/modules/countries/READ....

Pinging.

I'm going to be using this for a personal project, and will be creating a number of useful sub-modules. Neither maintainers have time to merge, and there has been no commits to Country codes API for 42 weeks. All that would be required for a D7 country module is for this project to be published and ownership transferred.

I really think that Countries should be re-instated. It is a well made helpful module that has functionality that no other similar module has for D7. There isn't much duplication with Countries API really. As for CCK Country, this was created well after Countries came on the scene. There are much worse situations of duplication on d.o. so I don't see why this module has been singled out. I also see that everyone involved here is open to working together and potentially consolidation. Let's let this project carry on and evolve for the time being. Consolidation can happen at a future date.

Can everyone agree on this? I'd like to set this to RTBC so action can be taken.

@mrfelton An emphatic YES to all of the above! As for groups.drupal.org what about posting the conversation in http://groups.drupal.org/location-and-mapping? It is in the same problem space.

I've re-published the project. Assuming since Alan D. already has commit access I don't need to do anything else - but if so please update here. Not closing this as fixed since I'm not sure if it is yet.

It looks like the Countries module description doesn't reflect the module itself. I've added an issue to resolve this: #1053550: Update project node to reflect the actual countries module. Hopefully Alan D. has permission to manage the project node.

I passed the ownership of the project to Alan D.

Thanks all. Nice to get this resolved! I've released a dev version.

@mrfelton interested in co-maintaining?

@Tom - I've added you with full permissions.

All of us countries people should properly get together and try and sort out this mess of duplication. Perhaps we should think about creating a group on groups.drupal.org?

Hopefully this shouldn't be needed. With the conversation with Christoffer in #1055236: Drupal 7 version (and duplicate project issue), I will not publish the Drupal 6 version at all and for the time being, he will not port to Drupal 7. Both modules use iso2 codes for storage, so an upgrade path shouldn't be too hard.