False negative for Craft::$app->getUser()->getIsAdmin() in a plugin

[mmikkel]

Description

In a site upgraded from RC 10.1 to RC 11, I'm seeing some odd behaviour where the Craft::$app->getUser()->getIsAdmin() method returns false when called from a plugin's init method, even if the logged in user is an admin.

Specifically, this is an issue with my CP Field Inspect plugin, but I've also tested it with different plugins, and the same thing happens with all of them. As far as I've been able to figure out, getIsAdmin() actually returns false because User::getIdentity() returns null... for some reason.

To make things weirder, this does not happen on a different, clean install of RC 11. However, other users are seeing the same thing as me on their upgraded RC11 installs.

Probably related: I'm also seeing similarly odd behaviour with Craft::$app->getFields()->getAllFields();, which returns an empty array when called from a plugin's init method, although there are definitely fields in the site.

Disabling/enabling or even re-installing the affected plugin(s) does not help. I've also tried clearing out all caches and emptying all sessions/cookies/localstorage.

Steps to reproduce

1. Install a plugin on a Craft 3 version earlier than RC 11 (not sure if having the plugin installed before upgrading Craft is necessary or not)
2. Upgrade the Craft install to RC 11 (from the CP, not terminal/Composer)
3. Log in to Craft's CP with an admin account
4. Dump/log Craft::$app->getUser()->getIsAdmin(); from a plugin's init() method, confirm it returns false

Additional info

• Craft version: 3.0.0-RC11
• PHP version: 7.0.14
• Database driver & version: MySQL 5.6.34
• Plugins & versions: CP Field Links, v. 1.0.2

[brandonkelly]

I was able to reproduce this on Control Panel requests. Issue is that on CP requests, plugins are first initialized right in the midst of Craft/Yii fetching the logged-in user, in the process of setting the application language based on the user’s preferred language. Until it’s done, yii\web\User::getIdentity() will just return null, to prevent infinite recursive calls to getIdentity().

(It’s not an issue on front-end requests because the application language is determined by the current site on front-end requests, not the logged-in user.)

This bug was introduced by 1bbd5ac, which fixed #2439. Beforehand, plugins were loaded before Craft went on to set the application language, which is all well and good unless a plugin happens to need to load the formatter or locale components (directly or indirectly), which are configured based on the application language, and thus will end up getting misconfigured.

To fix both bugs (#2439 and this one), we just need to be able to get the logged-in user’s preferred language without actually fetching the logged-in user.

[mmikkel]

As of Craft 4.0.0-RC1, I'm no longer able to reproduce this issue 🎉

[brandonkelly]

This was supposedly fixed four years ago. Not the case?

[mmikkel]

Pardon the confusion, my brain wasn't fully plugged in before.

This original issue in Craft is fixed; I guess I've just been using this as a bookmark for when the same problem is triggered via modules or plugins – a thing that still crops up from time to time and that I can consistently reproduce on 3.7.39, but not on 4.0 (hence the excitement).

Like the similar/related #8733 this should probably be considered a plugin issue though (and in any case should've had its own issue years ago, instead of referring back to this one). Sorry for the noise 😅

[brandonkelly]

Hah, alright, well I’m glad we inadvertently did something to fix it further :)