AAM breaks user creation on WordPress Multisite — "Sorry, you are not allowed to give users that role."

Summary

AAM 7.x replaces the standard WordPress role dropdown on user-new.php with its own aam_user_roles[] multi-select field. WordPress 6.7+ introduced wp_ensure_editable_role(), which validates the presence of a role POST field before allowing user creation. Since AAM removes the role field, this core validation always fails, making it impossible to create new users on Multisite subsites when AAM is active.

This is a different issue from #180 (which was fixed in 6.9.4 for user-edit.php on AAM 6.x). The v7 rewrite + WordPress 6.7's new security check introduced a new variant on user-new.php.

Environment

• WordPress version: 6.7+ (any version with wp_ensure_editable_role)
• AAM version: 7.x (tested on 7.0.11)
• Setup: WordPress Multisite
• PHP version: 8.x

Steps to Reproduce

1. Install WordPress Multisite with AAM 7.x network-activated
2. Log in as a Super Admin
3. Navigate to a subsite's aam plugin setting at /wp-admin/admin.php?page=aam, then go to Settings -> Core Settings -> Enable "Multiple Roles Support"
4. Navigate to a subsite's Users → Add New (/wp-admin/user-new.php)
5. Fill in the new user form (username, email)
6. Select a role (e.g., Subscriber) from AAM's role selector
7. Click Add User

Expected Behaviour

The user should be created and assigned the selected role.

Actual Behaviour

Sorry, you are not allowed to give users that role.

Root Cause Analysis

The POST data AAM submits

When the form is submitted, the POST data contains:

[action] => createuser
[user_login] => testuser
[email] => testuser@example.com
[ure_other_roles] =>
[aam_user_roles] => Array
    (
        [0] => subscriber
    )
[createuser] => Add User

Notice: There is no role field. AAM replaces the native <select name="role"> dropdown with its own <select name="aam_user_roles[]"> multi-select to support multi-role assignment.

What WordPress 6.7+ expects

WordPress 6.7 added the wp_ensure_editable_role() function as a security hardening measure. This function is called inside wp-admin/includes/user.php (the edit_user() function) and validates that $_POST['role'] is present and corresponds to an editable role. When the field is missing entirely (as it is when AAM replaces the dropdown), the check fails and triggers wp_die().

Debug backtrace confirming the source

[14-Apr-2026 09:14:49 UTC] === ERROR TRIGGERED ===
Backtrace: wp_ensure_editable_role, __, translate, apply_filters('gettext'), WP_Hook->apply_filters, {closure}
REQUEST_URI: /academy/wp-admin/user-new.php
REQUEST_METHOD: POST

Additional verification performed

• Super Admin status: Confirmed (is_super_admin() returns YES)
• Roles exist on subsite: Confirmed (all 16 roles present in wp_X_user_roles option)
• get_role('subscriber') on the subsite: Returns FOUND
• editable_roles filter output: Returns all 16 roles correctly
• promote_users capability: Present on the administrator role
• Deactivating AAM resolves the issue: Confirmed — user creation works immediately after deactivation
• map_meta_cap bypass: Attempted returning ['exist'] for promote_users — did NOT fix the issue, confirming the error is not a capability check but a direct wp_die() from wp_ensure_editable_role()
• Deactivating all other plugins: Issue persists with only AAM active, confirming AAM is the sole cause

Difference from Issue #180

Suggested Fix

AAM should inject the first selected role from aam_user_roles[] into $_POST['role'] before WordPress core processes the form. This satisfies wp_ensure_editable_role() while still allowing AAM to handle multi-role assignment through its own field afterward.

Example implementation (early hook, before core processes the form):

add_action('admin_init', function() {
    if ($_SERVER['REQUEST_METHOD'] !== 'POST') {
        return;
    }
if (!isset($_POST['aam_user_roles']) || isset($_POST['role'])) {
    return;
}

$roles = (array) $_POST['aam_user_roles'];

if (!empty($roles[0])) {
    $role = sanitize_text_field($roles[0]);

    if (get_role($role)) {
        $_POST['role']    = $role;
        $_REQUEST['role'] = $role;
    }
}

}, 0);

Current Workaround That I had to use on my clients site

You can place the above code as an mu-plugin at wp-content/mu-plugins/fix-aam-role-assignment.php until an official fix is released.