Piwigo.org

VDigital · 2010-01-27 23:20:28

Sans vouloir vous masquer les raisons qui sont derrière ce débat, le pb est compliqué.
J'ai proposé 24h de réflexion à plg

L'avenir du répertoire ./upload est derrière.
Dès que c'est plus clair pour nous, et qu'on peut vous proposer quelque chose qui tienne debout,
j'expliquerai.

plg · 2010-01-27 23:25:14

mathiasm a écrit:
Proposition basée sur ma supposée compréhension :

file: reste le nom original
name: contient le nom d'affichage (file sans extension par défaut)
path: contient le chemin physique

C'est exactement ce que j'ai proposé hier :-)

mathiasm a écrit:
le nom de téléchargement est construit à partir de name + extension de file ?

Non, aujourd'hui le nom de téléchargement, c'est basename($path). Moi je propose d'uitliser images.file, tout simplement (donc le nom d'origine du fichier)

flipflip · 2010-01-28 13:33:52

Un problème que viens de soulever mathiasm avec l'extension.

Exemple :
J'ai une image dont je génère les 3 déclinaisons (thumbnail, normal, hd) la thumbnail et la normal on bien l'extension jpg, mais la hd a l'extension tif, si on stock le vrai nom du fichier + l'extension il avec être difficile de traiter ce cas.

VDigital · 2010-01-28 15:14:22

Merci Philippe, j'étais passé à coté de ce pb encore une raison de plus pour des champs séparés.

Je suis convaincu que tu vas comprendre le problème futur que je perçois.
J'ai avancé depuis mes messages précédents.

plg connait également le pb (je présume qu'il le comprend comme moi).

- Piwigo - /tags/2.0.8/admin/include/functions.php - Piwigo - fonction update_path()
Plus précisément sur "SET path = CONCAT(\''.$fulldirs[$cat_id].'\',\'/\',file)"

Tu me répondras: On parle de pLoader, et cette fonction ne sera jamais utilisée pour des images de pLoader.

Tu auras raison sauf que:

Si j'ai 40 000 photos dans ./upload et que mon serveur "plafonne".

0 - Je place la galerie en maintenance, et

1 - Copie ./upload sur un site distant

2 - Par un plugin:
- je crée le site distant dans la db,
- je décompose les path des images pour créer les catégories physiques (privées / verrouillées) avec le site id que je viens de créer,
- je rattache les images au storage_category à leur catégorie physique que j'ai crée.
Bref, je transforme des images pLoadées en images synchronisées.

- je termine par la fonction update_path() et la suppression totale de ./upload du site principal.

Moralité:
Je donne une bouffée d'air frais à mon site.
Je ne perds :
- aucune image,
- aucun niveau de confidentialité,
- aucun classement,
- aucune autorisation,
- aucun commentaire,
- aucune trace de l'historique,
- etc...

Dès que je déverrouille, je peux à nouveau faire du pLoader sans pb.

A une condition: c'est que "file" soit le nom physique de l'image dans ./upload
(ou qu'on rectifie la fonction update_path).

C'est probablement compréhensible pour toi, mais pas pour tous.

flipflip · 2010-01-28 15:55:37

J'ai bien compris ton cheminement... Mais je vois pas trop le rapport avec la discussions ? :D

Autre petits détails par rapport au serveur qui plafonne, je n'ai jamais été voir mais les fichier pLoadé sont stocké tous à la racine de ./upload ou bien dans des sous-répertoires ? Si c'est tous à la racine attention à la limite du nombre de fichiers dans un dossier... Mais je pense que c'est hors cadre de notre discussion.

Pour le bien de nos méninges de développeur de plugin je pense qu'il faudrait garder la même méthode de nommage, rangement quelque soit la méthode d'ajout de photos (pLoader, UploadForm)... Sauf peut être celle par ftp mais j'ai l'impression qu'elle est amené à disparaître vue les dernières évolutions.

Dernière modification par flipflip (2010-01-28 15:59:26)

plg · 2010-01-28 16:27:46

VDigital a écrit:
Si j'ai 40 000 photos dans ./upload et que mon serveur "plafonne".

0 - Je place la galerie en maintenance, et

1 - Copie ./upload sur un site distant [...]

Je pense que c'est faire bien compliqué de transformer en catégories réelles, tout ça pour quoi ? juste pour pouvoir reconstruire le images.path avec la méthode standard. Dans ce cas bien particulier:

1) copie de "./upload" sur mon serveur distant
2) dans la base (via un plugin si tu veux), update images set path = replace (path, './upload', 'http://autre_domaine.net/photos/upload');
3) suppression complète du contenu du répertoire "./upload"

Evidemment, il va y avoir quelques petits soucis à gérer (comme la photo qui ne pourra être supprimée que logiquement, mais pas pire qu'avec les sites distants actuels), mais c'est 3 fois rien par rapport à la génération de pseudo catégories physique pour retourner dans le mode "historique" basé sur les catégories physiques.

Dans l'histoire, je ne place même pas ma galerie en mode maintenance.

plg · 2010-01-28 16:35:36

flipflip a écrit:
Autre petits détails par rapport au serveur qui plafonne, je n'ai jamais été voir mais les fichier pLoadé sont stocké tous à la racine de ./upload ou bien dans des sous-répertoires ? Si c'est tous à la racine attention à la limite du nombre de fichiers dans un dossier...

C'est bien fait et ce problème a été pris en compte. A moins d'uploader 20000 photos dans la même journée, tu n'auras pas de soucis.

flipflip a écrit:
Pour le bien de nos méninges de développeur de plugin je pense qu'il faudrait garder la même méthode de nommage, rangement quelque soit la méthode d'ajout de photos (pLoader, UploadForm)...

pLoader et UploadForm utilisent le même algorithme pour trouver l'emplacement de la photo.

flipflip a écrit:
Sauf peut être celle par ftp mais j'ai l'impression qu'elle est amené à disparaître vue les dernières évolutions.

Non, a priori ce n'est pas amené à disparaître (ou alors je ne suis pas au courant ;-). De mon point de vue, c'est conservé à titre historique, parce qu'on peut difficilement annoncer à utilisateurs de longue date que le mode pLoader/UploadForm est devenu obligatoire. Même (et surtout) au sein de l'équipe, le mode pLoader ne remporte pas l'unanimité. Et c'est normal. Lire [Forum, post 128488 by plg in topic 16759] Ca donne effectivement à réfléchir ...

tosca · 2010-01-28 17:37:30

tosca a écrit:
Ca a l'air fort intéressant, mais je ne comprends rien à votre discussion et je pense que ça doit être aussi très abscons pour l'utilisateur lambda.

plg a écrit:
Peux tu me citer l'endroit où j'ai dit ça ? :-) (parce que je n'ai jamais dit ça, du coup, ça rend le reste de ton message un peu à côté de la plaque :-/ si j'ose dire)

Gotcha a écrit:
(ça fait un moment que j'ai décroché... :-/ )

mathiasm a écrit:
Proposition basée sur ma supposée compréhension :

Ca fait un peu beaucoup de personnes qui ne (se) comprennent pas "totalement" ;-)
Je suis curieuse de voir où ça va aboutir, mais je vais (sagement ?) attendre la fin de la discussion pour (re)demander une synthèse en langage "décodé"

(de toute manière, vu les limites de connexion que j'ai ici, mieux vaut attendre que je sois rentrée dans mes pénates avec "mon" wifi pas hyper-rapide mais qui fonctionne 24h sur 24 et pour pas cher !)

Gotcha · 2010-01-28 18:08:05

Le principale ce n'est pas d'être compris de tout le monde, mais déjà de se comprendre soi même. Ensuite, VDigital et plg sont de très bon technicien et nuls doutes qu'ils se comprennent eux avec ce langage :-)

Je n'attends pas de tout connaître pour lire, mais ce que je vois par contre du coup, ce n'est plus que le résultat. Donc... wait & see

VDigital · 2010-01-28 18:52:03

plg a écrit:
1) copie de "./upload" sur mon serveur distant
2) dans la base (via un plugin si tu veux), update images set path = replace (path, './upload', 'http://autre_domaine.net/photos/upload');
3) suppression complète du contenu du répertoire "./upload"

Evidemment, il va y avoir quelques petits soucis à gérer (comme la photo qui ne pourra être supprimée que logiquement, mais pas pire qu'avec les sites distants actuels), mais c'est 3 fois rien par rapport à la génération de pseudo catégories physique pour retourner dans le mode "historique" basé sur les catégories physiques.

Dans l'histoire, je ne place même pas ma galerie en mode maintenance.

Bonne idée, je l'exploite.

Je n'aime pas du tout les choses qui vont avoir quelques petits soucis à gérer.
Donc, je reprends.

1) copie de "./upload" sur mon serveur distant

2 - Par un plugin:
- je crée le site distant dans la db,
- je décompose les path des images pour créer les catégories physiques (privées / verrouillées) avec le site id que je viens de créer,
- je rattache les images au storage_category à leur catégorie physique que j'ai crée.
- je corrige le path à ta façon
Bref, je transforme des images pLoadées en images synchronisées.

3) suppression complète du contenu du répertoire "./upload"

Pas besoin de la maintenance.

Le seul problème qui reste, est qu'on peut faire une maintenance et casser les paths.
D'où ma demande et celle de yoDan d'avoir un champ supplémentaire.
Car si file (le file actuel reste le vrai nom du fichier) je ne crains plus rien.

Maintenant ce qui est gênant dans ta solution, c'est surtout d'avoir dans une table du Core de Piwigo une colonne (images.file) ayant des usages différents suivant que l'image vient de FTP ou de pLoader.

A toi de voir.

PS: Pas de maintenance (mais je pensais déjà à l'enlever).

Dernière modification par VDigital (2010-01-28 18:53:08)

plg · 2010-01-28 20:39:23

VDigital a écrit:
Je n'aime pas du tout les choses qui vont avoir quelques petits soucis à gérer.

Oui, et le super avantage dans Piwigo, c'est qu'on accède au code source et en plus, on peut y faire des changements :-)

VDigital a écrit:
Le seul problème qui reste, est qu'on peut faire une maintenance et casser les paths.

Oui, si tu transformes en catégories physique, la maintenance va tout casser. Si tu laisses proprement en virtuel, la maintenance ne cassera rien.

VDigital a écrit:
D'où ma demande et celle de yoDan d'avoir un champ supplémentaire.

yoDan n'a pas demandé cela. yoDan a un besoin fonctionnel, l'implémentation il s'en fiche :-)

VDigital a écrit:
Maintenant ce qui est gênant dans ta solution, c'est surtout d'avoir dans une table du Core de Piwigo une colonne (images.file) ayant des usages différents suivant que l'image vient de FTP ou de pLoader.

En effet, là je suis d'accord. Je suis assez "à cheval" sur le modèle de données et pour le coup, ça ne me choque pas du tout. On a déjà des possibilités différentes selon que la photo soit ajoutée en mode pLoader ou synchro. Si je donne une plus grande importance au fonctionnel, je dirais qu'il ne faut pas trop se prendre la tête avec ce microdétail (il y a probablement des choses bien pires dans le modèle de données). J'ajoute qu'a priori sur une galerie données, les photos sont soit ajoutées avec pLoader soit avec synchro, rarement les 2. On aura donc un ensemble cohérent pour une galerie donnée (en général).

VDigital · 2010-01-28 21:02:12

plg a écrit:
Si je donne une plus grande importance au fonctionnel, je dirais qu'il ne faut pas trop se prendre la tête avec ce microdétail (il y a probablement des choses bien pires dans le modèle de données).

Qu'il y ait des choses bien pire dans le modèle, j'en vois mais elles ne me dérangent pas forcément.
Par contre, ce "microdétail" est un "détail" critique pour les tout petits budgets (je pense aux associations par exemple).

mathiasm · 2010-01-28 21:27:31

plg a écrit:
VDigital a écrit:
Maintenant ce qui est gênant dans ta solution, c'est surtout d'avoir dans une table du Core de Piwigo une colonne (images.file) ayant des usages différents suivant que l'image vient de FTP ou de pLoader.
En effet, là je suis d'accord. Je suis assez "à cheval" sur le modèle de données et pour le coup, ça ne me choque pas du tout. On a déjà des possibilités différentes selon que la photo soit ajoutée en mode pLoader ou synchro. Si je donne une plus grande importance au fonctionnel, je dirais qu'il ne faut pas trop se prendre la tête avec ce microdétail (il y a probablement des choses bien pires dans le modèle de données). J'ajoute qu'a priori sur une galerie données, les photos sont soit ajoutées avec pLoader soit avec synchro, rarement les 2. On aura donc un ensemble cohérent pour une galerie donnée (en général).

Euh...
Pourquoi c'est différent avec pLoader ?
on a toujours .path qui contient le chemin physique, nom du fichier compris et filename qui contient le nom original du fichier image avec son extension, non ?
Si la différence est dans la procédure de synchro, ce n'est pas le modèle de données qui est en cause, mais la méthode de génération desdites données.
[moitié HS]Et la synchro pourrait très bien faire comme pLoader, mais côté serveur: détection du dossier, déplacement sur /uploads/YYYY/MM/DD, renommage, et même création de la cat virtuelle portant le nom du dossier d'origine)[/moitié HS]

Ou j'ai raté un truc (parce qu'avant, en fait, j'avais compris :-)

plg · 2010-02-22 23:18:09

Dans [Forum, post 134175 by plg in topic 16951] Module d'export Lightroom

plg a écrit:
ron a écrit:
Ces évolutions dépendent d'abord de Piwigo. Il me semble qu'elles sont en cours et bien évidemment pLoader en tirera profit.
Non non, ce n'est pas en cours.

Gotcha voudrait que Piwigo stocke les fichiers avec leur nom d'origine.

Ce qui est en cours pour Piwigo 2.0.9/pLoader 1.5 (changement du système de numérotation de pLoader), c'est que pLoader envoie le nom original du fichier, et que Piwigo le stocke dans la champ images.file de la base de données.

Bon maintenant, si vous insistez pour avoir un truc instable et qui va générer un tas de plaintes tells que "je ne comprends pas, l'ajout de photo se passe bien, mais je n'arrive pas à les voir dans mon navigateur", alors je vais ajouter une option dans pwg.images.add pour forcer l'utilisation du nom original du fichier pour le stocker sur le serveur.

Puis dans [Forum, post 134178 by tosca in topic 16951] Module d'export Lightroom

tosca a écrit:
plg a écrit:
si vous insistez pour avoir un truc instable et qui va générer un tas de plaintes tells que "je ne comprends pas, l'ajout de photo se passe bien, mais je n'arrive pas à les voir dans mon navigateur"
Peux-tu expliquer un peu ce que tu entends par là ?
Parce que je n'ai pas l'impression que tous ceux qui demandent à conserver leurs noms de fichiers pour diverses raisons (organisation personnelle, référencement, etc.) aient conscience des inconvénients que tu évoques.

(dans le prochain post, je réponds, promis)

plg · 2010-02-22 23:36:08

A la demande de tosca, j'explique pourquoi le sujet des noms de fichier est sensible.

En mode synchro, le nom de fichier est très contraignant, caractères accentués interdit, espaces interdit. Ce n'est pas par pure méchanceté que c'est codé ainsi. C'est une conséquence de la gestion de l'encodage des noms de fichiers sur le serveur, transmis par le serveur HTTP et affiché par le navigateur web.

Il se peut qu'un fichier nommé "件。这项 &@#$€.jpg" passe bien dans certaines configurations, avec le serveur filesystem qui va bien, le serveur web qui va bien et le navigateur qui va bien. Mais il est assez probable qu'en fonction du navigateur, certains visiteurs ne voient aucune photo. Ou alors toutes sauf celles qui ont un caractère accentué dans leur nom de fichier.

Les contraintes imposées pour la méthode synchro sont uniquement faites pour s'assurer qu'à partir du moment où la synchro est passée, votre photo s'affichera partout.

Les contraintes imposées pour la méthode synchro sont supprimées quand on utilise pLoader. pLoader accepte n'importe quel nom de fichier et ne vous ennuie jamais avec ça. Tout simplement parce que le fichier est renommé au niveau du serveur, en utilisant un schéma de nommage propre et logique. Là aussi, ce renommage permet d'assurer que la photo sera visible, quelque soit le navigateur, le serveur web, etc. Ca s'appelle la robustesse.

Avec Piwigo 2.0.9 + pLoader 1.5, le nom original du fichier sera stocké dans le champ images.file de la base de données, ce qui aura plusieurs conséquences:

1) quand on fait un tri par "nom de fichier", ça triera selon le nom original du fichier (demande de yoDan dans une discussion sur le forum central en anglais)

2) quand on va télécharger le fichier haute définition en cliquant sur la disquette, ça proposera d'enregistrer "件。这项 &@#$€.jpg" et pas "20090903192103-30de24e0.jpg"

3) quand on fera une recherche sur "这项", il trouvera la photo

Piwigo.org

Annonce

#31 2010-01-27 23:20:28

Re: [Evolution] pLoader et nom de fichier

#32 2010-01-27 23:25:14

Re: [Evolution] pLoader et nom de fichier

mathiasm a écrit:

mathiasm a écrit:

#33 2010-01-28 13:33:52

Re: [Evolution] pLoader et nom de fichier

#34 2010-01-28 15:14:22

Re: [Evolution] pLoader et nom de fichier

#35 2010-01-28 15:55:37

Re: [Evolution] pLoader et nom de fichier

#36 2010-01-28 16:27:46

Re: [Evolution] pLoader et nom de fichier

VDigital a écrit:

#37 2010-01-28 16:35:36

Re: [Evolution] pLoader et nom de fichier

flipflip a écrit:

flipflip a écrit:

flipflip a écrit:

#38 2010-01-28 17:37:30

Re: [Evolution] pLoader et nom de fichier

tosca a écrit:

plg a écrit:

Gotcha a écrit:

mathiasm a écrit:

#39 2010-01-28 18:08:05

Re: [Evolution] pLoader et nom de fichier

#40 2010-01-28 18:52:03

Re: [Evolution] pLoader et nom de fichier

plg a écrit:

#41 2010-01-28 20:39:23

Re: [Evolution] pLoader et nom de fichier

VDigital a écrit:

VDigital a écrit:

VDigital a écrit:

VDigital a écrit:

#42 2010-01-28 21:02:12

Re: [Evolution] pLoader et nom de fichier

plg a écrit:

#43 2010-01-28 21:27:31

Re: [Evolution] pLoader et nom de fichier

plg a écrit:

VDigital a écrit:

#44 2010-02-22 23:18:09

Re: [Evolution] pLoader et nom de fichier

plg a écrit:

ron a écrit:

tosca a écrit:

plg a écrit:

#45 2010-02-22 23:36:08

Re: [Evolution] pLoader et nom de fichier

Pied de page des forums