Change User Role on Load

// Schedule the role assignment
//wp_schedule_single_event(time() + 5, 'userwp_role_assignment', array($user_id)); // Delay by 5 seconds
}
add_action('user_register', 'userwp_user_registration_approval',PHP_INT_MAX);
this hook not calling

### 1. **Verify User Registration Process**
– Ensure that the `user_register` hook is relevant to your user registration flow. This hook fires after a new user is created using the core WordPress registration system.
– If you're using a custom plugin (e.g., **UsersWP**) or a third-party plugin for user registration, it might not trigger the `user_register` hook. Check if the plugin provides its own hooks for handling registrations.

### 2. **Priority and Function Setup**
– You're using `PHP_INT_MAX` for the hook priority. While this is valid, it is an unusually high value. Try using a more typical priority (e.g., `10`) to see if the hook fires.
– Example:

add_action('user_register', 'userwp_user_registration_approval', 10);

### 3. **Debugging the Hook**
– Add a debugging line to check if the function is being called:

function userwp_user_registration_approval($user_id) {
         error_log('user_register hook called for user ID: ' . $user_id);
         // Your code here
     }
     add_action('user_register', 'userwp_user_registration_approval', 10);

– Check the `debug.log` file for entries. To enable `debug.log`, add the following to `wp-config.php` if not already done:

define('WP_DEBUG', true);
     define('WP_DEBUG_LOG', true);
     define('WP_DEBUG_DISPLAY', false);

### 4. **Third-Party Plugins Conflicts**
– If you're using **UsersWP** or similar plugins, they might override the registration process and not call `user_register`. Check the plugin documentation or code for alternative hooks, such as:
– `userswp_after_user_register`
– `um_after_user_register` (Ultimate Member)
– Similar hooks depending on your plugin.

### 5. **Custom Registration Process**
– If you have a custom registration form that does not use `wp_insert_user()` or `register_new_user()`, the `user_register` hook might not fire. Ensure your registration process uses these core functions.

### 6. **Hook Call Trace**
– Check if `user_register` is already being used elsewhere in your codebase or by other plugins. This can prevent your function from firing if there are conflicts or conditions preventing it from executing.

### 7. **Example with Plugin-Specific Hooks**
– For **UsersWP**, you can try this hook:

function userwp_user_registration_approval($user_id) {
         error_log('UsersWP registration hook called for user ID: ' . $user_id);
         update_user_meta($user_id, 'aiowps_account_status', 'pending');
         update_user_meta($user_id, 'userwp_account_status', '1');
     }
     add_action('userswp_after_user_register', 'userwp_user_registration_approval', 10);

By following these steps, you should be able to identify why the `user_register` hook is not firing and adapt your code accordingly.

### Implementation

function update_user_role_on_site_load() {
    // Check if a user is logged in
    if (is_user_logged_in()) {
        // Get the current user's ID
        $user_id = get_current_user_id();
        
        // Get the user's data
        $user = get_userdata($user_id);
        
        // Check if the user's role needs to be changed
        if (in_array('pending', $user->roles)) { // Replace 'pending' with your role slug
            // Change the user's role
            wp_update_user(array(
                'ID' => $user_id,
                'role' => 'subscriber' // Replace 'subscriber' with the desired role slug
            ));
        }
    }
}
add_action('init', 'update_user_role_on_site_load');

—

### Explanation of the Code
1. **`is_user_logged_in()`**: Ensures that the function runs only for logged-in users.
2. **`get_current_user_id()`**: Retrieves the current user's ID.
3. **`get_userdata($user_id)`**: Fetches the user's data, including roles.
4. **Role Check**: Checks if the user currently has a specific role (e.g., `pending`).
5. **`wp_update_user()`**: Updates the user's role if the condition is met.

—

### Points to Consider
1. **Performance Impact**:
– Running role updates on every page load might impact performance. Ensure this is strictly necessary.
2. **Avoid Overwriting Unnecessarily**:
– Only update roles when needed to prevent redundant database updates.
3. **Role Logic**:
– Modify the role logic to fit your requirements (e.g., checking specific conditions like metadata or timestamps).
4. **Custom Hooks for Specific Scenarios**:
– Use targeted hooks like `wp_login` if the role update is only needed during user login.

—

### Alternative: Update Role on Login
If changing roles on every page load is unnecessary, you can hook into `wp_login` instead:

function update_user_role_on_login($user_login, $user) {
    if (in_array('pending', $user->roles)) {
        wp_update_user(array(
            'ID' => $user->ID,
            'role' => 'subscriber'
        ));
    }
}
add_action('wp_login', 'update_user_role_on_login', 10, 2);

This will update the user role only when the user logs in, which is more efficient and logical.

### Updated Code

function ogz_uwp_after_process_register( $data, $user_id ) {
    // Get user info
    $user_info = get_userdata($user_id);
    
    // Update user meta as needed
    update_user_meta($user_id, 'aiowps_account_status', 'pending');
    update_user_meta($user_id, 'userwp_account_status', '1');
    update_user_meta($user_id, 'userwp_account_status2', '1');
    
    // Get the user's current roles
    $user_roles = $user_info->roles;
    
    // Remove 'subscriber' role if it exists
    if (in_array('subscriber', $user_roles)) {
        $user_roles = array_diff($user_roles, ['subscriber']);
    }
    
    // Add 'provider' role
    $user_roles[] = 'provider';
    
    // Update the user's roles
    wp_update_user(array(
        'ID' => $user_id,
        'roles' => $user_roles
    ));

    // Optionally, log the changes (if needed)
    // write_log('uwp_after_process_register: ' . "r" . $user_info->user_login . "/r" . $user_info->ID);
}
add_action('uwp_after_process_register', 'ogz_uwp_after_process_register', 10, 2);

### Explanation of Changes:
1. **Get Current Roles**: The user's current roles are fetched using `$user_info->roles`.
2. **Remove Subscriber Role**: If the user has the `subscriber` role, it is removed from the roles array using `array_diff()`.
3. **Add Provider Role**: The `provider` role is added to the roles array.
4. **Update User Roles**: The `wp_update_user()` function is called to update the user's roles.

### Important Notes:
– **Role Existence**: Ensure the `provider` role exists in your WordPress installation. You can create a custom role using `add_role()` if it doesn't exist.

Example:

if (!get_role('provider')) {
      add_role('provider', 'Provider', array(
          'read' => true, // Add capabilities as needed
      ));
  }

– **Logging**: If you want to log user information for debugging, ensure that `write_log()` is a valid function or replace it with `error_log()` to log to `wp-content/debug.log`.

This will change the user's role to `provider` while removing the `subscriber` role every time a user is registered and the `uwp_after_process_register` action is triggered.

"We've checked by disabling click tracking in SendGrid, and the password link works fine in private Chrome. I think we can disable click link tracking in SendGrid. We will also check Cloudflare tomorrow to see if we can resolve the issue there."