OroCommerce Forums

Covering OroCommerce topics, including community updates and company announcements.

Forums OroCommerce Currency issue in 3.1.4 build pulled via composer

This topic contains 14 replies, has 2 voices, and was last updated by Andrey Yatsenko Andrey Yatsenko 4 days, 4 hours ago.

  • Creator
  • #38321


    Just grabbed a fresh composer based source and saw 3.1.4 versions (different than the git 3.1.3 mentioned right now?) during install… Installed like always, no snags there

    Once installed, I’m seeing a snag/bug in the shopping list checkout process.. In the bottom-most pane, I’m not seeing the proper currency symbol or word ($/USD) but rather XXX … Double checked and tried settings but nothing has changed it.. I don’t think I missed something during shipment/payment integration/rules somehow, but maybe.

    I can submit some screen shots if necessary.

Viewing 14 replies - 1 through 14 (of 14 total)
  • Author
  • #38322



    It does look correct once the order is ‘viewed’ after it’s submitted.




    correct in ‘view order’

    Andrey Yatsenko
    Andrey Yatsenko

    This looks like a known issue of Mac OS X with outdated ICU version. You have to update this library to fix an issue.



    The running instance is on centos/pagespeednginx, no apple gear around here.. Rendering on a Win10 box in chrome & firefox both… you’re thinking intl libs inside php though?



    Now I knwo to look, I notice :

    — | WARNING | To get the latest internationalization data upgrade the ICU system package and the intl PHP extension.

    during oro:install

    php-intl ver:

    in /lib64
    i’ve got 50.1.2 and 62.1 installed for icu shared objects

    just reinstalled a 3.1.3 git brand as opposed to the statis composer pull and see the same issue there..

    What version of ICU do I require?



    I just rebuilt with remi php7.1 instead of 7.2 like above, and got the same results –
    On the 7.1 setup —

    • This reply was modified 1 week, 3 days ago by  chris.


    Confirmed in phpinfo() that 62.1 was being used correctly by php-intl …

    Internationalization support enabled
    version 1.1.0
    ICU version 62.1
    ICU Data version 62.1

    Do I need to retrieve 63.1 somehow and rebuild php etc?

    I also tested to make sure it wasn’t the mb4 unicode SQL/doctrine action, redid everything both waysstill have the issue of XXX ..

    Andrey Yatsenko
    Andrey Yatsenko

    63.1 works fine for me, you can rebuild it from source or try to upgrade the php7.2 to the last patch release it also helps on some systems.



    Hey Andrey,

    Thanks for the input, tracking things down more and more I’ve found that in the remi Centos repository, he changed over from ICU 50.1 that was base in Centos (I’m building off of Google Centos images) to the 62.1 I mentioned, fairly recently…


    and in


    “On RHEL / CentOS 7 the intl extension now use libicu version 62.1 (instead of 50.1). Feedback welcome.”

    Only thing I can come up with that wouldv’e broken it.. I’ve tried to register at their forum to request 63.1 but cannot successfully register..

    Building php-intl using pecl is deprecated c/o of PHP documentation/forums. Even though I grabbed/built ICU 63.1 and php-intl did see it successfully.


    ” [2018-04-16 11:36 UTC] show email PECL/intl has been superseeded by the bundled ext/intl. If your
    distro does not support it, either request that it does, or build your own PHP.”

    I think you can pretty easily reproduce it… I’ve rebuilt a few VMs in the last two days basing off of the remi php builds and kept rolling back orocommerce builds, issue is still there everywhere but never before this ICU version upgrade inside the remirepo..

    Thanks man, I’m sure there’s others going to experience this one.. =(

    • This reply was modified 1 week, 2 days ago by  chris.


    Maybe just a week ago? =\



    Here’s the master debian PHP packager talking about it too… Hmmm. Thanks again Andrey for the time and help man, let me know if you’ve got any insight or thoughts..

    Truly appreciate all of the work man!

    • This reply was modified 1 week, 1 day ago by  chris.
    Andrey Yatsenko
    Andrey Yatsenko

    Hi Chris,
    Our DevOps team confirmed that remi packages go with wrong ICU version, and because of this, we built our own PHP packages. To use them follow the official installation guide.
    Pay attention to these steps:
    1) Enable Required Package Repositories
    2) Install PHP



    Truly appreciate the confirmation from your devops guys, glad to hear it wasn’t just me. =)

    I’ll be starting over with a new VM and your repository for things and report back… Do you only build php 7.1 packages right now I assume?

    Since yesterday, I’ve spun up a debian testing google cloud image, used deb.sury.org’s php packages and
    then back-installed the nodejs v6 engine from nodesource.com as well as the latest pagespeed/nginx …

    php7.2.16, ICU 32.1, nodeJS 6.14.4

    Worked like a champion and took care of the currency sign issue.. I also included the tidy and imap php
    extensions to fulfill runtime checks/warnings..

    Thank you again Andrey, and thank your devops team for me as well! =)

    For reference –:
    apt-get install -y wget git
    apt-get install -y apt-transport-https
    wget -O /etc/apt/trusted.gpg.d/php.gpg https://packages.sury.org/php/apt.gpg
    echo “deb https://packages.sury.org/php/ $(lsb_release -sc) main” | tee /etc/apt/sources.list.d/php.list

    curl -sL https://deb.nodesource.com/setup_6.x | bash –
    apt-get install -ynodejs=6.14.4-1nodesource1
    apt-mark hold nodejs=6.14.4-1nodesource1

    apt-get install -y php7.2-common php7.2-cli php7.2-curl php7.2-fpm php7.2-mysql php7.2-xml php7.2-soap php7.2-gd php7.2-mbstring php7.2-zip php7.2-intl php7.2-opcache php7.2-json php7.2-readline php7.2-xml php7.2-tidy php7.2-imap unzip zip

    apt-get install -y libssl-dev
    bash <(curl -f -L -sS https://ngxpagespeed.com/install) –nginx-version latest

    Andrey Yatsenko
    Andrey Yatsenko

    Do you only build php 7.1 packages right now I assume?

    7.1 and 7.2

Viewing 14 replies - 1 through 14 (of 14 total)

You must be logged in to reply to this topic.

You will be redirected to [title]. Would you like to continue?

Yes No
sso for www.magecore.comsso for oroinc.comsso for oroinc.desso for oroinc.fr