Avant SPIP 3.0.11, SPIP prenait dans un tel cas les documents attachés au mots.
Mais en http://zone.spip.org/trac/spip-zone/changeset/74303/, croyant bien faire, et ne connaissant pas l'article de Marcimat, et mettant une coquille dans le log de commit (lire DOCUMENTS et pas EVENEMENTS), j'ai changé le comportement, ce qui impacte toutes les versions de spip > 3.0.11
Question à trois sous:
- on considère que ce qui est fait est fait, et on modifie les docs en conséquences?
- ou bien ou on fait un revert, et on modifie les docs en conséquences?
Amha il faut annuler la modification et vérifier que cela ne casse rien dans le medias. À moins qu'on considère que celle-ci est corrige bien un bug..
ca cassera nécessairement {id_mot} sur (DOCUMENTS). La question qui se pose est de savoir quel est la compréhension la plus "spontanée" de {id_mot} sur (DOCUMENTS). Sachant que {id_mot} correspond en général à "je cherche l'objet auquel le mot clef est attaché", la nouvelle version correspond plutôt à cela. Mais par contre ca va à contre courant de la doc de Marcimat
.
Je parlais bien de vérifier que cela ne casse rien dans le plugin medias, il est évident que ça cassera des boucles dans la nature, mais le mal est déjà fait de ce côté.
c'est une coquille de ma part. Cela étant, il serait bon je pense, si on revient en arrière, de préciser que entre la version xxx et la version yyy, le comportement est inverse
Je commence à m'y perdre avec toutes ces coquilles
je pense qu'il faut rétablir par principe ici, car en pratique cela doit toucher peu de sites (le fait est qu'on a pas eu de remontée du changement de comportement).
Par contre amha il faudrait que le compilateur lance une erreur "jointure ambigue" en cas ou 2 tables de liens sont possibles, pour forcer a lever l'ambiguite du critere de boucle dans le squelette.
