Mon réseau affiche des rôles sur certains sites et pas sur d'autres.
Pour une raison que je ne peux pas expliquer, lorsque j'ajoute un nouvel utilisateur, je n'ai pas de rôle à choisir dans le menu déroulant d'un sous-site de mon réseau. En outre, mon nouvel utilisateur affecté à un site ne figure pas dans la liste des utilisateurs de ce site.
Est-ce quelque chose de réparable?
Ci-dessous une image de la situation actuelle.
La photo ci-dessous montre le site principal avec les rôles correctement, mais pas les sous-sites du réseau.
wp_##_options
(wp_99_options) - vous aurez une table pour chaque blogoption_name
= wp_user_roles
wp_user_roles
en wp_##_user_roles
("wp_99_user_roles")La table que vous modifiez aura option_id
, blog_id
, option_name
, option_value
, autoload
. Cependant, NE CHANGEZ AUCUN ENREGISTREMENT sauf l'enregistrement où option_name
= wp_user_roles
. Il n'y aura qu'un seul enregistrement dans ce tableau comme celui-ci.
wp_user_roles
est utilisé lorsqu'il n'y a pas d'installation multisite, et ici, il semble qu'il s'agisse simplement d'un bogue lors de la création de la table.
Si tel est le problème que je connais si bien, vous exécutez une configuration memcache derrière votre installation MU? J'ai constaté qu'il y avait apparemment un problème de cache (observé dans la version 2.9) pour l'objet options où quelque chose de positif (comme la clé wp_user_roles) reste bloqué dans le tableau memcache "notoptions".
Si vous exécutez sur memcache et que cela semble être une possibilité, essayez d’appeler telnet dans la machine via 11211. Tapez delete blogid:options:notoptions
, où blogid est l’id du blog sur lequel vous voyez le problème. Actualisez le panneau d'administration et voyez s'il y a des rôles dans la liste déroulante. Si oui, vous avez trouvé votre problème.
UPDATE: OK, vous n'avez donc pas trouvé votre problème - vous n'utilisiez pas Memcache. Je voudrais toujours vérifier l'objet rôles, à la recherche d'un objet corrompu ou inexistant. Je crois que c'est votre meilleure piste. Vous pouvez utiliser ce code pour vider la table d'options:
global $wpdb;
$array = $wpdb->get_col("SELECT option_name FROM $wpdb->options");
foreach ($array as $key) {
echo $key . ": <code>";
var_dump(get_option($key), true));
echo "</code><br/>";
}
J'ai eu ce problème avec une installation multisite après la réinstallation de WordPress et la restauration à partir d'une sauvegarde Updraft Plus.
Lorsque j'ai vérifié l'enregistrement user_roles
, l'option_name était toujours définie sur le préfixe d'origine à quatre caractères, tel que pre1_user_roles
, alors que le préfixe de la deuxième installation était quelque chose comme pre2_user_roles
.
J'ai mis cela à jour avec pre2_user_roles
et les options sont immédiatement réapparues dans la page des options de l'utilisateur.
JE VOUS REMERCIE. Ce problème représente 10 heures de débogage. C'était un vrai ours pour moi.
Pour développer un peu ce sujet, j'ai ajouté une fonction à mon site qui vous permettra de résoudre ce problème si vous créez des sites par programme.
En gros, cela vérifiera si wp_user_roles
a été défini dans le blog spécifié. Si tel est le cas, la fonction utilisera wp_user_roles
pour définir une nouvelle option de manière correcte.
/**
* Sometimes, user roles do not properly get set when a new site is set up
* To fix this issue, we check to make sure the data is added properly and update if not
* See https://wordpress.stackexchange.com/questions/11725/why-are-my-roles-not-visible-in-a-multi-site-network
*/
function maybeAddUserRoles($blog_id){
switch_to_blog($blog_id);
if(get_option('wp_user_roles')){
update_option('wp_'.$blog_id.'_user_roles', get_option('wp_user_roles'));
delete_option('wp_user_roles');
}
restore_current_blog();
}
Je voulais juste vous remercier pour cet article parce que je cherchais une solution à ce problème depuis longtemps.
C'était simplement parce que j'avais utilisé un plugin pour cloner mes sites et que celui-ci n'avait jamais mis à jour correctement le wp_##_user_roles
. Lorsque le site copié à partir de wp_13...
, il a été cloné sur un nouveau site wp_81...
mais cette entrée était toujours bloquée à wp_13
.
Je tiens simplement à souligner que certaines personnes peuvent toujours avoir une table des utilisateurs du site vide, spécialement pour leur site racine. Si ce problème se produit, la solution au problème consiste à:
Je crois que "1" est toujours l'ID du site racine.
À votre santé.