J'ai créé le plugin pour gérer ceci, avec les bémols déjà évoqués. :)
[extension by Criss] CommentEditor
Hors ligne
Criss a écrit:
J'ai créé le plugin pour gérer ceci, avec les bémols déjà évoqués. :)
[extension by Criss] CommentEditor
Tu devrais créer un nouveau fil pour ton plugin
Hors ligne
nicolas va pouvoir identifier ce qu'il te manque pour aller plus loin...
Merci.
;-)
Hors ligne
ddtddt a écrit:
Criss a écrit:
J'ai créé le plugin pour gérer ceci, avec les bémols déjà évoqués. :)
[extension by Criss] CommentEditorhttp://illiweb.com/fa/i/smiles/icon_thumleft.png
Tu devrais créer un nouveau fil pour ton plugin
Je le fais de suite. :P
Hors ligne
VDigital a écrit:
nicolas va pouvoir identifier ce qu'il te manque pour aller plus loin...
Merci.
;-)
Sans problème, j'ai vu au moins 2 "manquements" dans le core pour être "propre". ;)
Le topic dédié: http://fr.piwigo.org/forum/viewtopic.php?id=15671
Hors ligne
Criss a écrit:
Bon j'ai un petit peu avancé.
moi aussi !
Criss a écrit:
Si une modification du core de piwigo est déjà bien avancée, dites-le que je ne prenne pas trop la tête à chercher des détails ;)
C'est bien avancé mais je n'ai pas tout à fait terminé. Malgré tout ton plugin permet de "résoudre" le problème tout de suite.
p.s: je continue la discussion sur le topic dédié.
Hors ligne
Notice: Undefined variable: userList in ./plugins/extension_296/classes/ce_comment.class.php on line 53
Warning: array_change_key_case() [function.array-change-key-case]: The argument should be an array in ./plugins/extension_296/classes/ce_comment.class.php on line 53
Warning: array_key_exists() [function.array-key-exists]: The second argument should be either an array or an object in ./plugins/extension_296/classes/ce_comment.class.php on line 53
Piwigo encountered a non recoverable error
make_picture_url: image_id is a required parameter
#1 make_picture_url ./include/functions_url.inc.php(200)
#2 duplicate_picture_url ./plugins/rv_akismet/check.inc.php(15)
#3 akismet_user_comment_check ./plugins/rv_akismet/main.inc.php(35)
#4 akismet_user_comment_check_wrapper ()
#5 call_user_func_array ./include/functions_plugins.inc.php(141)
#6 trigger_event ./plugins/extension_296/include/ce_functions.inc.php(109)
#7 update_user_comment ./plugins/extension_296/classes/ce_plugin.class.php(155)
#8 CE_Plugin::updateComment ./plugins/extension_296/classes/ce_plugin.class.php(57)
#9 CE_Plugin::loc_end_index ()
#10 call_user_func_array ./include/functions_plugins.inc.php(181)
#11 trigger_action ./index.php(29)
Il va falloir comprendre ça... ;-)
./plugins/extension_296/classes/ce_comment.class.php on line 53
Soit ici
A la validation de l'Edition par l'admin d'un commentaire d'un non membre.
Hors ligne
T'es pas le seul à l'avoir vu, je réponds dans le topic dédié ;)
Hors ligne
Je viens de faire le commit de la nouvelle fonctionnalité ([Subversion] r3445). J'ai pas mal testé mais il reste sûrement des bugs. Lâchez-vous! :-)
p.s: Si certains veulent tester pour de vrai, sans rien installer, dîtes moi et je vous donnerais un accès à ma galerie.
Hors ligne
Je t'ai envoyé un petit MP.
Hors ligne
Suite à la conversation avec nicolas par MSN, voila ce que je propose:
- La colonne author de la table des commentaires devient author_name
- On rajoute une colonne author_id
A partir de la 2.1, si un utilisateur enregistré poste un commentaire, author_id sera renseignée par l'id de l'utilisateur, et author_name sera null.
Si c'est un guest qui poste un commentaire, ca sera l'inverse: author_name sera renseigné et author_id sera null.
Pour moi, c'est bonne et la seule solution possible. Tous les commentaires existants seront bien sur conservés lors de la migration. Les utilisateurs ne pourront par contre pas modifier leurs anciens commentaires, puisqu'on ne pourra pas ratacher un nom d'auteur avec un userid.
Il faudra également prévoir le cas de la suppresion d'un utilisateur... Est-ce qu'on supprime aussi tous ces commentaires? (je ne pense pas...)
Il faudra que author_id soit effacé et author_name renseigné dans ce cas pour tous ses commentaires. Problème: cas d'une table users externe, gérée par un autre programme.
Solution: renseigner systématiquement la colonne author_name, meme pour un utilisateur enregistré (moins propre, mais efficace)
Dernière modification par P@t (2009-06-23 18:19:00)
Hors ligne
P@t a écrit:
(...)
Il faudra également prévoir le cas de la suppresion d'un utilisateur... Est-ce qu'on supprime aussi tous ces commentaires? (je ne pense pas...)
(...)
Je ne pense pas non plus mais la possibilité devrait être proposée optionellement (config_local.inc.php ou BDD ?). Car prenons le cas d'un visiteur inscrit qui devient... disons, "indésirable" par le fait même de la teneur des commentaires qu'il aura posté. Et, cet indésirable a été très prolixe dans la quantité de commentaires déposés.
L'admin de la galerie apprécierait de pouvoir supprimer le compte du malotru *et* tous ses commentaires.
Je ne parle pas de spam, bien entendu. Mais bien d'une personne qui était bien sous tous rapports au début et dont le comportement se serait dégradé par la suite.
[Mode avocat du diable = On]
Mais l'admin a la possibilité de valider les commentaires avant mise en ligne effective? Donc cette situation ne devrait pas se produire.
[Mode avocat du diable = Off]
Sauf que selon les webmestres en herbe (ce n'est pas péjoratif ! Nous l'avons tous été pendant une période plus ou moins longue), la validation des commentaires n'est pas forcément activée.
;-)
Hors ligne
Je pense que supprimer les commentaires du "dit" membre se décide au cas par cas (donc pas une option générale).
Et par défaut, c'est on ne supprime rien du tout.
Parce que d'autres membres ont pu répondre à ses commentaires, et supprimer l'original revient à rendre leurs propos inconsistants.
;-)
PS: Askimet fait 80% du boulet que je suis.
Hors ligne
[EDIT]
Grillé... encore...
[/EDIT]
Mais surtout que le vilain petit canard peux éditer ses commentaires après validation ^^
Si on suprime un USER, ce n'est pas le fruit d'un hasard et ça simplifierai la gestion des commentaires si on ne conservait pas ses commentaires.
Si l'admin veut les conserver, c'est simple: il change les caractéristiques du compte en question pour se l'approprier et du coup, bloquer l'individus indésirable :-)
Dernière modification par Gotcha (2009-06-23 19:29:59)
Hors ligne