bonjour,

j’ai fait un site en local pour gérer une photothèque et voici la maquette de démonstration : http://photos.hortical.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 corrections 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 posteriori) en était la cause avant de voir ces données réapparaitre 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 retournement et ainsi une image P123.jpg devient P123-r90.jpg. Reste plus qu’à construire une astuce.

Attention : il est de plus trèèèèès possible que les traitements graphiques fassent disparaî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 squelette 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 remplacer les trois expressions possibles en cas de retournement d’image "-r90.jpg" ou "-r180.jpg" ou "-r270.jpg" par ".jpg"

le détail est juste qu’une image de 3000x2000 passée en vertical sera toujours affichée 3000x2000 et non 2000x3000, ce qui ne me gêne nullement. Il ne devrait pas être difficile de repérer les "-r90" et "-r270" pour jouer sur l’affichage des dimensions. Ce sera peut-être pour un autre jour.

Au passage, finalement 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 dialogue aussi tout seul ... :) Arrives tu a afficher l histogramme d’une image avec ce plugin, moi non ?

bonne idée la recherche sur les donnees iptc, dis moi si ça fonctionne 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 squelette de démonstration dans le dossier du plugin.

grossiè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 utilisable, très efficace et il vaut mieux upgrader un site que de downgrader un nouveau plugin.

Il vaudrait mieux, à mon avis, contribuer aux éventuels besoin de mise-à-jour d’anciens plugins qui tournent sur un site 1.9.2 qu’on voudrait 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 parcourait les cases du porfolio et chargeait dynamiquement le pavé d’information. Lourd, lent, pas très viable. Et comme désormais les formulaires d’upload sont en Ajax, il fallait refaire l’opération quand après l’upload dynamique 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écisions sur le fonctionnement de ce plugin ou de son ancienne version.

 Effectivement 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 disponible sous 1.9.2.

 Par contre je ne comprend 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 relativement Stable utilisée par bcp de sites à l’heure actuelle, donc je ne vois pas pourquoi priver ses utilisateurs de certains plugins.

Si on commence à dire aux gens qui bosse avec Spip qu’il faut toujours développer sur la dernière version, pourquoi continuer à maintenir les anciennes versions ? Et les Webmestres, les pauvres, ils vont s’arracher les cheveux à faire des migrations sans arrêts...

 Spip étant un projet communautaire, je pense qu’il est important de souligner que chacun peut y contribuer à sa hauteur (je ne gagne pas ma vie grace au developpement)

Je travaille à l’heure actuelle principalement pour mon site perso, je fais évoluer les outils qui m’intéresse (comme toi je pense...), donc je rend compatible ce qu’il me manque pour la 1.9.2. J’ai été particulièrement déçu par l’arrêt de la compatibilité ascendante 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 Multiviewer doit certainement servir à quelques personnes en 1.9.2 autre que moi par exemple.

Il faut penser à tout le monde dans cette histoire : les développeurs n’auraient pas de travail s’il n’y avait pas d’utilisateurs de Spip, donc il faut aussi penser au webmestre lambda qui cherche juste un fonctionnalité pour son site stable qu’il ne migrera jamais en 2.0.

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

Au delà de ces considérations, 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 commencer par essayer la migration vers la 2.0 (tu te fais une copie du site) avant tout ?

Sur un site relativement normal, c’est quasiment transparent. Sur un site pluginisé et patché à mort, évidemment ça peut être plus chiant. Mais l’investissement en temps est un apprentissage carrément bénéfique. Et si tu aimes patcher et bidouiller, les nouvelles possibilités de SPIP 2 sont une bénédiction...

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

 les gens sans connaissances avancées en informatique 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 compatibilité, afin qu’ils disposent aussi de certain nouveaux plugins au fur et a mesure du devellopement 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 effectivement trafiqué le code de spip un peu partout, le squelette est bcp trop compliqué et pas bien codé pour etre portable à l’heure actuelle... ça demandera du travail !

 derniere chose : je voudrais bien quelque infos pour s’inspirer de ton ancien plugin metadonnees que tu disais trop lourd, pour creer un éventuel plugin 1.9.2... je sais je suis tétu :)

Linuxiennement,