cela fait longtemps qu’il y a des discussions au sujet des modèles d’incrustation des documents, liés entre autre à un comportement différent selon les modes (portfolio ou non) des images, etc.
Dans le cadre du passage à SPIP 3, que faire de cette proposition :
cette série de modèles restent clairement distincte des modèles actuels avec un appel de la forme ?
réécrire le plugin pour utiliser des appels de la forme <doc12|icone>, <doc45|embed>, … (ce que plusieurs personnes m’ont demandé informellement aux grottes) ?
continuer de proposer cette nouvelle fonctionnalité dans un plugin séparé ou
intégrer ces nouveaux modèles dans la médiathèque (sachant que les modèles historiques sont fournis dorénavant par cette dernière) ?
Dans tous les cas, il y aura maintien des raccourcis historiques et de leur comportement ainsi que le développement d’outils pour le passage d’un système à l’autre pour ceux qui le souhaitent.
Je ne sais si mon message est bien placé dans cette liste ou s'il faudrait ouvrir un ticket...
J'ai eu un problème avec la transposition des noms de tables faites par le noyau dans le cas où un préfixe autre que spip_ a été choisi à l'installation. Dans deux requêtes, j'avais une 'count(spip_xxx.id)' et dans l'autre 'JOIN spip_xxx ON (spip_xxx.id = ...)' qui n'étaient pas transposées. En regardant dans le code j'ai vu que spip_ doit être précédé d'une virgule ou d'un espace pour être transposé.
Est-ce qu'il ne faudrait pas ajouter le cas où le nom de table est précédé d'une parenthèse ? Est-ce que ça pourrait avoir des effets de bords gênants ? Et ne faudrait-il pas documenter plus précisément le mécanisme de transposition dans Programmer SPIP ?
Il est d'usage d'utiliser systématiquement un alias :
select count(xxx.id) FROM spip_xxx AS xxx JOIN spip_yyy AS yyy ON xxx.id_xxx=yyy.id_xxx WHERE ....
Sans alias, le remplacement de toutes les occurrences possibles est un problème complexe, qui risque d'entrainer des effets de bord négatif.
Oui, effectivement, d'ailleurs le code que tu as pris en exemple est celui que j'ai corrigé il y a trois jours.
Je suis bien d'accord qu'on s'en tire avec des alias, c'est ce que j'ai fait. Mais une ch'tiote mention dans Programmer SPIP avec la doc des fonctions sql_* me semblerait tout de même utile.
Je ne sais si mon message est bien placé dans cette liste ou s'il
faudrait ouvrir un ticket...
Sur la liste ça va, mais par contre tu aurais dû écrire un nouveau mail
au lieu de répondre à celui de Joseph posté juste avant. Sur mon client
mail par exemple je vois ton message comme une réponse à celui de
Joseph.
Je ne savais même pas que le message portait encore la trace de mon
coupable "Répondre à la liste..."
Je me méfierai maintenant.
(Et merci : ça fait des années que je fais des "Répondre à" en
nettoyant seulement l'objet et le contenu du message)
Explication technique de la fameuse "trace". Regarde les en-têtes des
mails que tu reçois ou envoies :
- Il y en a un qui est Message-ID: cet en-tête est placé par le client,
son contenu est généré de façon à être unique, et il est présent sur
absolument tous les mails qu'on envoie.
- Un autre en-tête est In-Reply-To, qui indique le Message-ID du mail
auquel on répond. Quand tu cliques sur "répondre" ou "répondre à la
liste", cet en-tête est placé par ton client.
Du coup même changer le sujet n'enlève pas l'information de "parenté",
car ce n'est pas le sujet mais l'en-tête In-Reply-To qui la contient.
D'ailleurs, le célèbre "Re: blablabla" est un sujet par défaut mais
n'est pas nécessaire. Il est même conseillé de changer le sujet pour
quelque chose de plus pertinent et davantage en rapport avec le contenu
réel du mail qu'on envoie ; c'est notamment vrai quand une discussion
dérive vers une autre thématique. C'est ce que fais ici, et que
j'aurais dû faire dans ma première réponse d'ailleurs.
