Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
This issue is about the D8/D9 port for Countries module. The current version is only available as an attached patch in this issue.
Comment | File | Size | Author |
---|---|---|---|
#15 | interdiff-1277356-13-14.txt | 551 bytes | id.tarzanych |
#15 | 1277356-countries-drupal-8-port-14.patch | 388.48 KB | id.tarzanych |
Comments
Comment #1
Alan D. CreditAttribution: Alan D. commentedI think that this may be 1 or 2 years premature, but thanks for the heads up on this
Comment #2
Alan D. CreditAttribution: Alan D. commentedThe 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
Comment #3
Alan D. CreditAttribution: Alan D. commentedThere 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...
Comment #4
bojanz CreditAttribution: bojanz commentedIt 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)
Comment #5
Alan D. CreditAttribution: Alan D. commented@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.
Comment #6
bojanz CreditAttribution: bojanz commentedYou 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).
Comment #7
Alan D. CreditAttribution: Alan D. commentedCountry 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.
Comment #8
matsbla CreditAttribution: matsbla commentedI 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).
Comment #9
id.tarzanych CreditAttribution: id.tarzanych at Internetdevels commentedPlease 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:
Comment #10
id.tarzanych CreditAttribution: id.tarzanych at Internetdevels commentedCreated GitHub repo to make code review easier: https://github.com/id-tarzanych/countries
Comment #11
Alan D. CreditAttribution: Alan D. commented@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.
Comment #12
id.tarzanych CreditAttribution: id.tarzanych at Internetdevels commented@Alan D.
Thanks, I am really interested in that.
By the way, what do you think about logic based on Country config entities here?
Comment #13
id.tarzanych CreditAttribution: id.tarzanych at Internetdevels commentedAdded code protection.
Comment #15
id.tarzanych CreditAttribution: id.tarzanych at Internetdevels commentedRemoved obsolete line
Comment #17
id.tarzanych CreditAttribution: id.tarzanych at Internetdevels commentedComment #18
Alan D. CreditAttribution: Alan D. commentedThere 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 :)
Comment #19
Alan D. CreditAttribution: Alan D. commentedOh, and I would just ditch Countries configuration & example sub-modules, i18n shouldn't be needed
Comment #20
bojanz CreditAttribution: bojanz commentedYour 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.
Comment #21
marassa CreditAttribution: marassa commentedI'm interested in trying out this module. I downloaded the code from github, installed it but when trying to enable it I am getting:
Comment #22
vlad.dancer@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"
Comment #23
roborew CreditAttribution: roborew at Christian Aid commentedJust 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.
Comment #24
lpalgarvio CreditAttribution: lpalgarvio as a volunteer commentedhello
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?
Comment #25
lpalgarvio CreditAttribution: lpalgarvio as a volunteer commentedComment #26
Alan D. CreditAttribution: Alan D. commentedJust 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
Comment #27
johnvAlan,
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,
Comment #28
Alan D. CreditAttribution: Alan D. commentedHaven'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 :)
Comment #29
johnvComment #30
johnvAt 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...
Comment #31
johnvComment #32
RudiLambert8 CreditAttribution: RudiLambert8 commentedI'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.
Comment #33
johnvI 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.
Comment #34
RudiLambert8 CreditAttribution: RudiLambert8 commentedUnfortunately that won't do for our purposes. I need to override the core Drupal countries list.
Comment #35
AnybodyPerhaps 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?
Comment #36
AnybodyComment #37
andypostComment #38
Anybody