bonjour,

j’ai fait un site en local pour gérer une pho­to­thèque et voici la maquette de démonstration : http://​photos​.hor​tical​.com/ (mais ce ne sont pas les vrais photos seulement les vignettes de 500px. Depuis j’ai remis à jour et bricole cause php5.3 qui n’aime pas les ereg

Bonjour Claude,

Je viens d’uploader une version 1.2 du plugin qui supprimer les ereg.

merci Arno*,

je venais de faire qq cor­rec­tions mais comme j’ai juste appris à faire echo avant hier (je dois m’y mettre depuis 5 ans) je vais aller chercher cette version

je viens de me rendre compte d’un pb bizarre : les données (EFIX et IPTC) ne s’affichent plus en public lorsque je retourne une photo !

je pensais que ma mise à jour d’hier soir (en local pas sur la version d’essai dont les vignettes avaient été remises d’aplomb a pos­te­riori) en était la cause avant de voir ces données réap­pa­raitre sur d’autres images.

ps, sur ce site on ne peut pas cliquer en arrière sur le texte sans être éjecté (du coup je n’ose plus revenir sur les pohtes de frappe)

bonjour,

je viens de comprendre.

Dans IMG, l’image change de nom en cas de retour­nement et ainsi une image P123.jpg devient P123-r90.jpg. Reste plus qu’à construire une astuce.

Attention : il est de plus trèèèèès pos­sible que les trai­te­ments gra­phiques fassent dis­pa­raître les données Exif et IPTC. Ce qui fait que ton image « retournée », ou même simple réduire, ne contienne plus les données nécessaires.

À mon avis, il faut que, pour l’affichage des données, tu repartes bien du fichier d’origine (#FICHIER) sans aucun traitement.

bon, j’ai résolu à un détail (non gênant) près,

rappel : dans mon sque­lette article, j’ai un _ [(#INCLURE{fond=pave_exif}{id_article}{id_document}{env})]

et dans ce pave_efix.html côté public (copié depuis le plugin), je rajoute une fonction à #FICHIER de la ligne 3 :

#SET{fichier,#FICHIER|retournee}

dans config/mes_fonctions.php, j’ai installé ma fonction :

donc, dans #SETfichier,#FICHIER je voulais modifier le contenu de #FICHIER qui est de forme "IMG/jpg/P1000070-r90.jpg" en "IMG/jpg/P1000070.jpg"

c’est-à-dire rem­placer les trois expres­sions pos­sibles en cas de retour­nement d’image "-r90.jpg" ou "-r180.jpg" ou "-r270.jpg" par ".jpg"

le détail est juste qu’une image de 3000×2000 passée en ver­tical sera toujours affichée 3000×2000 et non 2000×3000, ce qui ne me gêne nul­lement. Il ne devrait pas être dif­ficile de repérer les "-r90" et "-r270" pour jouer sur l’affichage des dimen­sions. Ce sera peut-​​être pour un autre jour.

Merci Claude pour le site ou l’on peut voir le plugin en action !

Au passage, fina­lement je m’en suis sorti comme ça : _

ensuite la boucle avec : _ [(#GET{datexif})]

dans mes_​fonctions, j’ai mis le code (source) :

Ce qui me donne une date du type jj/​mm/​aa, sauf si le champ exif est vide.

Voilà.

S’il y a plus simple, je suis preneur…

salut a toi !

Je vois que tu dia­logue aussi tout seul … :)

Arrives tu a afficher l his­to­gramme d’une image avec ce plugin, moi non ?

bonne idée la recherche sur les donnees iptc, dis moi si ça fonc­tionne au final svp. _ ++

L’affichage de l’histogramme est désactivé dans l’affichage privé, parce que c’est vraiment lourd comme calcul. Et si tu uploades 20 photos d’un coup (genre un gros Zip dans /​upload), ton serveur est sur les genoux).

Mais la fonction est pré­sente, et il devrait y avoir un sque­lette de démons­tration dans le dossier du plugin.

gros­sière erreur de ma part concernant l’ouverture max et l’ouverture standard, c’est bien normal, j’ai dit une betise !

Pas de réponse, parce que je ne vois pas bien l’intérêt. La 2.0 est désormais très stable, très uti­li­sable, très efficace et il vaut mieux upgrader un site que de down­grader un nouveau plugin.

Il vau­drait mieux, à mon avis, contribuer aux éven­tuels besoin de mise-​​à-​​jour d’anciens plugins qui tournent sur un site 1.9.2 qu’on vou­drait passer en 2.0.

Par ailleurs, le plugin existe le pipeline afficher_contenu_objet qui est propre à la 2.0. Dans une pré­cé­dente version, j’avais bidouillé un jquery qui par­courait les cases du por­folio et char­geait dyna­miquement le pavé d’information. Lourd, lent, pas très viable. Et comme désormais les for­mu­laires d’upload sont en Ajax, il fallait refaire l’opération quand après l’upload dyna­mique d’un nouveau document. Ça tournait à l’usine à gaz, que le nouveau pipeline a résolu proprement.

Merci d’avoir répondu Arno et merci pour ces pré­ci­sions sur le fonc­tion­nement de ce plugin ou de son ancienne version.

 Effec­ti­vement je ne pense pas qu’il soit très viable de s’attaquer à la conversion de ce plugin vers Spip 1.9.2 étant donné que le plugin repose sur l’utilisation d’une pipeline non dis­po­nible sous 1.9.2.

 Par contre je ne com­prend pas ton point de vue quand tu me dis que ce genre de rétro-​​adaptation n’a pas d’interet.

Je pense que Spip 1.9.2 est une version rela­ti­vement Stable uti­lisée par bcp de sites à l’heure actuelle, donc je ne vois pas pourquoi priver ses uti­li­sa­teurs de cer­tains plugins.

Si on com­mence à dire aux gens qui bosse avec Spip qu’il faut toujours déve­lopper sur la der­nière version, pourquoi continuer à main­tenir les anciennes ver­sions ?

Et les Web­mestres, les pauvres, ils vont s’arracher les cheveux à faire des migra­tions sans arrêts…

 Spip étant un projet com­mu­nau­taire, je pense qu’il est important de sou­ligner que chacun peut y contribuer à sa hauteur (je ne gagne pas ma vie grace au developpement)

Je tra­vaille à l’heure actuelle prin­ci­pa­lement pour mon site perso, je fais évoluer les outils qui m’intéresse (comme toi je pense…), donc je rend com­pa­tible ce qu’il me manque pour la 1.9.2.

J’ai été par­ti­cu­liè­rement déçu par l’arrêt de la com­pa­ti­bilité ascen­dante des plugins entre la 1.9.2 et la 2.0 et je pense que je ne suis pas le seul.

L’adaptation du Plugin Mul­ti­viewer doit cer­tai­nement servir à quelques per­sonnes en 1.9.2 autre que moi par exemple.

Il faut penser à tout le monde dans cette his­toire : les déve­lop­peurs n’auraient pas de travail s’il n’y avait pas d’utilisateurs de Spip, donc il faut aussi penser au web­mestre lambda qui cherche juste un fonc­tion­nalité pour son site stable qu’il ne migrera jamais en 2.0.

 Au delà de ces consi­dé­ra­tions, je suis évidemment d’accord pour aller dans ton sens, le jour ou je migrerai vers la 2.0.

Au delà de ces consi­dé­ra­tions, je suis évidemment d’accord pour aller dans ton sens, le jour ou je migrerai vers la 2.0.

Je pige bien, mais : pourquoi ne pas com­mencer par essayer la migration vers la 2.0 (tu te fais une copie du site) avant tout ?

Sur un site rela­ti­vement normal, c’est qua­siment trans­parent. Sur un site plu­ginisé et patché à mort, évidemment ça peut être plus chiant. Mais l’investissement en temps est un appren­tissage car­rément béné­fique. Et si tu aimes patcher et bidouiller, les nou­velles pos­si­bi­lités de SPIP 2 sont une bénédiction…

Evi­demment ok, spip 2.0 a l’air allé­chant et j’y gou­terai un de ces jours, mais c’est toujours la meme chose qui me gene :

 les gens sans connais­sances avancées en infor­ma­tique vont rester bloqué en 1.9.2 sans plus aucun nouveau plugin ou autre dev…

c’est triste pour des gens qui ont choisis une version stable ont pouvait esperer un peu plus de com­pa­ti­bilité, afin qu’ils dis­posent aussi de certain nou­veaux plugins au fur et a mesure du devel­lo­pement de spip.

 du coté de la future migration de mon site en Spip 2.x.x, je pense que ce sera un joli bordel car j’ai effec­ti­vement tra­fiqué le code de spip un peu partout, le sque­lette est bcp trop com­pliqué et pas bien codé pour etre por­table à l’heure actuelle… ça demandera du travail !

 der­niere chose : je vou­drais bien quelque infos pour s’inspirer de ton ancien plugin meta­donnees que tu disais trop lourd, pour creer un éventuel plugin 1.9.2… je sais je suis tétu :)

Linuxiennement,