search

craftcms / cms

Build bespoke content experiences with Craft.
https://craftcms.com
Other
3.23k stars 629 forks source link

Upgrade tp 3.3.5 showing small error on entry count in cp. #4995

Closed gjhead closed 4 years ago

gjhead commented 5 years ago

Description

Just upgraded to 3.3.5. My localhost seems to be ok, but my staging site is giving me an error where the "Entry Count" shows up at the bottom of the entry screen. Instead of saying "X Entries" it's instead echoing: "{total, number} {total, plural, =1{{item}} other{{items}}}

error

Additional info

Application Info PHP version 7.3.9 OS version Linux 2.6.32-042stab140.1 Database driver & version MySQL 5.5.30 Image driver & version Imagick 3.4.3 (ImageMagick 6.7.2-7) Craft edition & version Craft Pro 3.3.5 Yii version 2.0.21 Twig version 2.11.3 Guzzle version 6.3.3 Imagine version 1.2.3-dev

Plugins Freeform 3.5.0 Redactor 2.4.0 Super Table 2.3.0

Modules my-module modules\Module

brandonkelly commented 5 years ago

What is your user account’s Language set to?

Do you have the Intl PHP extension installed? (Go to Utilities → PHP Info and search for intl. If there are any results, it’s installed.)

brandonkelly commented 5 years ago

You may want to try nuking your vendor/ folder and running composer install on the server to ensure that the Craft update is fully installed.

gjhead commented 5 years ago

User account’s language: English (United States)

Intl PHP Extension is installed. (Although it looks like my webhost has a MUCHh earlier version that I have on my localhost.)

Webhost with code problem: ICU version 4.2.1 ICU TZData version 2009j ICU Unicode version 5.1 intl.default_locale no value intl.error_level 0 intl.use_exceptions 0

Localhost without the problem: ICU version 56.1 ICU Data version 56.1 ICU TZData version 2015f ICU Unicode version 8.0 intl.default_locale no value intl.error_level 0 intl.use_exceptions 0

brandonkelly commented 5 years ago

Can you try opening vendor/yiisoft/yii2/i18n/MessageFormatter.php and change line 93 from:

if (!class_exists('MessageFormatter', false)) {

to:

if (true || !class_exists('MessageFormatter', false)) {

and see if that helps?

gjhead commented 5 years ago

That fixed it! Man, I love Craft!

brandonkelly commented 5 years ago

Well that just isolated that it’s your version of Intl that’s the culprit. Can you tell me which version you’re running?

gjhead commented 5 years ago

Yep - see my post above. I posted all the php info i could for intl for both my local and stage.

brandonkelly commented 5 years ago

Right ok. I’m guessing that this is just a bug with the Intl extension you’re running. I’d try downgrading to PHP 7.2 for now on that server and see if you have better luck. The change you made manually is going to go away the next time you update Yii.

ryanmasuga commented 4 years ago

For anyone else coming along: I did a fresh install of Craft Pro 3.3.11 and am seeing this pagination rendering issue on the /admin/users screen: {total, number} {total, plural, =1{{item}} other{{items}}}

Under System Report > Requirements, Craft says for Intl: "The Intl extension (version 1.0.2+) is recommended." That may have to become a more specific message if this issue continues to crop up (we've seen it on two servers now that must have older intl extension installed)

The problem server is running PHP 7.2.22 and has these settings:

intl
version             1.1.0
ICU version         4.2.1
ICU TZData version  2009j
ICU Unicode version 5.1
intl.default_locale no value
intl.error_level    0
intl.use_exceptions 0

Locally, I have this site running on PHP 7.2.20 and these intl settings, and I'm not seeing the issue (note is has one more line "ICU Data version" than the intl settings on the problem server):

intl
version             1.1.0
ICU version         56.1
ICU Data version    56.1
ICU TZData version  2015f
ICU Unicode version 8.0
intl.default_locale no value
intl.error_level    0
intl.use_exceptions 0

Guess we'll see if the host can update that specific extension.

ryanmasuga commented 4 years ago

I don't know where the fault lies here, but the host is saying "hold up" - here were their responses. Is the host being unreasonable here, or is this an issue with how Craft is rendering those things, or does the fault lie with Yii...I think this is a little bigger issue than it first appears - can we only effectively install Craft on some servers and expect it to work correctly?

We have an app installed that is filing to render some variables. The reason has been narrowed down to the intl PHP extension.

Can you clarify the reasoning behind that?

Is it possible to update the intl extension?

The setting for "intl" are identical, what you're referring to is the ICU library, which is maintained by the linux distribution. As far as I can tell the only way to change this for you would be to install it from source, which really isn't a great idea for a maintained library.

I think I'd need to see something more specific as to why you believe this is a problem to decide if this is something we'd be willing to do. I'm not confident this is even safe to change.

We've also never had a customer ask us to do this, so I'm trying to understand your very unique requirement here.

Can you provide a reproducible example of this issue?

Why is the pagination info tied to whatever intl is doing, but other parts of the CP aren't affected? The pagination info is some of the most useful in the entire CP!

terryupton commented 4 years ago

I am also seeing this issue on my production server, across a few sites. But not locally using Valet. What is the solution here? It seems this was closed but I cannot see a valid fix from the thread?

Screenshot 2019-10-22 at 18 53 17 
version 1.1.0
ICU version 4.2.1
ICU TZData version 2009j
ICU Unicode version 5.1
intl.default_locale no value
intl.error_level 0
intl.use_exceptions 0

Running PHP 7.2.23

brandonkelly commented 4 years ago

If one of you can give us SSH access to your server, we should be able to investigate further. support@craftcms.com

ryanmasuga commented 4 years ago

I'm talking with our host about this now. That "ICU version 4.2.1" seems incredibly old, especially when other people are reporting ICU versions like 64.1 or 55.1.

ryanmasuga commented 4 years ago

If one of you can give us SSH access to your server, we should be able to investigate further. support@craftcms.com

Brandon, I can give you SSH access. Will email support now.

terryupton commented 4 years ago

I see @ryanmasuga has offered SSH access, but let me know if you want it from me too...

angrybrad commented 4 years ago

@ryanmasuga @terryupton Do you happen to know what linux distro and version your servers are running?

terryupton commented 4 years ago

@angrybrad I am not exactly sure what information you need as this goes a little over my head but here are some (hopefully useful) stats:

let me know if this is not what you asked. :-)

ryanmasuga commented 4 years ago

Well, we may be out of luck on this one. I pointed them to this thread, and this was their response. Maybe others running into this will have a more flexible host.

Guess any of our clients on this host are going to have to be content with {total, number} {total, plural, =1{{item}} other{{items}}} for their pagination.

I read the conversation you linked. I think you need to just wait for the developers of that CMS to patch their code.

Realistically it's not viable to have a web application that requires such a specific and recent version of this library. Reasonable server administrators are not going to be installing the latest version of this from source to meet this need.

It's hard to not consider this a bug in their code, when clearly it could be avoided with some modification to their logic.

If CentOS means being locked into a "conservative" distro if you will, perhaps the app we build with the most (Craft CMS) isn't going to be the best fit for these servers, if this is possibly indicative of other issues that may arise due to using older (albeit stable) software extensions/packages.

You can do what you want, but you're going to regret that approach. You don't want to run software that is on the absolute bleeding edge of libraries like this. It's the developers job to have their software be compatible with the extremely vast majority of the server market. You really don't want to be on a server where everything is installed from source and custom per environment to meet the needs of these one-off issues.

Anyway, we're not going to install ICU from source for you. They'll just need to update their application to be compatible with a huge percentage of their user base.

The host has a point, the Yii devs need to fix something, or both. All I know is, when our clients inevitably ask why the control panel looks broken, I'll only be able to ¯_(ツ)_/¯.

brandonkelly commented 4 years ago

I believe we’ve just fixed this. Would appreciate if you all could test though!

To get the fix early, change your craftcms/cms requirement in composer.json to:

"require": {
  "craftcms/cms": "dev-develop#eff654f21af547f2d97d89362a07053e55ee4e7a as 3.3.12",
  "...": "..."
}

Then run composer update.

terryupton commented 4 years ago

@brandonkelly I have updated and confirm it is fixed. Thanks for sorting this and so promptly....amazing! 👍

Screenshot 2019-10-22 at 21 04 48
angrybrad commented 4 years ago

For posterity:

Looks like CentOS 6 uses a really old ICU version (4.2.1): http://mirror.centos.org/centos/6/os/x86_64/Packages/icu-4.2.1-14.el6.x86_64.rpm

And ICU 4.2.1 looks like it came out in 2009.

Craft 3 recently expanded our use of message parameter formatting so we could support how different languages deal with singular and plural words differently.

Looking at the underlying ICU class that's used, there are some methods that didn't get introduced until ICU 4.8, which was released in 2011.

And according to here, 4.8 major changes included "CLDR 2.0, MessageFormat rewrite", so my guess is that's the safest minimum ICU version that supports this..

gjhead commented 4 years ago

Nice. Thanks @brandonkelly

brandonkelly commented 4 years ago

Just submitted a PR to Yii to fix this at the core: https://github.com/yiisoft/yii2/pull/17630

angrybrad commented 4 years ago

Realistically it's not viable to have a web application that requires such a specific and recent version of this library.

I lol'd at that from the host.

Realistically, it's reasonable for a semi-modern application to expect a library that's more recent than 8 years old.

I get that CentOS is conservative and is maintained for 10 years after release, but even then, CentOS 6 falls out of that maintenance window next year.