Si j'ai bien compris, P@t, tu proposes de renommer la colonne author en author_name et d'ajouter une colonne author_id simplement pour gérer le cas des invités (guest) et ainsi récupérer leur nom. Je propose pour éviter de devoir faire une migration, de simplement ajouter la colonne author_id et de garder la colonne author.
Je ne garde pas le principe de l'author_id null. Je le mets à la valeur de $conf['guest_id'] comme ça on a la même logique pour tous les auteurs.
Et si l'auteur est égal à null alors le commentaire a été posté avant la migration et on ne peut pas savoir si c'est un membre ou un invité.
Qu'en pensez-vous ?
Hors ligne
nicolas a écrit:
Si j'ai bien compris, P@t, tu proposes de renommer la colonne author en author_name et d'ajouter une colonne author_id simplement pour gérer le cas des invités (guest) et ainsi récupérer leur nom. Je propose pour éviter de devoir faire une migration, de simplement ajouter la colonne author_id et de garder la colonne author.
Je ne garde pas le principe de l'author_id null. Je le mets à la valeur de $conf['guest_id'] comme ça on a la même logique pour tous les auteurs.
Et si l'auteur est égal à null alors le commentaire a été posté avant la migration et on ne peut pas savoir si c'est un membre ou un invité.
Qu'en pensez-vous ?
Impeccable ;-)
Hors ligne
1 - J'aime.
2 - Celui qui change le guest_id devra en tenir compte... Il pourra également faire machine arrière.
3 - Un post récent évoquait plusieurs Guest_id possible en fonction du sous-domaine.
Quid des commentaires? Je crois que cela ne change rien...
P@t?
(Il me semble que c'est toi qui avait proposé ça...)
Hors ligne
VDigital a écrit:
Quid des commentaires? Je crois que cela ne change rien...
P@t?
(Il me semble que c'est toi qui avait proposé ça...)
Je pense aussi que ça ne change rien. Un utilisateur (un vrai, pas un ivité) pourra éditer/supprimer ses messages que s'il lui appartienne, en se basant sur son user_id et sur author_id. Pour le cas de l'utilisateur ayant posté avec un pseudo et s'enregistrant après sous le même pseudo, il ne pourra pas editer/supprimer ses anciens messages.
Hors ligne
Je viens de faire la mise à jour de la base. ([Subversion] r3450)
Du coup, on a un comportement qui peut sembler étrange.
Avant la migration (r3450), un utilisateur légitime (pas guest) poste un commentaire. Il peut le modifier.
Après la migration, il ne peut plus modifier ces anciens commentaires. En revanche s'il crée de nouveaux commentaires, il pourra bien entendu les modifier/supprimer.
Mais en fait c'est parfaitement normal du fait du choix que l'on a fait. On se base désormais sur author_id pour savoir si le commentaire nous appartient et avant la migration ce champ était vide.
Hors ligne
Ca me semble logique. Bon les gens vont râler et ne pas comprendre, mais on n'a pas vraiment le choix. :D
Hors ligne
En même temps, avant tu ne pouvais pas
Et puis tu ne vas pas relire les commentaires 2 jours après pour les modifier !
Hors ligne
Nico,
De souvenir il me semble qu'on n'utilise jamais en direct les colonnes id, username de la table users. On passe par $conf['user_fields']['id'] et $conf['user_fields']['id'] et $conf['user_fields']['username']...
Je ne m'en sert pas, mais ca doit etre pour pouvoir partager la liste des utilisateurs avec un autre cms/blog etc...
Aussi il me semble qu'il faut appliquer un htmlspecialchars au contenu qu'on edite. Sinon on ne pourra jamais editer comme il faut un commentaire de style
a</textarea>b
Hors ligne
$conf['user_fields']: Excellente remarque que je vais appliquer à un de mes plugins (Pan sur le bec!).
Hors ligne
VDigital a écrit:
$conf['user_fields']: Excellente remarque que je vais appliquer à un de mes plugins (Pan sur le bec!).
Ah tiens faut que je regarde moi aussi...
Sinon as-tu revu une interaction entre le plugin CommentEditor et Aksimet ?
Hors ligne
Merci Radu. C'est corrigé ([Subversion] r3452). Comme dit Criss, on ne peut pas connaître tout le code et je ne connaissais pas bien cette subtilité.
Sinon j'ai bien fait l'équivalent d'un htmlspecialchars avant l'édition du commentaire !
Hors ligne
Criss a écrit:
VDigital a écrit:
$conf['user_fields']: Excellente remarque que je vais appliquer à un de mes plugins (Pan sur le bec!).
Ah tiens faut que je regarde moi aussi...
Sinon as-tu revu une interaction entre le plugin CommentEditor et Aksimet ?
Je n'ai pas regardé pour l'instant mes priorités ne sont pas sur le web actuellement... ;-)
Hors ligne
Comme je te comprends :P
Hors ligne
Et un dernier point sans importance majeure ... les regles des codages qq part disent qu'il faut utiliser 2 espaces comme tabulation. Hors sur ton editeur t'utilises des tabs (probablement configures a 8 espaces)...
Hors ligne
rvelices a écrit:
Et un dernier point sans importance majeure ... les regles des codages qq part disent qu'il faut utiliser 2 espaces comme tabulation. Hors sur ton editeur t'utilises des tabs (probablement configures a 8 espaces)...
Normalement les tabs sont sauvés comme des espaces, mais ils sont à 4 oui. :)
Hors ligne