Je ne sais pas quand il faut ouvrir un ticket... donc je passe par cette liste.
Quand on cree une nouvelle traduction d'article, le texte et les images suivent bien mais pas les documents du portfolio.
Vu que spip permet maintenant d'ajouter des images lors de la creation de l'article (alors qu'il n'a pas de numero), il serait logique que quand on cree un article a traduire, cela se passe de la meme facon.
Rajouter dans la fonction articles_edit
si $lier_trad est renseigne, on duplique les entrees de spip_documents_liens qui ont le num d'article de $lier_trad avec un article a (0-id_auteur)
Rajouter dans la fonction articles_edit
si $lier_trad est renseigne, on duplique les entrees de spip_documents_liens
qui ont le num d'article de $lier_trad avec un article a (0-id_auteur)
le risque ici c'est qu'un auteur ouvre plusieurs articles en
traduction, puis quand il valide, le premier article validé "récupère"
tous les documents. Je crois qu'il vaut mieux insérer ces liens au
moment de la création de l'article traduit (donc, à la validation du
formulaire).
Oui, c'est evident que ca serait plus logique. Mais c'est deja comme ca que c'est realise dans articles_edit avec ce commentaire :
# ICI GROS HACK
# -------------
# on est en new ; si on veut ajouter un document, on ne pourra
# pas l'accrocher a l'article (puisqu'il n'a pas d'id_article)...
# on indique donc un id_article farfelu (0-id_auteur) qu'on ramassera
# le moment venu, c'est-a-dire lors de la creation de l'article
# dans editer_article.
Oui, c'est evident que ca serait plus logique. Mais c'est deja comme ca que
c'est realise dans articles_edit avec ce commentaire :
C'est proche, mais le contexte d'usage n'est pas exactement le même ;
là il s'agit de pouvoir uploader des docs dans un article qu'on est en
train de créer. Cela dit, en effet, avec ma méthode les liens de docs
ne s'afficheraient pas dans la marge lors de la création de la
traduction. Sauf à tester si on est précisément dans ce scénario, et à
remplacer alors la colonne de des docs (0-$id_auteur) par celle des
docs (article d'origine).
Le hack en question est pratique, mais il atteint vite ses limites
Je proposais cette solution car on est dans la meme configuration a un moment donne :
1. un article nouveau (donc sans id) avec une colonne de gauche dans laquelle on a deja charge des docs
2. un article de traduction (sans id non plus) avec une colonne de gauche dans laquelle sont precharges (via mediatheque, sinon on ne les voit pas) les docs joints a l'article d'origine
A ce moment la, on est dans les 2 cas dans la meme config. Sauf que dans le cas 2, comme on n'est pas passes par le formulaire d'ajout de docs, la table spip_documents_liens n'est pas renseignee avec (0-$id_auteur). Donc faudrait quand on demande la creation d'une traduction, mettre a jour cette table.
2. un article de traduction (sans id non plus) avec une colonne de gauche
dans laquelle sont precharges (via mediatheque, sinon on ne les voit pas)
les docs joints a l'article d'origine
donc le core ne fait rien, et la médiathèque n'a fait que la moitié du
job, si je comprends bien. A ce compte-là c'est sans doute dans la
médiathèque qu'il faut faire le patch. Ou alors, si c'est
insatisfaisant, faire le patch complet dans le core (mais pas juste
l'autre moitié en complément de la médiathèque).
A ce moment la, on est dans les 2 cas dans la meme config. Sauf que dans le
cas 2, comme on n'est pas passes par le formulaire d'ajout de docs, la table
spip_documents_liens n'est pas renseignee avec (0-$id_auteur). Donc faudrait
quand on demande la creation d'une traduction, mettre a jour cette table.
même si ce n'est pas la meilleure réponse, ce sera en effet toujours
mieux que l'existant
2. un article de traduction (sans id non plus) avec une colonne de gauche
dans laquelle sont precharges (via mediatheque, sinon on ne les voit pas)
les docs joints a l'article d'origine
donc le core ne fait rien, et la médiathèque n'a fait que la moitié du
job, si je comprends bien. A ce compte-là c'est sans doute dans la
médiathèque qu'il faut faire le patch. Ou alors, si c'est
insatisfaisant, faire le patch complet dans le core (mais pas juste
l'autre moitié en complément de la médiathèque).
Ca me semble plus logique de tout faire dans le core. Et je n'ai pas reussi a trouver comment la mediatheque arrive a afficher ces docs du portfolio de l'article de reference. Ne connaissant pas assez bien le systeme dans l'ensemble, je me suis dit, ben faut p'tet faire un ticket ,-)
