Le stockage centralisé

J.Juraver	Ouacances... Je ne m'attarde pas, j'ai mon yacs en double file... Yacs on my blog \| Suivez le blog Yacs \| Yacs Showroom \| Plugin Firefox de recherche dans Yetanoz \| on Aug. 19 2011
Alexis Raimbault	you hou ? tu as encore loupé la notif ? ou bien je t'agace ? Alexis Raimbault webmaster free-lance on Jul. 7 2011
Alexis Raimbault	Jmarc : comme j'ai écris, les simples utilisateurs passeront à terme par une interface graphique sans code yacs. Cela fonctionnerait comme tu le souhaites il faut discuter du terme "dupliquer". ce n'est peut être pas le bon terme. lorsque l'on passe par le code yacs pour utiliser dans une page B une image utilisée dans une autre page A on survol l'image dans la page A pour connaitre son id (comme maintenant dans la version stable) on écrit à la main le code dans la page B en enregistre là on se dit : moi, je veux pas ce titre ! on survole l'image dans la page B on clique sur l'icône d'accès rapide à l'édition l'image s'affiche en édition un texte prévient que l'image est aussi utilisée par la page A, C, D...E etc. le formulaire d'édition est en grisé un bouton propose cependant de dupliquer l'image, "pour une utilisation de l'image propre à cette page" si l'utilisateur à les droits sur l'image, un bouton permet d'activer le formulaire pour éditer tout de même. en cliquant sur dupliquer, le code va créer une nouvelle ligne dans la table, et donc obtenir un nouvel id. Le formulaire devient actif pour modifications. après enregistrement le code yacs dans le texte de la page B est aussi changé avec le nouvel id. lorsque l'on passe par l'interface graphique : l'utilisateur édite la page B avec un éditeur riche les images visibles, et non pas un code yacs. dans l'éditeur, il clique sur le bouton ajouter une image une popup permet de faire des selections, ou bien par glisser déposer, ici tout reste à définir, y compris la manière de proposer les listes de vignettes (par thèmes ?) la selection d'une image entraine automatiquement la demande d'un nouvel id. l'utilisateur place son image comme il le souhaite. il enregistre la page un nouveau code js transforme les images en code yacs. Ici il faudra enrichir les possibilités, par exemple pouvoir donner des dimensions d'affichage. `[image=xx,left,200px,100px]` le tout est posté vers le serveur. si on édite en textarea, le texte affiche les codes yacs, et on fait tout à la mano. Alexis Raimbault webmaster free-lance inspired from Jmarc on Jul. 1 2011
Jmarc	Alexis : dans le cas de mes utilisateurs (de simples contributeurs) aucun ne fera l'effort de "dupliquer" une image (et encore moins l'effort de comprendre à quoi ça sert). La duplication manuelle revient donc a rester à la situation actuelle avec son probleme d'impact lors d'une suppression d'image... Y a t-il une autre interet à l'utilisation du code yacs [ image=...] hormis la possibilité de modifier le titre et la description d'une même image sur plusieurs pages à la fois ? inspired from Alexis Raimbault on Jul. 1 2011
Alexis Raimbault	Pour la banque d'images ok, autant tout charger sur une page. Alexis Raimbault webmaster free-lance on Jul. 1 2011
Alexis Raimbault	tu va voir on va finir par converger !... " Ta solution de "dupliquer" les propriétés à la demande ne répond pas à l'un des objectifs principaux de ce projet : ne pas impacter d'autres pages lorsque je modifie l'image sur sa page d'origine " Non je pense avoir inclu ce point : à partir du moment où l'image est "dupliquée", ses propriétées seraient indépendantes de l'image originelle. On pourrait même changer de fichier si on voulait Par contre, dans mon exposé l'utilisateur doit effectivement demander explicitement la duplication. Sinon, cela veut dire qu'il utilise l'image d'origine. Par contre il est averti par l'interface. Ce que je souhaite, c'est qu'on l'on appel toujours une image avec un code yacs précis, mais pas qu'une moulinette manipule ce code à l'enregistrement. De plus pour le moment, je ne comprends pas comment tu compte faire à l'affichage ? il faut bien une moulinette pour aiguiller le code yacs vers la bonne copie d'image ? sur Nautical c'est différent car tu stockes dans la base le code html de l'image, et non pas le code yacs, qui lui disparait Je préfère un id = une image couplée à un set de propriétés dans une ligne d'une table. et non pas un id = un traitement invisible Là où on se rejoint, c'est que nous aurons effectivement une interface visuelle pour sélectionner des vignettes. Dans ce cas le code yacs n'est pas affiché en WYSIWYG, et le glisser-déposé engendrerait automatiquement une "duplication" de l'image d'origine. Du coup c'est transparent pour l'utilisateur. Ainsi, les utilisateurs ont l'interface, et le webmaster conserve son code yacs lorsqu'il veut appeler une [image/propriétées] précises. Un webmaster peut aujourd'hui utiliser sciemment le fait qu'en modifiant une image, la modification se reporte sur toutes les utilisations de cette image (pour des images qu'il place lui-même). Pour cela il continura de le faire en passant par les codes yacs, comme aujourd'hui. Alexis Raimbault webmaster free-lance on Jul. 1 2011
Jmarc	Alexis j'ai scindé les derniers échanges en points distincts. point 1 : le stockage des infos sur les images dans une ou deux tables. Les 2 solutions me conviennent. Celle que tu proposes (table unique) est probablement plus simple à implémenter et à assimiler par les développeurs. Ce serait donc celle qu'il faudrait adopter. Point 2 : la personnalisation des propriétés de l'image sur chaque page. Ta solution de "dupliquer" les propriétés à la demande ne répond pas à l'un des objectifs principaux de ce projet : ne pas impacter d'autres pages lorsque je modifie l'image sur sa page d'origine. Je pense qu'il faut inverser le fonctionnement par défaut que tu proposes. Sans action de la part de l'utilisateur, les propriétés de l'image d'origine sont dupliquées et un nouvel id est attribué. Cela veut dire qu'il y a systématiquement un traitement d'analyse lors de l'enregistrement de la page. Si l'on veut pouvoir revenir au mode actuel de yacs où une modif sur l'image d'origine est répercutée sur l'image dupliquée sur une autre page, il faudrait que l'utilisateur édite l'image dupliquée de la page en indiquant qu'il veut qu'elle soit synchronisée avec une autre image (ou qu'il ajoute un paramètre dans le code yacs). Je pense que ce mode de fonctionnement est à déconseiller voir à bannir car le risque de se retrouver avec des "trous" dans des pages est difficilement acceptable... Point 3 : effacement des images non utilisées ou conservation dans une banque d'image ? La notion de banque d'image "sans page associée" n'existe pas dans Yacs aujourd'hui. Je ne vois pas l'intérêt de l'introduire. Il me paraît plus simple et naturel que la banque d'image d'un site soit constituée par une page (ou plusieurs) dans laquelle sont ajoutée les images concernées. Dans ce cas, ces images seront conservées et en plus, accessibles en consultant la page. On pourrait aussi prévoir une option dans le panneau de configuration qui permette d'opter entre 3 modes : les images qui ne sont plus utilisées sont automatiquement supprimées du serveur les images qui ne sont plus utilisées sont conservées dans le serveur dans une page à définir (la page des images non utilisées) l'utilisateur qui supprime une image est averti si elle va être définitivement supprimée et peut choisir de la transférer dans la page des images non utilisées. Point 4 : lourdeur des traitements d'analyse pour identifier les images nouvellement insérées. Je ne vois pas comment l'éviter sachant que cette analyse n'est réalisée que lors de l'enregistrement de la page éditée (une seconde ou deux de traitement en plus n'est pas rédhibitoire à ce moment là). Si, par défaut, on veut rendre indépendante l'utilisation d'une même image sur 2 pages différentes, on est obligé d'avoir 2 enregistrements différents des propriétés de l'image. Pour créer ce 2ème enregistrement, de mon point de vue, il est nettement préférable d'avoir un traitement un peu lourd qui s'exécute automatiquement à chaque enregistrement plutôt que de devoir éditer manuellement chaque image "dupliquée" pour que le traitement soit réalisé à ce moment là. C'est ce qui est réalisé depuis un an sur mes sites et je n'ai pas vu de différence par rapport à l'utilisation de yacs.fr... Un dernier point concernant l'utilisation du code yacs [ image=...] : Je trouve que l'utilisation d'un code yacs pour insérer une image dans un texte n'est pas une solution au niveau de l'ergonomie actuelle du web. A l'heure des éditeurs wysiwyg, il convient plutôt d'insérer la véritable vignette dans le texte en cours d'édition. C'est plus lisible et plus intuitif pour les utilisateurs car c'est comme cela qu'ils procèdent dans leur traitement de texte. Ecrire un tel code yacs à la main, c'est comme aller sur la page d'un site en tapant son url complète (avec le paramètre &id_page=13245 qui va bien) plutôt que de passer par google quitte à arriver sur la page d'accueil du site puis d'utiliser les menus pour accéder à la page. Les deux méthodes fonctionnent mais si la première méthode est plutôt plus rapide (à condition de connaître l'url !), la seconde est utilisée par 98% des internautes car plus accessible sans effort. Pour terminer, je vais rajouter un chapitre dans l'article ci-dessous pour donner le dernier état des solutions pressenties... inspired from Alexis Raimbault on Jul. 1 2011
Jmarc	Alexis : Je n'avais pas vu passer la notification de ton post précédant... Ta proposition présente des avantages et des inconvénients. J'y réfléchie... inspired from Alexis Raimbault on Jul. 1 2011
Alexis Raimbault	Cela te laisse dubitatif Jmarc ? on sollicite d'autres avis ? Alexis Raimbault webmaster free-lance on Jul. 1 2011
Alexis Raimbault	il y a plusieurs choses qui me chagrinent : avec le même code yacs `[image=123]` sur différentes pages, on exploite différentes propriétés pour la même image, je crains qu'on ne s'y retrouve plus. on ne peut changer le texte de l'image originale, par exemple si on s'est trompé de titre au premier chargement (faute d'ortho), toute utilisation de l'image commencera avec un mauvais titre. on supprime les images qui n'ont plus d'association à une page, mais un webmaster peut vouloir profiter du nouveau système pour mettre à disposition une banque d'images, sans les associer à une page au préalable. la procédure demande au script d'analyser le texte pour détecter les codes yacs (intro, description, zone extra, bas de page, et il faudrait étendre cela aux nombreuses possibilités des overlays) c'est un peu lourd en traitement. deux tables pour gérer les images. Je propose la variation suivante : Lorsqu'on ajoute une image à une page A, c'est comme actuellement : il n'y a qu'un seul enregistrement dans une seule table. On peut éditer cette image comme on veut depuis cette page. si on utilise l'image dans une autre page B on écrit le même code yacs. mais si on édite l'image depuis cette page B, les champs de propriétées de l'image sont grisés : on ne peut rien modifier. par contre on a un bouton "dupliquer cette image" (intitulé à débattre) qui créé un nouvel enregistrement dans la table des images (nouvel id), vers le même fichier. Le fichier n'est donc pas dupliqué. Dans le texte de la page B, le code yacs est remplacé automatiquement avec le nouvel id après cette opération. On peut ensuite éditer cette image comme on veut depuis cette page (pour ceux qui en ont les droits). Si on ne duplique pas l'image, on reste exposé aux changement effectué sur l'image depuis la page A. A côté du bouton de duplication, on aurait aussi un raccourci pour ce rendre sur la page originale. Sur une page C, on peut maintenant utiliser le code de la page B, et même le dupliquer en une troisième version. J'ai pas tout exposé mais je pense que cela suffit déjà pour comprendre cette nouvelle proposition ? Alexis Raimbault webmaster free-lance inspired from Jmarc on June 28 2011
Jmarc	Alexis : Des éclaircissements... On ajoute une image (photo.jpg) à la page A en définissant certaines de ses propriétés : titre, description, auteur, option d'affichage de la vignette. Si c'est le 123ème image ajoutée sur le site yacs, un enregistrement dont l'id est 123 est créé dans la table "images". Le fichier de l'image originale est stocké "en central" en étant renommé en 123-photo.jpg Enfin, comme cette image est insérée dans la page A, un enregistrement reprenant les propriétés (titre, description, etc...) est créé afin de mémoriser l'association entre l'image originale et son utilisation dans la page A. Lorsque je suis en train d'éditer la page A et que je liste les images associées à cette page, je peux éditer l'image 123. Dans ce cas, je modifie uniquement les propriétés de l'enregistrement associé à la page A. Donc si je modifie le titre de l'image, il ne sera pas modifié dans les autres pages utilisant cette image. Si je supprime l'image, je supprime l'association de cette image avec la page A. Et si cette image n'est associé à aucune autre page alors l'image originale est également supprimée, même si je suis ni propriétaire de l'image, ni associé, car il est inutile de conserver une image qui n'est utilisée dans aucune page... Lorsque j'insère l'image 123 dans la page B en ajoutant dans le texte [ image=123], un enregistrement reprenant les propriétés de l'image originale (titre, description, etc...) est créé afin de mémoriser l'association entre l'image originale et son utilisation dans la page B. Je peux modifier ces propriétés en éditant cette image dans le formulaire d'édition de la page B. Si je souhaite modifier le fichier image pour le remplacer par un autre, je ne peux effectivement pas le recharger depuis la fenêtre d'édition de ma page B. Pour changer d'image, Je dois ajouter la nouvelle image (124 par exemple) et remplacer [ image=123] par [ image=124] Si maintenant, je veux insérer l'image 123 dans la page C sans les propriétés de l'image originale mais avec les propriétés de celle insérée en page B... je ne peux pas. Je suis obligé de l'insérer avec les propriétés de l'image originale et de les modifier ensuite. Dans tous les cas, l'image originale 123 est insérée dans les pages avec le code yacs [ image=123] On peut cependant envisager un moyen plus ergonomique pour insérer des images (moins "informatique" que le code yacs). Plutôt que d'imposer à nos utilisateur de connaître le code yacs [ image=...] et l'id de l'image qu'il veulent réutiliser, il me paraît plus intuitif de leur laisser chercher la page où est située l'image qui les intéresse dans l'arborescence des pages du site (via un arbre dynatree par exemple) puis d'afficher la galerie des vignettes des images de cette page et leur laisser cliquer sur celle qui les intéresse. De cette manière, on peut recopier les propriétés (titre, description, etc...) de l'image "associé" choisie plutôt que celles de l'image originale. inspired from Alexis Raimbault on June 28 2011
Alexis Raimbault	j'ai besoin d'éclaircissements suppons qu'on ajoute une image à une page, avec la gestion centralisée. l'image est enregistrée dans la base, avec un id "123" par exemple. le fichier est stocké selon les règles enoncées. dans le texte, un code yacs `[image=123]` permet de positionner l'image l'image est associé à la page question : lorsque j'édite l'image, je change "l'originale" ou "l'image associée" (pour l'instant je suis le seul à utiliser l'image) si je supprime l'image, c'est uniquement l'association à la page qui est supprimée. Mais en tant que propriétaire ou associé je dois quand même avoir un moyen de supprimer l'original. lequel ? Maintenant, dans une autre page, j'ajoute dans le texte `[image=123]` d'après tes explications, une nouvelle association est enregistrée entre la page et l'image si on édite l'image, on ne change que les propriétées de l'image associée, pas celles de l'originale, ni d'autres association de la même source. note : dans ce cas, il ne faut pas autoriser de recharger le fichier depuis la fenêtre d'édition. question : dans le texte, j'ai toujours image=123 ? ou un autre id ? Maintenant, dans une troisième page, je veux insérer mon image 123, mais avec les mêmes propriétés que l'association faite dans la page précédente, pas celle de l'originale. je donne quel code yacs là ? j'ai quelques éléments de réponse à tout ça, mais je ne sais plus bien comment fonctionne ton système en place. Alexis Raimbault webmaster free-lance on June 28 2011
Jmarc	" quelle serait l'interface permettant de choisir une image existante dans le stockage central ? " Dans un premier temps, la même chose qu'aujourd'hui. On réutilise une image existante par un `[image=id]`, peu importe que son stockage soit centralisé. " je pense que l'insertion manuelle de code yacs `[image=id]` ne doit pas être analysé pour créer des copies d'images. " Peux tu préciser Alexis ce que tu entends par "créer des copies d'image" ? inspired from Alexis Raimbault on June 28 2011
Jmarc	" Il faudra peut-être prévoir le cas de l'import/export en accompagnement de celui des sections. " Heu... j'ai pas compris ta remarque inspired from Alexis Raimbault on June 28 2011
Jmarc	" ...Pour le nom des fichiers enregistrés, je précaunise `<id>-<nomdufichieruploadé>.<ext>` pour donner plus d'informations lors du parcours des répertoires par FTP " C'est une excellente idée ! inspired from Alexis Raimbault on June 28 2011
Alexis Raimbault	quelle serait l'interface permettant de choisir une image existante dans le stockage central ? je pense que l'insertion manuelle de code yacs `[image=id]` ne doit pas être analysé pour créer des copies d'images. Alexis Raimbault webmaster free-lance on June 27 2011
Alexis Raimbault	Il faudra peut-être prévoir le cas de l'import/export en accompagnement de celui des sections. Alexis Raimbault webmaster free-lance on June 27 2011
Alexis Raimbault	Le projet est relancé ! Pour le nom des fichiers enregistrés, je précaunise `<id>-<nomdufichieruploadé>.<ext>` pour donner plus d'informations lors du parcours des répertoires par FTP Alexis Raimbault webmaster free-lance on June 27 2011
Jmarc	Le code que j'utilise actuellement pour centraliser le stockage des images est dispo sur github à l'adresse : http://github.com/jmarc06/yacs/commit/a34df92a47d777244a54d6a327134650453b9a29 Voici la liste des fichiers impactés : Articles\article.php Files\files.php Images\delete.php Images\edit.php Images\images.php Images\view.php Images\layout_images.php Images\layout_images_as_feed.php sections\section.php Shared\anchors.php Shared\global.php on Oct. 19 2010
Jmarc	Alexis : avec mon système de stockage centralisé, les fonctions de maintenance continuent de fonctionner. J'obtiens bien la liste des images les plus grosses. Les 2 autres actions me remontent un comptage d'enregistrements traités (qui s'arrete à 10000 images d'ailleurs alors que j'en ai beaucoup plus...). inspired from Alexis Raimbault on Oct. 19 2010
Jmarc	Alexis : Après vérification, il s'avère que mon analyseur de page ne traite pas les codes [ image=xxxx]. Il ne s'occupe que des images insérées via l'éditeur ckeditor (le fonctionnement préconisé sur mes sites pour insérer des images). Lorsqu'il détecte une nouvelle image, il crée l'association entre l'image et la page (dans la table images_link). Il serait facile de modifier ma fonction d'analyse pour qu'elle traite de la même manière les codes [ image=xxxx] inspired from Alexis Raimbault on Jul. 7 2010
Alexis Raimbault	Jmarc : " Pour que cela fonctionne, j'ai ajouté un mécanisme d'analyse des contenu lors de leur enregistrement qui repère l'utilisation d'une image... " Est-ce que l'image fait alors partie des "pièces jointes" de la page ? Alexis Raimbault webmaster free-lance inspired from Jmarc on Jul. 2 2010
Jmarc	Alexis : les procédures de suppression sont conservées avec les même écrans et message. La seule différence c'est que le fichier source n'est pas supprimé tant qu'il y a des pages auxquelles il est associé. Pour que cela fonctionne, j'ai ajouté un mécanisme d'analyse des contenu lors de leur enregistrement qui repère l'utilisation d'une image et crée l'association avec la page si ce n'est pas déjà le cas. inspired from Alexis Raimbault on Jul. 1 2010
Alexis Raimbault	ok, on retrouvera. Avant de faire une synthèse, je reviens sur la suppression dénoncé par Tof. Comment se passe dans ton système la suppression ? est-ce que tu affiches encore la page de confirmation de suppression ? On pourrait peut-être adapter cette page si la suppression concerne la dernière utilisation de l'image ? Alexis Raimbault webmaster free-lance on June 30 2010
Jmarc	Alexis : " qu'est-ce qui conçaient dans tes essais avec anchor NULL ? " heu, là, je ne me souviens plus... Mais ça devait être suffisament compliqué à contourner pour que je décide d'y mettre un anchor sur une section fictive créé pour l'occasion... inspired from Alexis Raimbault on June 30 2010
Alexis Raimbault	Jmarc : en effet c'est tarabiscoté ! qu'est-ce qui conçaient dans tes essais avec anchor NULL ? Alexis Raimbault webmaster free-lance inspired from Jmarc on June 30 2010
Jmarc	Alexis : Dans images_link, il y a un id unique dans le champ id et dont la numérotation commence à 8 000 000. Mais ce champ n'est pas vraiment utilisé car c'est surtout l'anchor et l'image_name qui sont utiles pour déterminer quelles images sont associées à une page. L'id permet principalement aux fonctions de savoir qu'elles ont affaire à une image asociée et pas à une image "source". Leur comportement est alors différent lorsqu'il s'agit d'une modification ou d'une suppression d'image. Ton idée d'utiliser la même table "image" pour gérer les 2 avec l'anchor nul dans le cas des images "source" permettrait de simplifier pas mal de choses. inspired from Alexis Raimbault on June 30 2010
Alexis Raimbault	Jmarc : j'ai regardé le code dans images/check.php les "images non utilisées", c'est repérer les images de la table qui ne sont pas appelées par les articles (pas de test sur section) les enregistrements orphelins, c'est repérer les images de la table dont l'anchor n'est pas valide. Dans tous les cas, un max de 10000 images sont traités. Alexis Raimbault webmaster free-lance inspired from Jmarc on June 29 2010
Alexis Raimbault	Jmarc : j'ai pas encore tout compris. Dans images_link, il y a quoi dans le champ id ? Alexis Raimbault webmaster free-lance inspired from Jmarc on June 29 2010
Jmarc	Alexis a écrit : " Pour stocker tout dans la meme table on peut éventuellement stocker les images avec un anchor NULL, et considérer tous les anchors avec une valeur comme des utilisations de cette image. " c'est une excellente idée... mais j'avais des problème lorsque l'anchor de mes images n'était pas défini (ce qui m'a contraint à affecter un anchor par défaut, écrit en dur dans un fichier ) Dans mon Images_link, le champs avec le nom du fichier contient le nom du fichier "centralisé". De plus, ce nom correspond à l'id Je fais donc le lien avec l'image "source" via le nom du fichier (qui est le même) ou en récupérant l'id de l'image dans son nom (en virant simplement l'extension). inspired from Alexis Raimbault on June 29 2010
Jmarc	Alexis : je ne connaissais pas ces fonctions de gestion des images (pas vu dans la doc ) Normalement, elles ne devraient plus fonctionner avec mon nouveau système et devront être modifiées pour cela. C'est quoi les enregistrements orphelins ? Des enregistrements dans la tables images pointant vers des fichiers qui n'existent plus physiquement ? inspired from Alexis Raimbault on June 29 2010
Alexis Raimbault	Jmarc : Pour stocker tout dans la meme table on peut éventuellement stocker les images avec un anchor NULL, et considérer tous les anchors avec une valeur comme des utilisations de cette image. Dans ton images_link, par quels champs tu fais la jointure avec la table images ? Alexis Raimbault webmaster free-lance inspired from Jmarc on June 28 2010
Alexis Raimbault	Jmarc : " Et si une image n'est plus associée à aucune page, cela risque d'être difficile de la retrouver pour la réutiliser un jour (ou alors, il faudrait l'associer à une page "images non utilisées"). " sur un serveur yacs, en temps qu'associé va sur l'url "/images" tu remarques que dans la colonne extra, il y a un outil "maintenance" les options : Lister les plus grosses images Détecter les images non utilisées Détecter les enregistrements orphelins maintenant je sais pas ce qui va se passer sur ta version customisée. Alexis Raimbault webmaster free-lance inspired from Jmarc on June 28 2010
Jmarc	Christophe : Comme indiqué par Alexis, la table yacs_members ne permettrait pas de "cloner" les propriétés de l'image source pour les appliquer/modifier pour chaque occurence de l'image sur le site. " dommage de supprimer l'image quand elle n'est plus utilisée; imagine que tu l'enlèves d'un article juste pour la mettre dans un autre... ton image est supprimée puis recréée. " Oui, effectivement. Mais lorsque l'utilisateur clique sur "Supprimer l'image", il doit quand même s'attendre à ce qu'elle soit supprimée. Et si une image n'est plus associée à aucune page, cela risque d'être difficile de la retrouver pour la réutiliser un jour (ou alors, il faudrait l'associer à une page "images non utilisées"). On peut peut être envisager d'avoir un lien "supprimer l'image de cette page" pour seulement supprimer l'association sans supprimer le fichier de l'image... inspired from Christophe Battarel on June 28 2010
Jmarc	Alexis a proposé : " je me demande si on ne pourrait pas utiliser la même table (images) pour faire les deux fonctions, avec un champ qui nous indique s'il s'agit d'un tuple concernant une image physique ou bien une utilisation dans une page. " Je pense que cela doit être effectivement possible. C'est une idée intéressante qui va complexifier un peu le code par moment mais qui va également le rendre plus simple à d'autres moment. La transposition du système centralisé pour gérer les fichiers serait effectivement souhaitable... inspired from Alexis Raimbault on June 28 2010
Alexis Raimbault	C'est juste une idée pour le moment mais je me demande si on ne pourrait pas utiliser la même table (images) pour faire les deux fonctions, avec un champ qui nous indique s'il s'agit d'un tuple concernant une image physique ou bien une utilisation dans une page. Si ce n'est pas possible, je préconise des noms plus expicite pour les tables, par exemple images_stored images_used Il faut aussi réfléchir à la transposition pour le stockage des fichiers. Alexis Raimbault webmaster free-lance on June 28 2010
Alexis Raimbault	" pourquoi créer une table supplémentaire yacs_images_links ? La table yacs_members pourrait être utilisée, non ? " JM utilise sa nouvelle table pour surcharger les descriptions et autres options d'images. autant de champ qui n'existent pas dans member. Alexis Raimbault webmaster free-lance inspired from Christophe Battarel on June 27 2010
Christophe Battarel	Première réaction à chaud : Bravo ! Je suis content que tu aies fait ce boulot, car j'avais également besoin de centraliser les images de yacs dans un dossier unique pour plusieurs raisons : pouvoir partager les images entre plusieurs instances de yacs pouvoir partager le répertoire d'images avec mes partenaires lors du développement du site (client, photographe, graphiste, etc) Juste un ou deux points "techniques" sur lesquels je me pose des questions : pourquoi créer une table supplémentaire yacs_images_links ? La table yacs_members pourrait être utilisée, non ? dommage de supprimer l'image quand elle n'est plus utilisée; imagine que tu l'enlèves d'un article juste pour la mettre dans un autre... ton image est supprimée puis recréée. Christophe Battarel - Société altairis - on June 26 2010
Jmarc	Voici la présentation du nouveau systeme de stockage des images que j'ai mis en place. Il tourne depuis 2 mois sur mes sites en production (Nautical Trust et Nautical Trek) qui totalisent plus de 35000 images gérées ainsi. A voir maintenant si vous jugez opportun de récupérer ce systeme sur une prochaine version de Yacs... on June 26 2010