- Statut : non résolu
- Ce sujet contient 16 réponses, 4 participants et a été mis à jour pour la dernière fois par
, le il y a 11 années et 8 mois.
-
Messages
-
Bonjour,
Ma configuration WP actuelle
– Version de WordPress : 3.3.1
– Version de PHP/MySQL : 5
– Thème utilisé : Twenty ElevenProblème(s) rencontré(s) :
avant de reporter un bug dans le trac de WordPress (chose que je n’ai jamais faite d’ailleurs), j’aimerais exposé un bug dont je suis enfin parvenu à identifier l’origine. Cela dure depuis plus d’1 an.
Actions effectuées :
– Créer un nouveau compte utilisateur (exemple : admin) ;
– Ouvrir phpMyAdmin puis supprimez un compte dans wp_users ;
– Retournez sur la liste des utilisateurs dans le back office de WordPress ;BUG : le compteur d’utilisateur n’est pas mis à jour !
Est-ce normal ? Des idées ?
Merci de m’indiquer ce que je dois faire pour améliorer WordPress. 😉
Rhooooo c’est un peu pervers de faire ça 🙂
Sinon quelles sont les conséquences, le compteur est il remis à jour en rajoutant un user?
Oué je sais c’est tordu mais dès fois on doit en passer par là…
Et justement non quand je créé un nouveau compte le décalage est toujours présent. Au début, j’ai cru à un utilisateur pirate non identifié ! 🙂
Je viens de tester en local, avec un WP 3.3.1 et le thème Arras (je ne sais si cela influence le problème ?)
Et je n’ai aucun problème !
– J’ai créé un nouvel utilisateur ayant un rôle Contributeur (donc différence avec toi)
– j’ai ouvert ma base et supprimer cet utilisateur
– j’ai ouvert l’administration de mon WP
– Dans la liste des utilisateurs, il n’y a plus l’utilisateur supprimé dans la base
Tout va bien dans mon test
🙂Je reviens de faire un test avec un nouvel utilisateur ayant un rôle Administrateur et ayant écrit un article.
De nouveau pas de souciNON ! Effectivement mes compteurs ne se mettent pas à jour !
J’ai Contributeur (1) et à l’affichage la liste est bien vide !
J’ai Administrateur (2) et à l’affichage j’en ai qu’un seul !
😕A mon avis, les compteurs devraient se mettre à jour au moins en suppression/ajout, je comprends qu’ils aient voulu se passer d’une requête qui retournera presque toujours la même chose, mais cela n’aurait pas été couteux de réinitialiser le compteur pour une modification. Maintenant… je ne sais pas si cela sera dans leurs priorités, fais un plugin pour le corriger 🙂 je n’ai jamais regardé comment étaient déterminés les id des users.
Il est normal que les compteurs ne se mettent pas à jour. En plus de la table wp_users, il y a la table wp_users_meta où sont stockés les autorisations (user level et capabilities)
Donc la requête trouve toujours « x » enregistrements correspondant à la capacité administrateurs.
Il faut nettoyer les deux tables en même temps
« It’s not a bug, it’s a feature »
OK merci à tous de vos réponses ! Cela m’aura évité de faire une bourde en postant un pseudo bug sur le trac WordPress. ✅
« a feature » je ne suis pas certain. Qu’une table (appelée meta) fasse référence à un user qui n’existe pas… il me semble que quelque chose au niveau de la modélisation, de la validation et du contrôle des données est passé au travers.
On ne devrait pas pouvoir additionner ou lister des données additionnelles d’une clé inexistante sans avoir au minimum un message d’info.Guy wrote:« a feature » je ne suis pas certain. Qu’une table (appelée meta) fasse référence à un user qui n’existe pas… il me semble que quelque chose au niveau de la modélisation, de la validation et du contrôle des données est passé au travers.
On ne devrait pas pouvoir additionner ou lister des données additionnelles d’une clé inexistante sans avoir au minimum un message d’info.Ah… je ne sais que faire alors. Je reporte ?
Avant de te répondre, je suis quand même allé voir comment ils comptaient les utilisateurs à l’affichage dans le panneau d’administration.
Et… cela tendrait à prouver qu’effectivement, ils l’ont fait comme ça par design en connaissance de cause et ne le changeront pas. Dans le source, en entête de la fonction retournant les valeurs, on trouve :
* Assumes there are neither duplicated nor orphaned capabilities meta_values.
C’est ainsi, et je ne ferai donc pas de commentaires sur la modélisation de la base 🙂
@Guy, de base tu peux faire ce que tu veux dans une base de données quand tu es en accès direct. Les contrôles sont effectués dans le cadre des procédures wordpress et des fonctions.
Sinon, tu dois répliquer un certain nombre de ces contrôles dans les procédures MySQL, ce qui est partiellement possible mais
1. beaucoup plus lourd
2. interdit à l’inverse un certain nombre d’interventions d’urgences dans la baseOn est sur une base de données MySQL. Les indexes existent, et dans les tables meta et dans les tables users. En revanche le contrôle d’intégrité tel qu’il existe dans les bases Access, ça n’existe pas.
Le design de la base, par ailleurs, permet un autre type de sécurité, puisque le meta capabilities est spécifique à une base, précédé du préfixe de base, ce qui aurait été impossible en mettant les capabilities directement dans la table user. Par ailleurs, pour le multiblog, cela permet de gérer plusieurs niveaux d’autorisations selon les blogs, pour un même user.
Moi je la trouve très bien cette modélisation ^^
(on peut reprocher beaucoup de choses à wordpress dans l’organisation de son code, mais la modélisation de la base de données est puissante)
Ce que tu critiquerais éventuellement n’est pas la modélisation de la base, mais la requête directe sur wp_users_meta sans rajouter un join sur wp_users ^^
Après je dis que ça n’est pas un bug, parce que ça marche « comme prévu », mais ça n’empêche pas de demander de l’améliorer 🙂
- Vous devez être connecté pour répondre à ce sujet.