Bug in function current_user_can prevents admin to access to Dashboard

[DotMG]

File : wp-includes/capabilities.php

method has_cap is not always defined for the Object $current_user, and when this occurs, site Administrator cannot access to Dashboard, because the function current_user_can returns false.

The real bug is what caused the method has_cap to be absent for the object $current_user, after a successful login. But this patch simply avoid the calling of has_cap when it is not available.

[DotMG]

Tests if has_cap is callable before actually calling it.

[DotMG]

Somewhat, _wp_get_current_user() in wp-includes/user.php was the problem here. I made the following change :

        #if ( ! empty( $current_user ) ) {
        if ( ! empty( $current_user->ID ) ) {

to finally manage to let the admin log-in and access to Dashboard. And I cancelled all other changes I've made (to capabilities.php, etc).

[pento]

Thank you for the bug report, @DotMG!

Are you able to reproduce this issue with no plugins activated? The $current_user global is only set in a few places in Core, and they should all be ensuring that it's a proper WP_User object.

Detailed steps to reproduce this bug would also be very helpful for getting it fixed.

[DotMG]

Replying to pento:

Are you able to reproduce this issue with no plugins activated?

Detailed steps to reproduce this bug would also be very helpful for getting it fixed.

I could not reproduce the "bug", even with all plugins activated, once I could get passed it by applying the fix I proposed in comment:1. That means : $current_user was set, it was a WP_User object, but it had $current_user->ID equal to 0.

The main issue here is the deadlock. Under an unknown circumstances, the admin can login "successfully", but is not identified correctly as an administrator, as $current_user->ID remains equal to 0. I'll be looking at how $current_user is modified after user or admin login.

[DotMG]

After a long digging, the issue is caused by another software that has set the global variable $current_user. So, it's not a Wordpress bug. It's a global variable name collision.

If there's an enhancement that can be made, that would be to rename global variable by adding a prefix like WORDPRESS_GLOBAL_

And maybe (or surley) it's not worth it...