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 16 replies, has 3 voices, and was last updated by  chris 1 month, 4 weeks ago.

  • Creator
    Topic
  • #38321

    chris
    Participant

    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 15 replies - 1 through 15 (of 16 total)
  • Author
    Replies
  • #38322

    chris
    Participant

    first
    second
    third
    view

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

    #38323

    chris
    Participant

    first
    second
    third

    correct in ‘view order’
    view-order-correct

    #38324
    Andrey Yatsenko
    Andrey Yatsenko
    Moderator

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

    #38325

    chris
    Participant

    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?

    #38328

    chris
    Participant

    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:
    php-intl-7.2.16-1.el7.remi.x86_64

    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?

    #38329

    chris
    Participant

    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 4 months, 1 week ago by  chris.
    #38332

    chris
    Participant

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

    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 ..

    #38333
    Andrey Yatsenko
    Andrey Yatsenko
    Moderator

    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.

    #38342

    chris
    Participant

    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…

    https://forum.remirepo.net/viewtopic.php?id=3774

    and in

    https://blog.remirepo.net/post/2019/02/21/PHP-version-7.2.16RC1-and-7.3.3RC1

    “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.

    https:///bugs.php.net/bug.php?id=72879

    ” [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 4 months, 1 week ago by  chris.
    #38346

    chris
    Participant

    Maybe just a week ago? =\

    #38351

    chris
    Participant

    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 4 months, 1 week ago by  chris.
    #38355
    Andrey Yatsenko
    Andrey Yatsenko
    Moderator

    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

    #38356

    chris
    Participant

    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

    #38365
    Andrey Yatsenko
    Andrey Yatsenko
    Moderator

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

    7.1 and 7.2

    #38908

    roberto.taschetto
    Participant

    Hi Andrey,
    are these packages usable for Community Editition or only for Enterprise Edition?

    Thanks,
    Roberto

Viewing 15 replies - 1 through 15 (of 16 total)

You must be logged in to reply to this topic.

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

Yes No