Recalculer quoi !?
Mais si, vous savez les compteurs des utilisateurs, triés par rôles dans la page des utiilsateurs de la partie administration !
Il se peut que vous ayez un compteur indiquant (1) – ou 1 de trop, alors que vous n’avez pas – ou moins, de membre associé à ce rôle. Ici pour mon exemple, vous avez supprimé le compte Momo qui était Moderator.
Pourtant, WordPress continue de le prendre en compte.
Comment est-ce possible ?
Et bien, souvenez-vous !
Il se pourrait que vous soyez allé dans la base de données, avec phpMyAdmin avec un plugin portable par exemple, puis que vous ayez supprimé un utilisateur depuis la table wp_users.
Mais avez-vous supprimé les champs des données de cet utilisateur dans la table wp_usermeta ? Pas sûr…
Et c’est là tout le problème, car WordPress ne fait pas de lien entre le nombres de rôles trouvés dans les données utilisateur. Voici un extrait du core :
* Count number of users who have each of the user roles. * Assumes there are neither duplicated nor orphaned capabilities meta_values.
WordPress ne fait que compter les rôles trouvés dans la table wp_usermeta sans tester si l’utilisateur existe encore. Légitime quelque part car vous ne devez normalement pas intervenir de cette façon dans les tables de WordPress. En tout cas, à vos risques et périls…
La preuve, je suis ici pour vous en parler.
Comment régler ce problème de compteur ?
2 solutions comme souvent : une requête MySQL ou une fonction PHP.
#1 – Exécuter une requête MySQL
Ouvrez votre gestionnaire de base de données phpMyAdmin puis exécutez la requête suivante – en prenant soin de remplacer wp_ par votre préfixe de base données WordPress :
Cette requête va effacer tous les champs de la table wp_usermeta dont l’ID du membre associé n’est pas dans la table wp_users.
Autrement dit, les champs qui auraient dû être supprimés le seront ici !
#2 – Créer une fonction PHP
Autre solution pour ceux qui sont frileux du phpMyAdmin ou qui n’y ont tout simplement pas d’accès, voici le code à copier dans le fichier functions.php de votre thème :
Puis raffraichissez le panneau administrateur. Si le requête s’exécute plusieurs fois, rien de grave, les prochaines fois ne servent juste à rien.
Vous pouvez supprimer le code de votre fichier maintenant !
Comment prévenir ce problème à l’avenir ?
Si effacer le membre n’est pas possible pour X raisons depuis l’administration de WordPress, exécutez alors ces 2 requêtes, ici pour l’utilisateur dont l’ID est 123 :
Ou pour dans votre functions.php :
Edit: ScreenFeed nous parle de wp_delete_user() qui a l’avantage de réassigner les articles à un autre utilisateur, excellente idée, voici le code :
Au terme de ce tutoriel, vous serez en mesure de résoudre ce problème de comptabilité. J’attends vos commentaires avec impatience !
Bien vu 🙂
Pour ma part je préfèrerais utiliser wp_delete_user() qui a l’avantage de réassigner les posts du user si besoin (ou de les supprimer) 😉
Option 4 : passer par l’administration 😀
Tout à fait, merci d’y avoir pensé à ma place :p
J’ai édité l’article pour ajouter le code à fournir.
A bientôt !
Je n’ai jamais utilisé cette fonction donc je ne connais pas son comportement dans les moindres détails (et je suis pas allé fouiner dans le core) mais imagine que le user 1 n’existe pas (je sais on ne peut pas patcher la bêtise comme tu dis, mais une étourderie est vite arrivée), donc je ne sais pas ce qu’il se passe si elle ne trouve pas le user à qui réassigner les posts.
Hypothèse : elle les supprime, ne faudrait-il pas alors vérifier que ce user 1 existe avant? Histoire de ne pas perdre tous les posts par une simple faute de frappe ou autre.
Tu as raison et je vais même un peu plus loin en vérifiant que l’utilisateur a les droits de suppression.
Code édité de nouveau.