Post to Facebook
Tweet about this
Share at LinkedIn
Invite participants
Reference this pageProjets « Suggestions de fonctions « Images «
Protection des images contre l'effacement non désiré
votes
Je viens d'apprendre, à la lecture d'un billet de Jmarc (qui l'a appris, lui, à ses dépends) que lorsque l'on supprime une page avec des images, celles-ci sont supprimées, même si elles sont utilisées dans une autre page.
Cela me semble très inconvenant. Un jour, je trouverai une page à laquelle il manque une image et je ne me souviendrai peut-être même pas de ce que c'était, ni d'où elle venait, parce que plusieurs semaines auparavant j'aurai effacé une page qui ne semblait plus utile.
À l'inverse, si on duplique une page, Yacs duplique aussi toutes les images qui y sont rattachées, avec le risque d'engorger la base de données, non ?
La demande fonctionnelle est d'empêcher l'effacement d'une image à moins qu'aucune page ne l'utilise plus.
Christian - Le problème c'est que les images sont stockées dans un répertoire mentionnant le numéro de l'article ou de la section. S'il faut revoir cette organisation ca ne va pas être facile. Les images sont aussi rattachées à l'article dans la base de données. Si on ne supprime que l'article cela va engendrer beaucoup d'orphelins. Je ne pense pas pour ma part qu'il faille changer ce principe de suppression.
Par contre je verrais bien une évolution dans le chargement des images à la manière de ce que propose d'autres CMS. En tout cas ce que j'en ai vu de loin.
Le principe :
Quand on veut ajouter une image nous est proposé de : - soit parcourir son ordinateur - soit parcourir l'arborescence des collections sur le serveur et de choisir une image déjà présente
Christian Loubechine
actupro
Actupro
quelques sites yacs : création site internet annuaire pro
Alexis Raimbault - la commande de suppression prévient tout de même que des images vont être effacée.
On pourrait avoir une option pour rattacher les images à un "conteneur ramasse images".
Quand à scruter tout le contenu du site pour trouver si un éventuel code yacs fait quelque part appel à l'image, cela serait impensable.
Et après, on demandera la même chose avec les fichiers ! 
Alexis Raimbault webmaster free-lance
Jmarc - Alexis : on a beau être prévenu que telle image va être effacé, il est impossible de savoir si quelqu'un n'a pas utilisé cette image dans un autre article 
Pour moi, perdre de l'espace disque en dupliquant les images dans chaque article ou en n'effaçant pas les images lorsque qu'un article est supprimé est largement moins grave que de bousiller un article parce qu'il utilise les image d'un autre qui a été supprimé.
Garantir au contributeur que son travail ne sera pas "saccagé" innopinément par un autre est une priorité si l'on ne veut pas le dégouter de contribuer.
Dans un premier temps, une solution qui parait pas trop compliquée (y'a que du code à retirer) consisterait à ne pas supprimer le dossier qui contient les images de l'article supprimé.
La proposition d'alexis de déplacer les images dans un conteneur "ramasse image" est encore plus propre mais demande un peu de codage.
Dans un deuxième temps, on peut réfléchir à la manière de gérer proprement la suppression des images qui ne sont utilisées dans aucun contenu (une purge après analyse des contenus de la base, c'est lourd mais on peut qu'en même y penser...)
Et pour les fichiers... même problème = même combat
J.Juraver - Plus généralement, tous les codes dynamiques sont concernés : les commentaires aussi disparaiseent lors d'une suppression d'article, ce qui paraît normal, mais si j'ai cité un comment avec [comment=423] .... ça me troue un contenu de page. On a déjà eu ce souci plusieurs fois dans notre documentation.
Le paradoxe, c'est que les signatures en revanches se comportent à l'exact opposé. Les signatures engorgent la base de données de chaque commentaire, y compris les signatures obsolètes, avec leurs éventuels liens morts qui reste sur site. Bon c'était une parenthèse mesquine.
En tout cas il y a une fonction administrateur pour scanner les images orphelines et non(utilisées : on peut déjà en suggérer une similaire pour l'usage de codes dynamiques corrompus.
Ensuite on peut aussi suggérer qu'un code d'affichage, particulièrement celui affichant une image, soit remplacé le cas échéant par un texte un peu plus user-friendly.
Et enfin, il existe un autre problème soulevé par le constat de cette discussion : le versioning. Si je modifie un article en supprimant une image attachée, et que plus tard je reviens à une version antérieure qui contenait cette image, il n'y a aucun moyen de retrouver laquelle. Pour un habitués vous me direz c'est normal, supprimer une image du disque est un acte conscient et conséquent : oui mais dans le cas d'un wiki ouvert...?
A mon sens, le dossier contenant les fichiers enregistrés dans chaque article ne devrait pas être supprimé avec l'article en soi. Mais en revanche l'associé doit pouvoir purger régulièrement et obtenir une traçabilité de ces attachements/suppressions en cascade : là où interviendrait le module de "panier d'élément" évoqué par Alexis. Une sorte de couloir de la mort des éléments en sursis 
Yacs on my blog | Yacs on social media | Yacs Showroom | Plugin Firefox de recherche dans Yetanoz | Find Yacs anywhere with your phone!
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 |
Alain Lesage - Et si, quand un second article utilise une image déjà rattachée à un premier article, on inscrivait en regard de cette image dans la base de données tous les articles auxquels se rattache l'image ?
Lors d'une suppression, on pourrait au moins aviser que non seulement une image sera supprimée, mais également quels articles seront affectés. Yacs pourrait même déplacer automatiquement l'image dans le dossier d'un autre article où elle est rattachée.
Mais tout ça, c'est probablement aussi compliqué que de revoir totalement la logique du téléversement, du stockage et du rattachement des images, tel que suggéré ci-dessus.
L'usage d'un « conteneur unique à images » aurait d'autres avantages il me semble. L'archivage et la recherche seraient facilités. On pourrait même téléverser toute une série d'image par FTP dans ce conteneur et avoir un script qui les incluerait automatiquement à la base de données en leur donnant un numéro utilisable partout. Ce serait une alternative puissante au téléchargement multiple. Mais je rêve probablement...
On a si peu d'idée de ce qui est possible...
Jmarc - Alain : pour continuer dans les même rêveries, voici un article proposant quelques évolutions de la gestion du stockage des images dans Yacs.
Le stockage des images
On y retrouve la plupart des idées que tu évoques et un peu plus de détails concrets sur une manière de procéder.
Mais cela reste une modification assez profonde et complexe donc on a encore un peu de temps devant nous pour réver avant que cela deviennent réalité
Alain Lesage - Jmarc : je suis ébahi !
Ton article est admirablement clair, expose avec limpidité les raisons du changement suggéré, propose des solutions pragmatiques et commence même à en expliquer la mise en oeuvre. Wow, on en voudrait davantage des comme ça. Je vais prendre des cours de rédaction de tickets en te lisant !
En passant, j'adore ta section, où tu regroupe toutes tes suggestions sur un même thème (ici les images). Il me semble qu'on devrait s'en inspirer pour organiser la section des suggestions de fonctions. Il m'est même passé par la tête que ces recommandations de fonctions pourraient être attachées à chacune des rubriques de la doc (en préparation), ou au moins suivre la même organisation. Ne serait-ce pas plus facile pour le développement d'aborder un « thème » (par exemple, les images) en ayant sous les yeux toutes les suggestions qui y sont liées ? (JJ va suggérer qu'on fasse ça avec les étiquettes, attends 2 minutes et tu vas voir... )
Une remarque : je ne peux pas faire de commentaires sur les pages de La gestion des images dans Yacs que tu as créée, mais il semble que je puisse y ajouter une page. Est-ce voulu ? Et pourquoi est-ce que ton espace personnel est l'unique item d'une section [section=467] à la racine du site ?
On a si peu d'idée de ce qui est possible...
J.Juraver - Alain : 
Moi ma central de suggestions, j'ai abandonné depuis longtemps... Nouvelles fonctions suggérées
Yacs on my blog | Yacs on social media | Yacs Showroom | Plugin Firefox de recherche dans Yetanoz | Find Yacs anywhere with your phone!
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 |
Jmarc - " Il m'est même passé par la tête que ces recommandations de fonctions pourraient être attachées à chacune des rubriques de la doc (en préparation), ou au moins suivre la même organisation. "
j'adhère !
" je ne peux pas faire de commentaires sur les pages de La gestion des images dans Yacs que tu as créée, mais il semble que je puisse y ajouter une page. Est-ce voulu ? Et pourquoi est-ce que ton espace personnel est l'unique item d'une section [section=467] à la racine du site ? "
ben là je sais pas J'ai juste cliqué sur le lien dans mon profil qui permet de se créer un blog perso... C'est peut être une nouveauté de Yacs 10 que je suis le premier à expérimenter ?
M'en vais voir de plus près comment c'est paramétré tout ça.
Jmarc - JJ :
" Moi ma central de suggestions, j'ai abandonné depuis longtemps... Nouvelles fonctions suggérées "
C'est dommage. Le principe me parait très bien !...
Alain Lesage - JJ:
Moi ma central de suggestions, j'ai abandonné depuis longtemps... Nouvelles fonctions suggérées
J.Juraver - Sans troller 1000 ans sur ma personne, j'ai arrêté la maintenance de ma page parce que d'abord il n'y a pas de code qui me permette d'avoir une vue d'ensemble (tels articles postés par tel user dans telle section), et puis la notion d'intégration effective est beaucoup plus complexe à valider qu'avec des ok / abandonné , vu que parfois on a bien une intégration mais pas tout à fait comme on l'avait souhaité 
Yacs on my blog | Yacs on social media | Yacs Showroom | Plugin Firefox de recherche dans Yetanoz | Find Yacs anywhere with your phone!
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 |
Alexis Raimbault - Jmarc tu dois pouvoir dans les options de tes pages permettre les commentaires aux membres.
En tout cas il y a des erreurs importantes dans ta description, comme :
" Les images sont enregistrées dans des dossiers sans rapport avec leur page d'origine. "
et d'autres commentaires à faire (l'id doit être unique dans la table, donc dans ton système tu ne peux pas recopier un code yacs car il faudra un nouvel enregistrement donc un nouvel id)
en tout cas ici on est hors sujet, c'est pas l'endroit pour développer.
Alexis Raimbault webmaster free-lance
Jmarc - j'ai encore un peu de mal avec la gestion des droits... je pense que maintenant, c'est bon pour commenter directement Le stockage des images
J'y vais de ce pas pour commenter tes remarques...
J.Juraver - On sait que yacs a besoin d'une élément parent pour enregistrer des objets tels que des images. Le problème soulevé par Jean-Marc, c'est bien celui-là.
Or si yacs en a tellement besoin, le plus efficace serait peut-être d'attacher dans la base de données relationnelle l'image non pas à un article, mais à la personne qui l'envoie. On pourrait ainsi la retrouver partout ailleurs indépendant de la vie de l'article (ou de la section, ou de la catégorie parente), et il est moins fréquent de supprimer un utilisateur qu'un article...
Par ailleurs, celà permettrait définitivement de répondre à une demande voisine... Gestion centralisée des images côté utilisateur
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 |
