Unicode mapping fallback

[denysvitali]

Hello everyone,
I'm posting here for an issue I'm having with this library and PrestaShop v1.7+

Apparently the Prestashop devs have included your library in the installation process and many users are experiencing some problem with the provide function. Apparently, under certain conditions, the codeMappings.json file can't be downloaded, thus the installation fails.

A workaround for this issue appears to be to provide the codeMappings.json file separately, I've personally fixed my issue by changing the function to this:

/**
     * The section path, following the pattern "<identity>/<section>".
     *
     * @param string $path
     *
     * @throws ResourceNotFound when the specified path does not exists on the CLDR source.
     *
     * @return string
     */
    public function provide($path)
    {
        #$connection = $this->obtain_connection();

        #curl_setopt($connection, CURLOPT_URL, $this->origin . $path . '.json');

        #$rc = curl_exec($connection);

        #$http_code = curl_getinfo($connection, CURLINFO_HTTP_CODE);

        #if ($http_code != 200)
        #{
        #   throw new ResourceNotFound($path);
        #}
        #
        $rc = file_get_contents('/app/vendor/icanboogie/cldr/lib/codeMappings.json');

        return json_decode($rc, true);
    }

I'm now providing the file here, just in case you can't reach unicode.org.

It will be nice if the file gets included directly in this repo

The error in PrestaShop is the following:

1: HTTP 200 - parsererror -
Fatal error: Uncaught ICanBoogie\CLDR\ResourceNotFound: Path not defined: supplemental/codeMappings. in /app/vendor/icanboogie/cldr/lib/WebProvider.php:77 Stack trace: #0 /app/vendor/icanboogie/cldr/lib/ProviderChainTrait.php(43): ICanBoogie\CLDR\WebProvider->provide('supplemental/co...') #1 /app/vendor/icanboogie/cldr/lib/ProviderChainTrait.php(43): ICanBoogie\CLDR\FileProvider->provide('supplemental/co...') #2 /app/vendor/icanboogie/cldr/lib/Repository.php(124): ICanBoogie\CLDR\RunTimeProvider->provide('supplemental/co...') #3 /app/vendor/icanboogie/cldr/lib/Supplemental.php(95): ICanBoogie\CLDR\Repository->fetch('supplemental/co...') #4 /app/src/Core/Cldr/Repository.php(301): ICanBoogie\CLDR\Supplemental->offsetGet('codeMappings') #5 /app/src/Core/Cldr/Repository.php(226): PrestaShop\PrestaShop\Core\Cldr\Repository->isCurrencyValid('CHF') #6 /app/classes/Currency.php(135): PrestaShop\PrestaShop\Core\Cldr\Repository->getCurrency('CHF') #7 /app/classes/LocalizationPack.php(326): CurrencyCore->add() #8 /app/classes/Locali in /app/vendor/icanboogie/cldr/lib/WebProvider.php on line 77

[olvlvl]

Hi @denysvitali,

Thanks for reporting this. Is download always failing on codeMappings or is it random? supplemental/codeMappings is accessible here http://www.unicode.org/repos/cldr-aux/json/26/supplemental/codeMappings.json, could it be a problem with CURL, or how I used it?

This version of CLDR is pretty old, but Prestashop is locked with PHP 5.4 :(

It's almost one in the morning where I leave, I'll try to install Prestashop tomorrow.

[denysvitali]

Don't worry.

I was able to reproduce this issue only on 1 of my 3 servers.
I still don't know why this happens, but many users report it as a kind of rate limit from unicode.org.

I still haven't figured out exactly what the problem is, I'm running Prestashop in a Docker container, but I can reach the unicode json with wget / curl without any problem.
Unfortunately Prestashop composer file forces a PHP version of 5.4, therefore this library version is blocked at 1.3.9 (IIRC). I'll check tomorrow if I can make a branch of Prestashop where targeted for PHP 7+, with updated libraries.

Some references:
Issue on Prestashop's IssueTracker
Issue on the forums

[olvlvl]

I'm checking Prestashop's code and it appears they use their own CLDR mirror:

https://github.com/PrestaShop/PrestaShop/pull/7597/files
http://i18n.prestashop.com/cldr/json-full/supplemental/codeMappings.json

Do you have this code in your files? If not, maybe try to update.

[denysvitali]

Yes, I do.
I'm pretty sure the problem is still with the vendor's CLDR (yours, stuck at v 1.3.9).

Apparently Prestashop uses both yours and their own implementation. I don't really have an explanation for this

[denysvitali]

Quick update:
I've fixed the problem by adding the Google public DNS to my container (yes, I'm that dumb for not thinking about it.)

Sorry for this issue.

[olvlvl]

I'm glad you found a way to fix your issue. On my side I tried to install Prestashop and everything went fine. I leave my Vagrantfile here for posterity:

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure("2") do |config|
  config.vm.box = "ubuntu/xenial64"
  config.vm.network "private_network", ip: "192.168.33.10"
  config.vm.provision "shell", inline: <<-SHELL
    apt-get update
    debconf-set-selections <<< "mysql-server mysql-server/root_password password password"
    debconf-set-selections <<< "mysql-server mysql-server/root_password_again password password"
    apt-get install apache2 libapache2-mod-php mysql-server php php-mysql php-zip php-xml php-gd php-curl php-intl -y
    a2enmod rewrite
    cp /vagrant/* /var/www/html/
    rm /var/www/html/index.html
    chown www-data:www-data /var/www/html
    service apache2 restart
  SHELL
end