User roles property should always be an array, but they sometimes become an object in localized data

[haruncpi]

When filtering roles via array_filter() in wp-includes/class-wp-user.php, the resulting array ($this->roles) can retain non-sequential numeric keys, if any roles are filtered out. This causes WP_User->roles to be treated as an object when JSON-encoded (e.g., in wp_localize_script()), instead of a proper array, which breaks client-side expectations.

$current_user = wp_get_current_user();

$local_data = array(
    'current_user' => array(
        'id' => $current_user->ID,
        'roles' => $current_user->roles,
    ),
);

wp_localize_script( 'myplugin-frontend', '_myplugin_object', $local_data );

If roles contains keys like [0 => 'editor', 2 => 'seo'] , the resulting JSON becomes:

{ roles: { "0": "editor", "2": "custom" } }

Instead of

{ roles: ["editor", "custom"] }

[haruncpi]

Adds array reindexing to ensure roles remains a proper indexed array

When filtering roles via array_filter() in wp-includes/class-wp-user.php, the resulting array ($this->roles) can retain non-sequential numeric keys, if any roles are filtered out. This causes WP_User->roles to be treated as an object when JSON-encoded (e.g., in wp_localize_script()), instead of a proper array, which breaks client-side expectations.

$current_user = wp_get_current_user();

$local_data = array(
    'current_user' => array(
        'id' => $current_user->ID,
        'roles' => $current_user->roles,
    ),
);

wp_localize_script( 'myplugin-frontend', '_myplugin_object', $local_data );

If roles contains keys like [0 => 'editor', 2 => 'seo'], the resulting JSON becomes:

{ roles: { "0": "editor", "2": "custom" } }

Instead of

{ roles: ["editor", "custom"] }

Ticket’s URL
https://core.trac.wordpress.org/ticket/63427

### Test Report

I’ve tested this PR and can confirm that it works as expected. After applying the changes, the $current_user->roles array is properly reindexed using array_values(), ensuring sequential keys. The localized JSON output now correctly produces an array instead of a JavaScript object, which resolves the client-side issue.

Tested with multiple role combinations, including cases where some roles were removed — everything behaves correctly. ✅

### Testing environment:

WordPress Version: 6.8.1
PHP Version: 8.2.27
Theme: TwentyTwentyFive
Plugins: None installed
OS: Windows

Thanks for the Fix

[haruncpi]

Could you kindly take a look and review this fix? @SergeyBiryukov @desrosj

[SirLouen]

@haruncpi If you have a patch and a test report, you dont have to close the ticket. Leave it open for review with the patch. Closing with worksforme is used when someone reports a bug, you test it and you see there is no bug.

PS: I have not tested the patch, I'm just informing the user.

[haruncpi]

Thank you @SirLouen
Reopened for review.

[SirLouen]

@haruncpi I've added some code review in your PR. Give it a check when you can.

[SirLouen]

<has-code-review>

I've been able to track the introduction of array_keys back to 1.6 [2793], which is not the problem itself, but is the main reason of why this is happening. Because this thing has probably existed historically, from the inception of this function.

The question here is: @haruncpi why you don't simply preprocess the resulting json into an array, before delivering it to wp_localize_script?

[haruncpi]

Replying to SirLouen:

@haruncpi I've added some code review in your PR. Give it a check when you can.

PR is updated

[SirLouen]

Still I have the question:

@haruncpi why you don't simply preprocess the resulting json into an array, before delivering it to wp_localize_script?

This not sequential order has been for ages, and I'm not sure if it's a bug or just something expected. After checking the history of this function, this has been there for easily 15+ years (since WP 1.6 when they introduced array_keys). Not saying that everything old is correct, but I'm still trying to find an useful reason.

[haruncpi]

Replying to SirLouen:

Still I have the question:

@haruncpi why you don't simply preprocess the resulting json into an array, before delivering it to wp_localize_script?

This not sequential order has been for ages, and I'm not sure if it's a bug or just something expected. After checking the history of this function, this has been there for easily 15+ years (since WP 1.6 when they introduced array_keys). Not saying that everything old is correct, but I'm still trying to find an useful reason.

Thanks for the question!

The issue isn’t really about whether this behavior has existed since early WordPress versions. It likely wasn’t noticed, triggered, or was often preprocessed by developers before reaching wp_localize_script.

However, delivering correct, consistent data directly from core is always the better approach. It ensures data integrity at the source and removes the need for extra preprocessing by developers. This makes the data safer and more predictable for all use cases.

Additionally, the process is now optimized to linear time, preventing potential cubic complexity.

[SirLouen]

Replying to haruncpi:

However, delivering correct, consistent data directly from core is always the better approach. It ensures data integrity at the source and removes the need for extra preprocessing by developers. This makes the data safer and more predictable for all use cases.

I understand your concern which from my point of view is valid

I think that for this reason, its required to use the maybe_unserialize WP function.

$current_user = wp_get_current_user();

$local_data = array(
    'current_user' => array(
        'id' => $current_user->ID,
        'roles' => maybe_unserialize( $current_user->roles ),
    ),
);

wp_localize_script( 'myplugin-frontend', '_myplugin_object', $local_data );

Probably due to this kind of issues all over the code.

Still I agree with you that this could/should be fixed to provide a more consistent data and also now I feel that with a simplified complexity (not from cubic, but cuadratic because original there were only two iterations), now becomes linear so it also provides some performance improvement.

[SirLouen]

At this point, I think it is ready to be shipped
cc @SergeyBiryukov

[wildworks]

@haruncpi @SirLouen Can you rebase the pull request on top of the trunk branch to run CI and ensure that the tests don't fail?

[haruncpi]

I have merged the latest changes from WordPress:trunk into my PR branch.
I ran the tests/phpunit/tests/user.php suite, and all tests passed successfully.
Additionally, the test_user_roles_property_is_sequential_array test ran without any failures.

Replying to wildworks:

@haruncpi @SirLouen Can you rebase the pull request on top of the trunk branch to run CI and ensure that the tests don't fail?

[haruncpi]

Hi @SergeyBiryukov @wildworks,
This was completed and tested about 5 months ago, and @SirLouen confirmed it’s ready to ship.
When you have a moment, please review and merge the PR.

[wildworks]

@haruncpi Thanks for the update!

@SergeyBiryukov, Do you have the bandwidth to commit to ​PR 8790 before the RC1 release?

[wildworks]

I will change the keywords because new feedback has been added to the pull request.

[haruncpi]

@wildworks
Thanks! I’ve updated the PR with all the requested changes except one.
I’ve also added an explanation for why a simple foreach loop was used instead of array_values() — mainly for performance and clarity reasons, as suggested by @SirLouen in this commit ​https://github.com/WordPress/wordpress-develop/pull/8790/commits/4e32ecf82553567ffc7598296a04490dda85c95b

@haruncpi It appears the unit tests are failing. Could you investigate whether the problem lies in the logic itself or if the tests need to be updated?

@t-hamano unit test case updated, now it's working fine.

[johnjamesjacoby]

Just reviewed & approved the PR.

If Sergey doesn't commit this, I'm happy to.

[wildworks]

@johnjamesjacoby Please do :)

[SergeyBiryukov]

In 61210:

Users: Initialize the WP_User::$roles property as a sequential array.

Previously, if any roles were filtered out via array_filter() when assigning the WP_User::$roles property in WP_User::get_role_caps(), the resulting array could contain non-sequential numeric keys, which would then cause it to be treated as an object when JSON-encoded, e.g. in wp_localize_script(), instead of a proper array, breaking client-side expectations.

This commit ensures that the WP_User::$roles property is always treated as an array.

Follow-up to [2703], [2793], [22118].

Props haruncpi, peterwilsoncc, SirLouen, getsyash, wildworks, johnjamesjacoby, SergeyBiryukov.
Fixes #63427.