This issue is about the D8/D9 port for Countries module. The current version is only available as an attached patch in this issue.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Alan D.’s picture

Title: API Change in D8 » Drupal 8 port

I think that this may be 1 or 2 years premature, but thanks for the heads up on this

Alan D.’s picture

The oldest issue in the queue ;)

Important change to how Drupal 8 handles countries.

#2004506: Move standard_country_list() to Drupal\Core\Locale\Country
country_get_list() has been converted to a swappable service

Alan D.’s picture

There is a fairly big i18n patch in the 7.x-2.x queue that I am waiting on review, but rather than waiting on this, I'm pushing ahead.

Created a new 8.x-1.x branch with the following applied.

#2032835: [META] Finialise i18n issues, patch from comment #16
#1830198: Better support for various providers of Country data., patch #2 from comment #8
#2041263: Views handler views_handler_filter_countries_continents_list is redundant., patch from initial issue post

Snapshot before the update can be seen here, the tagged 8.x-1.x-pre-update (commit 3e98153):

http://drupalcode.org/project/countries.git/shortlog/refs/tags/8.x-1.x-p...

bojanz’s picture

Issue summary: View changes

It would make a ton of sense to pull in the https://github.com/commerceguys/intl library via Composer for the 8.x port.

This would give you all CLDR countries (same source that Drupal 8 uses), as well as all translations, allowing you to automatically create
translations for the active languages / create translations when a new language has been added.

(assuming that countries will be configuration entitites)

Alan D.’s picture

@bojanz
First assessment was that there was little to gain. The import that has been implemented (7.x dev) allows any source.

Really I think that parts are going to be really hard to push from 7.x to 8.x.

Sun pushed hard for configurable entities, then due to other reasons, I think these lost the ability to be fieldable. Vocabs, countries, languages all fall in this group now (disclaimer, got too busy to track D8 changes from about 1 or 2 years ago)

So maybe Countries module should become a simple wrapper module, to integrate external sources with the core countries list, and providing a simple Name based options list as a field.

Provides the API for core CRUD events
Provide the base table schema for the country entity with simple UI

New modules
* Country Entity (hardest task)
* Country Sources (cdlr, iso, others?)

Drop country configuration, country i18n, country example

The first bit would become a critical task, to try and get other core D8 modules using it, but we have probably already missed that boat.

bojanz’s picture

You consider having translations for all languages as "little to gain"?
Having the module import translations when I add a new language, without forcing me to translate each country manually would be a major reason for people to use the module. Only CLDR/ICU gives that. ISO doesn't (and everybody hates their country naming anyway).

Alan D.’s picture

translations for all languages as "little to gain"?

Country Sources would be the import engine. The alpha code floating around for 7.x handles i18n imports nicely, the existing i18n depends on i18n module.

The plans would be to define the full list of countries as per the ISO standard within the module, and having short, long and nationality parsable for i18n; t(SHORT), t(LONG), t(NATIONALITY) and just to integrate the code with cores i18n handling. Then to supply the cldr as the second source defined that can pull in content from there.

matsbla’s picture

I think to have a Country Sources module that give you correct country lists according to either ISO or CLDR would be very handy, especially now as core ships with two country codes not used by either CLDR or ISO: Netherlands Antilles (AN) and Outlying Oceania (QO).

id.tarzanych’s picture

Please check my view of Drupal 8 version of Countries module.

Country entities were moved to Country config entities.
Also I added Continent manager, moved entity validation checks to \Drupal\countries\Entity\Country class, moved countries_get_countries() and countries_filter() methods to entity storage class.

To be done:

  • Port tests
  • Port countries_import and countries_configuration submodules
  • Integrate Countries with Feeds and Devel
  • Investigate possibility of integration with CTools
  • Investigate possibility of integration with Views
id.tarzanych’s picture

Status: Active » Needs review

Created GitHub repo to make code review easier: https://github.com/id-tarzanych/countries

Alan D.’s picture

@id.tarzanych
I'm probably at least a year off from needing this upgraded myself, but happy to add you as a maintainer if you are interested.

id.tarzanych’s picture

@Alan D.

Thanks, I am really interested in that.
By the way, what do you think about logic based on Country config entities here?

id.tarzanych’s picture

Added code protection.

Status: Needs review » Needs work

The last submitted patch, 13: 1277356-countries-drupal-8-port-13.patch, failed testing.

id.tarzanych’s picture

Removed obsolete line

Status: Needs review » Needs work

The last submitted patch, 15: 1277356-countries-drupal-8-port-14.patch, failed testing.

id.tarzanych’s picture

Status: Needs work » Needs review
Alan D.’s picture

There are a few use cases for the module, one is for fieldable entities, which config entities would rule out.

In saying that, this reduces the complexity, and easy workaround by defining a reference field on a node or a contextual filters on views

That's a +1 from me to make this decision

You should have full access to things,

Many thanks :)

Alan D.’s picture

Oh, and I would just ditch Countries configuration & example sub-modules, i18n shouldn't be needed

bojanz’s picture

Your architecture means importing 250 config entities at module install time, and loading 250 config entities every time you want to display a country list. That's going to end badly. You'll at least need a cache layer to mitigate issue issue #2, while praying for the best on issue #1.

You will also need to think about config updates. After the module is installed, the country objects are now owned by the user. That means you'll need to write update hooks each time a country changes (thankfully, that's not too often), while deciding what to do with the user's changes (detect if the entity was changed post-install, and either proceed with the update, or skip the entity).

I went through this cycle in Address module, with Address Format config entities per country, ended up giving up on them.

I also need to re-emphasize that the country list needs to be CLDR and not ISO, otherwise your list will be noticeably different from the one shipped with Drupal, Symfony, operating systems. There's a reason why no country list anywhere uses ISO. Don't make this mistake needlessly.

marassa’s picture

I'm interested in trying out this module. I downloaded the code from github, installed it but when trying to enable it I am getting:

Error: Class 'Drupal\bootstrap\Utility\Unicode' not found in Drupal\countries\Entity\Country->validateProperty() (line 228 of modules\countries-8.x-1.x\src\Entity\Country.php).

vlad.dancer’s picture

@id.tarzanych What's the purpose of the Entity/Country.php? I assume only for status (visible in lists or no).
How about to use commerceguys/addressing for localised pre-defined country manager to start build a list of countries.
Than use something like "CountryOverride" config entity to store only overrides that end-user can make via UI. Actually many users don't need all that countries in "entity representation"

roborew’s picture

Just wondering the thoughts and plans for the drupal 8 version of this module. Was a big fan with drupal 7, and hoped to use it in drupal 8.

@ndlarge I created a simple patch for that issue in the github repo, so head over there to download if you want to test further.

However, I got parts of it working well but also found quite a few bugs that need sorting, documented a few for good measure in github ;-)

Unfortunately i'm in a bit of time pressured situation so looking for a sustainable solution for the organisation that won't change or be unstable in the future. So now leaning towards https://www.drupal.org/project/country as an option as it has some active development and is in beta3. Would have preferred the flexibility of the countries module.

Whats the current roadmap for the module though, plans and focus for release, or is there a rethink going on terms of implementation preventing its alpha release and more dev time dedicated to it. Be happy to support the process if there was a greater need from the community to get it ready.

lpalgarvio’s picture

Priority: Normal » Major

hello

the development has been stopped for 2 years it seems.
the last stable release for drupal 7 is from 2014, 3 years old.

what are your plans?
are you planning to ask for new maintainers and co-maintainers?

lpalgarvio’s picture

Issue tags: +abandoned, +Apply for a co-maintainer, +co-maintainership, +maintainership
Alan D.’s picture

Issue tags: -abandoned

Just time is the issue. I still monitor for anything critical, but nada else atm.

If your interested, I can get a dump of various tasks.

D8 will have a bit of a hurdle trying to make Country entities (they are config entities in D8 & not fieldable), so core functionality in a base module, with a small collection of sub-modules for the various tasks

johnv’s picture

Alan,
perhaps you could make the status of the D8 version more clear.
ATM, for a normal user, it seems there is none.
Some info on the project page, a hint to the github or guide how to download it. or making the code available on drupal.org; creating a D8 release, so people can file issuess against D8-version.
I have ported Workflow module , creating all objects into (config) entities, so I might be able to lend a hand porting the code.
Kind regards,

Alan D.’s picture

Haven't reviewed the patch in #15 in detail, but using Config Entities means you can't be fieldable, but is a great start. :)

Note this issues raised in #20.

So it really needs to have a very good thought about the architecture and built up around that. Potentially via prototyping different strategies and assessing the cleanest most efficient solution.

Country sources should be plugable, ISO, CLDR, whatever. All data provider lists will have some issues with their data depending on the usage and political orientation. ISO is actually better for the AU Government, but CLDR is best for an international AU based organisation for example... got some D7 code somewhere from 2015 that implemented this... but I guess #1830198: Better support for various providers of Country data. has the closest for the port at this stage. And the default should be the implementation that core uses and allow users to override

And happy to grant anyone with experience / existing module maintainer rights access. Added :)

johnv’s picture

Issue summary: View changes
johnv’s picture

Title: Drupal 8 port » Drupal 8/Drupal 9 port
Issue summary: View changes
Issue tags: -, -, -

At the moment I am working on the D8/D9-port of this module.

Not sure if there is a demand for this module after such long time already in Drupal 8/9, and we have some alternatives out there:
https://www.drupal.org/project/countries_info (500 installs, since 2020) for the country list;
https://www.drupal.org/project/country (2.4k installs, since 2013) for the country field;
https://www.drupal.org/project/address (70k installs, since 2015) for the country field.

Using the patch from #14 as a basis, I now have finished:
- a 'country' field (having first 'country', then additionally 'countries' enabled gives unpredicatable resutls, since both declase a 'country' field);
- the 'countries' maintenance UI;
- country storage as ConfigEntity;
- the 'import' page from the accompanying csv (which is also used by countries_info).

I read above discussions, and noticed the following hot topics:
- translation of country names;
- fieldability;
- source of updates, ownership of data;
- memory consumption/loadingtime/caching of 200+ countries.
- ISO vs. CLDR - I do not really understand the issue - this is about translated Names, not about the ISO2-key, right?

This al relates to the StorageDefinition, and it seems that fieldability is a big issue:
- Countries as a ConfigEntity now works, but is not fieldable, but does have 'static_cache' and 'translatable' properties;
- Countries as a ContentEntity requires quite some effort, so I looked at the solution in countries_info:
- Countries as a Taxonomy, keeping the (additional) admin/regional/countries UI.

The latter (Countries as Taxonomy) seems OK for me:
- Caching should be handled by core, since this is 'slow-moving content';
- Fieldability, Translatability is out-of-the-box;
- We can have continents as hierarchy.

Awaiting your opinions...

johnv’s picture

Assigned: Unassigned » johnv
RudiLambert8’s picture

I'm working on a Drupal website for the UN Environmental Program's ecosystem restoration project. With the UN a countries list is a sensitive topic, so I would be very interested in seeing a Drupal 8/9 port of this module.

johnv’s picture

I have revisited this ticket and my code.
IMO the best solution is to have a Countries taxonomy class. That is already implemented in the Countries infomodule. Using this taxonomy, you can disable/enable countries.

https://www.drupal.org/project/country is a very simple field type.
https://www.drupal.org/project/countries_info adds a Taxonomy, and used the out-of-the-box TermReference field widgets and fieldablility.
https://www.drupal.org/project/address has a separate country field type and has 70k installation.

I guess it is best to use one of that alternatives.

The Countries modules does have good functionality for filtering countries.

RudiLambert8’s picture

Unfortunately that won't do for our purposes. I need to override the core Drupal countries list.

Anybody’s picture

Component: Code » Documentation

Perhaps the alternatives and the future plan / development status could be reflected on the module page?

Doesn't look like this will ever be fixed?

Furthermore, it would be super helpful to have an upgrade path via migration module in the most recommended follow-up module?

Anybody’s picture

andypost’s picture

Anybody’s picture