[spip-dev] Noms de documents conservés !!!

Bonjour,

voilà, j'en rêvais, je l'ai fait ... :wink:

Le but était que SPIP conserve les noms de fichier d'origine pour les
images, documents et vignettes uploadés dans les articles.

En me lançant, j'avais peur que ça me prenne des heures, mais a
priori, au bout de 15 minutes de travail, le code suivant fonctionne
chez moi, sur WinXP/EasyPHP 1.6

Je demande à tous ceux qui sont intéressés de tester avant de mettre
en production !!!

Tout d'abord, créer un répertoire 'docs' à la racine.

Ensuite, éditer 'spip_image.php3' et remplacer ce qui suit à partir de
la ligne 265 :

(re)bonjour,

voilà, j'en rêvais, je l'ai fait ... :wink:

Attention, ça fonctionne, mais ce n'est pas parfait :

- SPIP crée un fichier .test dans chaque sous-répertoire de document,
  fichier dont on doit pouvoir se passer

- si on supprimer un document, le répertoire associé n'est pas
  supprimé, à faire

Sinon, je confirme, mes tests sont toujours concluants.
  
-Nicolas

Sinon, je confirme, mes tests sont toujours concluants.

Le chemin d'accès à un fichier est de quelle forme, du coup ?

-- Fil

------------------------------------------------------------
if ($id_document_lie) {
       if (creer_repertoire('docs', 'doc'.$id_document_lie)) {
               creer_repertoire('docs/doc'.$id_document_lie, 'vig');
               $dest =
               'docs/doc'.$id_document_lie.'/vig/'.basename($orig);
       } else {
               $dest =
               'docs/doc'.$id_document_lie.'-vig-'.basename($orig);
       }
} else {
       if (creer_repertoire('docs', 'doc'.$id_document)) {
               $dest = 'docs/doc'.$id_document.'/'.basename($orig);
       } else {
               $dest = 'docs/doc'.$id_document.'-'.basename($orig);
       }
}
$dest_path = $dest;
------------------------------------------------------------

Vraiment bien, mais pourquoi un nommage aussi verbeux ?
Pourquoi pas IMG/pdf/mon_document.pdf à la place ?
(une petite gestion des doublons peut être faite rapidos avec
des file_exists())

a+

Antoine.

Hello,

Vraiment bien

Merci ... :wink:

mais pourquoi un nommage aussi verbeux ?

Pour éviter les doublons en assurant le respect total du nom de
fichier (si on peut créer des répertoires).

Pourquoi pas IMG/pdf/mon_document.pdf à la place ?

Pourquoi séparer les documents par type ???

Et là, tu ne gères pas du tout les doublons.

(une petite gestion des doublons peut être faite rapidos avec des
file_exists())

Avec ma méthode, aucune vérification à faire, et pas besoin (dans le
cas général) d'ajouter un compteur (pas beau) à un nom de fichier.

-Nicolas

Hello,

Le chemin d'accès à un fichier est de quelle forme, du coup ?

Le doc :
http://site-spip/docs/doc32/mon super document.pdf

Sa vignette :
http://site-spip/docs/doc32/vig/vignette bidon.png

Et là, je réagis tout de suite, avant de me faire huer :

Oui, il faudrait mettre des rawurlencode où c'est nécessaire pour les
caractères spéciaux comme les espaces ... :wink:

-Nicolas

Pourquoi pas IMG/pdf/mon_document.pdf à la place ?

Pourquoi séparer les documents par type ???

Parce qu'il vaut mieux les ventiler, histoire de ne pas avoir
des milliers de documents à la racine de IMG. Mais on peut
trouver un autre critère de ventilation, c'est juste que
c'était le plus naturel que j'avais trouvé.

Avec ma méthode, aucune vérification à faire, et pas besoin (dans le
cas général) d'ajouter un compteur (pas beau) à un nom de fichier.

Oui mais avec une vérif de doublons (qui ne coûte pas grand'chose),
tu n'a pas de compteur dans la majorité des cas, tandis que là tu as
un doc-1983 à tous les coups. En plus avec un répertoire séparé par
fichier, la navigation à la main (FTP, HTTP...) devient très lourdingue.

a+

Antoine.

Nicolas Hoizey wrote:

voilà, j'en rêvais, je l'ai fait ... :wink:

+ 100 000

En tout cas merci,
car tu n'étais pas seul à en rêver.

J'attends vos commentaires éclairés !!! :slight_smile:

... (A suivre)

a+
^Fabrice^^

Pourquoi séparer les documents par type ???

Parce qu'il vaut mieux les ventiler, histoire de ne pas avoir des
milliers de documents à la racine de IMG.

En effet.

Tu auras tout de même noté au passage, que j'ai déplacé ça dans un
répertoire 'docs', ce qui me paraît plus cohérent que 'IMG'. Je sais,
il y a le problème de la compatibilité avec les docs existants, mais
ceux-ci peuvent rester où ils sont pour l'instant, ça ne pose pas de
problème ... :wink:

Mais on peut trouver un autre critère de ventilation, c'est juste
que c'était le plus naturel que j'avais trouvé.

On peut ventiler comme actuellement, pas de problème, mais un site
n'aura en général que deux ou trois types de docs différents, donc ça
ventilera peu ... :wink:

Oui mais avec une vérif de doublons (qui ne coûte pas grand'chose),

Bin un accès disque, quand même, avec recherche dans la hash table du
répertoire, non ?

tu n'a pas de compteur dans la majorité des cas

Mouais. Je préfère "toujours" à "dans la majorité des cas" en général,
quand c'est le but recherché ... :stuck_out_tongue:

tandis que là tu as un doc-1983 à tous les coups.

A part dans le cas où on ne peut pas créer de répertoires, ce qui doit
être rare, on se fout de ce 'doc-1983', c'est le nom du fichier qui
nous intéresse.

En plus avec un répertoire séparé par fichier, la navigation à la
main (FTP, HTTP...) devient très lourdingue.

Par HTTP, on s'en fou, mais c'est vrai que c'est plus chiant par FTP.
Mais après tout, pourquoi aller voir les fichiers par FTP ???

-Nicolas

Attention, ça fonctionne, mais ce n'est pas parfait :

Bin tiens, qu'est-ce que je disais ...

Le perspicace Diablo a vu que ça ne marche pas trop bien du fait des
'IMG' qui se trouvent dans 'inc-calcul.php3' ...

-Nicolas

Bin un accès disque, quand même, avec recherche dans la hash table du
répertoire, non ?

Heu ! Vu le reste de ce que fait SPIP.....

$n = 0;
$nom = "docs/pdf/mon_fichier";
$ext = ".pdf";

while (file_exists($s = $nom . ($n ? "-$n" : "") . $ext)) $n++;

Ca par rapport à une connexion MySQL suivie d'une flopée de SELECT,
UPDATE, INSERT DELAYED... Et puis tu n'uploades pas 100 documents par
seconde, si ?

> Bin un accès disque, quand même, avec recherche dans la hash table du
> répertoire, non ?

Heu ! Vu le reste de ce que fait SPIP.....

Qui a dit "raison de plus" ? :slight_smile:

$n = 0;
$nom = "docs/pdf/mon_fichier";
$ext = ".pdf";

/* PAC, ne pas oublier */
cleartstatcache();

while (file_exists($s = $nom . ($n ? "-$n" : "") . $ext)) $n++;

Dans l'absolu, il vaudrait d'ailleurs mieux l'inclure dans l'exécution
de la boucle WHILE pour éviter le cas où le gars qui fait son upload
s'excite sur son bouton et que deux upload ont lieu en même temps, sauf
si un mécanisme externe gère déjà ce cas.

Ca par rapport à une connexion MySQL suivie d'une flopée de SELECT,
UPDATE, INSERT DELAYED...

Raison de plus pour ne pas en ajouter non ? Les accès au file system
sont en temps aussi, voire plus coûteux qu'un accès SGBD (qui gère un
cache mémoire justement dans le but de ne pas avoir à en faire de trop).

a++
JG

From nhoizey@php.net Tue Oct 1 17:01:12 2002

Return-Path: <nhoizey@php.net>
Received: from lautre.net (estelle.lautre.net [80.67.164.8])
  by miel.brainstorm.fr (Postfix) with SMTP id 741781C2E1
  for <spip-dev@rezo.net>; Tue, 1 Oct 2002 17:01:12 +0200 (CEST)
Received: (qmail 7293 invoked by alias); 1 Oct 2002 15:01:10 -0000
Received: from unknown (HELO 172.16.19.11) (195.146.226.44)
  by estelle.lautre.net with SMTP; 1 Oct 2002 15:01:10 -0000
X-Mailer: The Bat! (v1.61)
X-Priority: 3 (Normal)
Message-ID: <2027806012.20021001170106@phpheaven.net>
In-Reply-To: <41267.80.67.170.17.1033483936.squirrel@rezo.net>
References: <11926819584.20021001164440@phpheaven.net>
<41267.80.67.170.17.1033483936.squirrel@rezo.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-BeenThere: spip-dev@rezo.net
X-Mailman-Version: 2.1b2+
Precedence: list
List-Help: <mailto:spip-dev-request@rezo.net?subject=help>
List-Archive: <http://listes.rezo.net/archives/spip-dev>
List-Unsubscribe: <http://listes.rezo.net/mailman/listinfo/spip-dev>,
  <mailto:spip-dev-request@rezo.net?subject=unsubscribe>
List-Subscribe: <http://listes.rezo.net/mailman/listinfo/spip-dev>,
  <mailto:spip-dev-request@rezo.net?subject=subscribe>
List-Post: <mailto:spip-dev@rezo.net>
List-Id: SPIP : developpement <spip-dev.rezo.net>
X-List-Received-Date: Tue, 01 Oct 2002 15:01:12 -0000
Status: O
Content-Length: 708
Lines: 30

Heu ! Vu le reste de ce que fait SPIP.....

:wink:

$n = 0;
$nom = "docs/pdf/mon_fichier";
$ext = ".pdf";
while (file_exists($s = $nom . ($n ? "-$n" : "") . $ext)) $n++;

Ca par rapport à une connexion MySQL suivie d'une flopée de SELECT,
UPDATE, INSERT DELAYED...

Un INSERT DELAYED pour insérer le document
Un UPDATE du document associé si c'est une vignette

Quoi de plus ?

Et il les faut tout autant avec ta méthode.

Et puis tu n'uploades pas 100 documents par seconde, si ?

Non, pas pour l'instant ... :wink:

-Nicolas

Hello,

j'essaie de finaliser cette histoire de noms de fichiers conservés
pour les documents, ça me titille ... :wink:

Le perspicace Diablo a vu que ça ne marche pas trop bien du fait des
'IMG' qui se trouvent dans 'inc-calcul.php3' ...

En fait, il n'y a pas d'erreur, les IMG sont là pour les logos, pour
lesquels ma modif n'entrait pas en compte.

Diablo, tu es sûr qu'il y a un problème ???

-Nicolas

Hello,

Pourquoi séparer les documents par type ???

Parce qu'il vaut mieux les ventiler, histoire de ne pas avoir des
milliers de documents à la racine de IMG.

Bon, j'ai essayé de faire ça, mais pour que ça reste simple, la
vignette est gérée à part, donc ça donne ça :

Document :
http://localhost/docs/jpg/doc7/document.jpg

Vignette :
http://localhost/docs/gif/doc7/vig/vignette.gif

Je ne trouve pas génial que les deux soient séparés, mais en mettant
la vignette avec son doc on aura des .gif (ou autres images) dans un
sous répertoire d'une autre extension, pas terrible non plus ...

Une idée ?

-Nicolas

Bonjour,

Document :
http://localhost/docs/jpg/doc7/document.jpg

Vignette :
http://localhost/docs/gif/doc7/vig/vignette.gif

Une idée ?

Pourquoi pas :

Document :
    http://localhost/docs/jpg/7/document.jpg

Vignette :
    http://localhost/docs/gif/7/document-s.jpg

?

Gilles.

Y'aura conflit si tu envoies par la suite un fichier "document-s.jpg".

Bonjour,

une heure de train, y'a rien de tel pour se prendre en main et coder
un peu pour SPIP ... :wink:

Toujours à propos du respect des noms de fichier uploadés, j'ai ajouté
un 'rawurlencode' ligne 44 du fichier 'ecrire/inc_documents.php3',
donc

$fichier = $row['fichier'];

devient

$fichier = urlencode($row['fichier']);

Cela permet entre autre de ne pas avoir d'espaces dans l'URL s'il y en
a dans le nom du fichier. Ils sont remplacés par des %20

Par contre, j'ai encore un dernier soucis, au niveau des accents.

Ainsi, si j'uploade un fichier dont le nom comporte un 'é', il
apparaît bien tel quel dans la base (en tout cas vu depuis phpMyAdmin)
et dans l'URL générée par SPIP, mais quand j'essaie d'y accéder Apache
(EasyPHP 1.6 sur WinXP Pro) me renvoie une erreur 404 et dans les logs
le 'é' est remplacé par 'ã©' ...

Un problème d'encodage à priori, genre UTF8, mais je n'y connais pas
grand chose, donc si quelqu'un a une idée, ça m'intéresse ... :wink:

Une fois ce problème réglé, est-ce que quelqu'un voit un inconvénient
à ce que cela soit intégré dans SPIP ?

-Nicolas

@ Nicolas Hoizey <nhoizey@php.net> :

Par contre, j'ai encore un dernier soucis, au niveau des accents.

Il faut sécuriser : tu peux passer une fonction qui remplace tous les é par
des e, etc, et tous les caractères en-dehors d'une plage restreinte
([.0-9A-Za-z] par exemple) par des _, comme ça tu es sûr de ne pas générer
de problèmes. Fais gaffe aussi à la longueur du nom du fichier, elle ne peut
pas dépasser je-ne-sais-plus-combien sur certains OS (cf. le calcul du nom
du fichier cache).

Une fois ce problème réglé, est-ce que quelqu'un voit un inconvénient
à ce que cela soit intégré dans SPIP ?

A priori c'est plutôt un plus :wink:

Aussi : ce qui serait nécessaire, pour les docs et les images, serait une
option "remplacer cette image" : si on veut retoucher un doc, actuellement,
il faut effacer puis recréer, ce qui fait perdre les références internes
<DOC12|left> et les titres, descriptif... Rien de compliqué, il faut juste
trouver comment ne pas alourdir l'interface...

-- Fil

Hello,

Par contre, j'ai encore un dernier soucis, au niveau des accents.

Il faut sécuriser : tu peux passer une fonction qui remplace tous
les é par des e, etc, et tous les caractères en-dehors d'une plage
restreinte ([.0-9A-Za-z] par exemple) par des _, comme ça tu es sûr
de ne pas générer de problèmes.

Mais du coup je perds mon nom de fichier, ce que je cherche justement
à éviter !

Tout comme les espaces sont remplacés par des %20, les é devraient
être remplacés par des %E3 (si je ne m'abuse) ...

Fais gaffe aussi à la longueur du nom du fichier, elle ne peut pas
dépasser je-ne-sais-plus-combien sur certains OS (cf. le calcul du
nom du fichier cache).

Il faudrait que la personne qui va uploader soit prévenue, qu'elle
prenne elle-même en charge le renommage du fichier.

Une fois ce problème réglé, est-ce que quelqu'un voit un
inconvénient à ce que cela soit intégré dans SPIP ?

A priori c'est plutôt un plus :wink:

Ouf ... :wink:

Aussi : ce qui serait nécessaire, pour les docs et les images,
serait une option "remplacer cette image" [...]

En effet, ce serait sympa.

-Nicolas

> Il faut sécuriser : tu peux passer une fonction qui remplace tous
> les é par des e, etc, et tous les caractères en-dehors d'une plage
> restreinte ([.0-9A-Za-z] par exemple) par des _, comme ça tu es sûr
> de ne pas générer de problèmes.

Mais du coup je perds mon nom de fichier, ce que je cherche justement
à éviter !

Entre doc33.pdf et L_enervement_de_Nico.pdf, il y a quand même une
différence. Je préfère aussi, sur le plan esthétique, les _ aux %20 dans les
URLs.

Tout comme les espaces sont remplacés par des %20, les é devraient
être remplacés par des %E3 (si je ne m'abuse) ...

Beurk.

Il faudrait que la personne qui va uploader soit prévenue, qu'elle
prenne elle-même en charge le renommage du fichier.

Non. Comme dirais Walk, tu joues à l'"informaticien" là : spip n'est pas
fait pour imposer des contraintes aux utilisateurs, mais bien l'inverse.

-- Fil