SPIP-Contrib

SPIP-Contrib

عربي | Deutsch | English | Español | français | italiano | Nederlands

286 Plugins, 197 contribs sur SPIP-Zone, 205 visiteurs en ce moment

Accueil > Administration et BDD > Gestion des documents > Hasher les documents > Le plugin hash_documents

Le plugin hash_documents

1er novembre 2009 – par Fil – 32 commentaires

17 votes

Le nombre de documents dans le répertoire IMG/{$ext}/ du site peut devenir beaucoup trop important et avoir un impact sur les performances du système de fichiers du serveur. La solution proposée par ce plugin est de « hasher » le répertoire IMG/.

De manière à limiter le nombre d’inode dans chaque sous-dossier de IMG/, on répartit automatiquement les fichiers dans des sous-sous-répertoires. La structure passe ainsi de
IMG/mp3/fichier-son.mp3
à
IMG/mp3/a/b/c/fichier-son.mp3

Ce plugin s’occupe de tout pour vous.

En SPIP 2, une page ecrire/?exec=hash_documents permet d’aller hasher tous les documents déjà installés (mais il n’est pas indispensable de l’utiliser pour que ça fonctionne). On peut à tout moment revenir en arrière (grâce à cette même page). En SPIP3, elle est accessible via la page d’administration des plugins (ecrire/?exec=configurer_hasher).

Dans tous les cas, la désactivation du plugin n’empêche pas le site de fonctionner normalement.

Ci-dessous, les explications techniques :

Structure du hashage

le sous-répertoire a/b/c/ doit être calculé de manière à ce que la répartition des documents soit homogène et prévisible. On utilisera pour ce faire une fonction de hashage très simple consistant à prendre les n premiers caractères du md5 du nom du fichier.

md5 ayant une représentation hexa, le nombre de sous-répertoires ainsi créés sera de l’ordre de 16^n ; pour répartir correctement un million de documents, on a les possibilités suivantes :

— n=1 16 répertoires * 62500 docs
— n=2 256 rép * 3900 docs
— n=3 4096 rép * 244 docs

Dans cette implémentation, on utilise 3 niveaux de sous-répertoires : pour un fichier d’origine situé dans IMG/{$ext}/xxxx.ext, le hasher consiste à prendre les 3 premiers caractères (a, b, c) du md5(xxxx.ext), et déplacer le fichier dans IMG/$ext/a/b/c/xxxx.ext.

fonction : function hasher_adresser_document(xxxx.ext)

Déplacement d’un document

fonction : function hasher_deplacer_document($id_document) {}

Cette fonction a pour rôle de déplacer un document proprement de sa position non hashée vers sa position hashée. Tous les contrôles d’erreur sont mis en place afin de garantir que tout se passe bien : si la création du sous-répertoire échoue, par exemple, ou si la connexion à la base de données est tombée, il faut pouvoir reprendre.

Elle appelle hasher_adresser_document()

Conversion « batch »

fonction : function hasher_deplacer_n_documents($n) {}

Cette fonction prend les n documents non hashés les plus récents, et appelle hasher_deplacer_document() sur chacun d’eux. Elle renvoie un array() contenant les id_document des documents qu’elle a déplacés.

Elle peut servir à convertir l’existant (on l’appelle répétitivement jusqu’à épuisement du stock), ou juste après un upload (en SPIP 1.9.2, car en SPIP 2 le cas de l’upload est géré nativement via le pipeline ad hoc), ou un spip2spip, afin de hasher les documents qu’on vient d’ajouter [1].

Elle peut aussi être appelée depuis la page ecrire/?exec=hash_documents

Gestion de redirection

Lorsqu’un document a été déplacé, on souhaite qu’un hit sur son ancienne adresse renvoie vers la nouvelle adresse, avec un code HTTP 301 Moved Permanently (redirection définitive).

Ceci permet, d’une part, de gérer proprement la migration ; d’autre part, ça implique qu’il n’est pas indispensable de hasher les documents juste après l’upload, donc beaucoup de souplesse dans l’intégration.

On va pour ce faire ajouter un .htaccess dans le répertoire IMG/ qui lancera, sur les fichiers non trouvés, un script de redirection écrit en PHP ; ce dernier calculera l’adresse hashée du document demandé, vérifiera si ce document est présent, et en fonction du résultat renverra soit un code 301 vers ce document, soit un 404 Not Found.

Le script PHP est le fichier hash_404.php présent dans le plugin ; la seule petite difficulté pour son activation, c’est qu’il nécessite la création d’un .htaccess spécifique dans le répertoire IMG/ contenant le code suivant :

En fonction de la configuration technique de l’hébergeur, il faudra peut-être adapter un peu ce .htaccess.

Compatibilité

Il est important de noter que la structure proposée pour le code offre nativement une grande compatibilité, puisque, une fois les documents hashés, on peut retirer tout le code de hachage sans impact sur le fonctionnement.

On a pris soin de ne pas utiliser de fonctions « fragiles » de SPIP, qui changeraient d’une version à l’autre, afin que ce plugin soit compatible de SPIP 1.9.2 aux SPIP futurs.

La seule difficulté à prendre en compte est que le nommage des documents dans la table spip_documents a changé entre SPIP 1.9.2 et la série SPIP 2.0. En SPIP 1.9.2, en effet, spip_documents.fichier contenait une chaîne de la forme IMG/jpg/postcards.jpg, tandis qu’en SPIP 2 on a simplement jpg/postcards.jpg (le IMG/ a été supprimé).

Le plugin fonctionne nativement avec les deux représentations (avec ou sans IMG/).

Réversibilité

Les fonctions de hashage sont réversibles : un paramètre $rev permet de revenir à la structure « à plat ». Cela permet de revenir en arrière si finalement on ne souhaitait pas utiliser ce système, ou pour en utiliser un autre. Cela a aussi permis de tester le plugin, lors de son développement, en faisant des allers-retours.

Voir en ligne : http://plugins.spip.net/hasher

Notes

[1Patch à appliquer aux fonctions qui ajoutent des fichiers dans spip_documents :

Dernière modification de cette page le 10 avril 2016

Retour en haut de la page

Vos commentaires

  • Le 2 novembre 2009 à 10:57, par Nicolas Hoizey En réponse à : Le plugin hash_documents

    Ah, au fait, tant qu’on y est, serait-il envisageable de hasher aussi les logos, j’en ai beaucoup, puisque j’ai beaucoup de rubriques et articles...

    • Le 2 novembre 2009 à 11:04, par Fil En réponse à : Le plugin hash_documents

      Hasher les logos n’est pas prévu, mais sens-toi libre de le coder en option. En option seulement, car la caractéristique du plugin actuel est qu’on le désactive quand on veut sans perdre aucune fonctionnalité. Pour les logos c’est impossible en l’état actuel de SPIP.

    • Le 2 novembre 2009 à 11:06, par Nicolas Hoizey En réponse à : Le plugin hash_documents

      Oui, je sais bien que les logos posent problème, avec leur stockage direct à la racine. Les passer en gestion comme des docs à part entière est sans doute nécessaire, et hash_documents pourra alors les prendre en charge... ;-)

    • Le 8 février 2013 à 10:13, par Max En réponse à : Le plugin hash_documents

      Bonjour,

      Est-ce que avec la version spip 2.1 le plugin permet de hasher les logos ?

    Répondre à ce message

  • Le 3 juin 2011 à 12:56, par Yffic En réponse à : Le plugin hash_documents

    Bonjour

    Sur un site de photographe, j’ai un souci. Je ne peux plus afficher la page de vidage du cache. Enfin j’ai une page blanche. Ca bloque au moment du calcul de l’espace sur local/cache-vignettes. Dans ce dossier, il y a 600 dossiers differents. En utilisant la fonction calculer_taille_dossier de exec/admin_vider dans un fichier php séparé, j’ai reussi à aller une fois jusqu’au bout, il m’a trouvé plus de 2Go de données. Je ne sais pas ce qui bloque l’execution du script, le max_execution_time ?
    Si on regarde la fonction de calcul de la taille du cache normal, on voit que si y’a trop de fichiers on ne fait qu’une estimation de la taille.

    Ensuite en listant le contenu de IMG/jpg, je me rend compte qu’il y a dans les 56000 fichiers... J’envisage du coup d’installer le plugin Hash Document qui ne peut qu’améliorer les performances... Dans la doc du plugin il est écrit que la « page ecrire/ ?exec=hash_documents permet d’aller hasher tous les documents déjà installés »... Est ce-qu’on est sûr que cette requête ira jusqu’au bout de son exécution sans etre génée par le max_execution_time ?

    Je ne suis pas sur d’être clair ;-)

    • Le 8 juin 2011 à 08:44, par Fil En réponse à : Le plugin hash_documents

      (je t’ai répondu sur la liste)

    • Le 22 juin 2011 à 15:22, par Yffic En réponse à : Le plugin hash_documents

      OK merci Fil... Je viens de tester, tout s’est déroulé sans problème...

      Par contre, la redirection via le .htaccess ne fonctionne dans le cas d’une mutualisation par domaine car le fichier /plugins/hash_documents/hash_404.php n’est pas accessible. J’ai testé en mettant ce fichier dans le sous dossier exec du plugin et en changeant dans le .htaccess :

      RewriteRule .* /ecrire/?exec=hash_404 [L]

      Et en ré-écrivant un peu les chemins dans ce même fichier... Ca fonctionne. Je peux essayer d’aller plus loin et rendre l’ensemble générique aux cas sans ou avec mutualisation, si tu penses que c’est une solution envisageable

    • Le 22 juin 2011 à 15:43, par Fil En réponse à : Le plugin hash_documents

      Le passage en exec est certainement plus générique ; n’hésite pas à le commiter

    • Le 22 juin 2011 à 15:44, par Fil En réponse à : Le plugin hash_documents

      quoique, à y réfléchir un peu plus, ça ne devrait pas être un « exec » (associé à l’espace privé), mais un « action ».

    • Le 22 juin 2011 à 20:05, par Yffic En réponse à : Le plugin hash_documents

      OK, c’est fait

      J’ai changé le contenu du .htaccess, du coup faudrait mettre l’article à jour

    • Le 22 juin 2011 à 21:47, par Fil En réponse à : Le plugin hash_documents

      OK super, j’ai simplifié un peu ton code en révision 49003 et mis à jour la doc ; merci !

    • Le 28 décembre 2011 à 22:16, par Julien Lanfrey En réponse à : Le plugin hash_documents

      Bonjour,

      Tout d’abord bravo pour cet excellent plugin très souple et qui fonctionne à merveille !

      Je suis en train de mettre en place les redirections.
      (site installé à la racine d’un hébergement ovh)

      Avec le code de base : RewriteRule .* ../index.php ?action=hash_404 [L]
      J’obtiens une erreur « Fichier hash_404 introuvable »

      J’ai tenté une autre règle précisée dans hash_404.php :
      RewriteRule .* /ecrire/ ?action=hash_404 [L]
      et je tombe (naturellement ?) sur la page d’authentification de spip...

      Quelle est la bonne façon d’appeler (non connecté) la page hash_404. ?

    • Le 29 décembre 2011 à 14:15, par Fil En réponse à : Le plugin hash_documents

      Peut-être ajouter en haut du fichier .htaccess la ligne

      RewriteBase /
    • Le 29 décembre 2011 à 19:28, par Julien Lanfrey En réponse à : Le plugin hash_documents

      Merci pour la réponse.
      En fait le pb est autre et le htaccess de cette doc est bonne à priori.
      J’ai du corriger plusieurs choses dans le fichier action/hash_404.php :

      1 - Il faut mettre tout le code dans une fonction :

      1. function action_hash_404_dist(){
      2. [ici le code du fichier]
      3. }

      Télécharger

      j’étais sous SPIP 2.1.12 et sans ça, SPIP renvoie une erreur en arrière plan avec le logo de l’écureuil et tout...

      2 - j’ai du remplacer les chemins des file_exists :

      1. file_exists('../'.$GLOBALS['meta']['dir_img'].$dest)

      remplacé par :

      1. file_exists('./'.$GLOBALS['meta']['dir_img'].$dest)

      (je ne comprend pas bien pourquoi. D’où le script est t-il vraiment lancé ?...)

      3 - Par ailleurs, je note une coquille : dans les 2 tests « file_exists » (selon que le fichier d’origine était un fichier hashé ou non), on peut voir une affectation à « dest1 » au lieu de « dest ». (« dest1 » ne servant à rien par la suite).

      Bon, ça fonctionne comme ça mais je crois que le chemin relatif est à réviser. Notamment, il risque de différer selon que la source est un fichier hashé ou non ...?)
      non ?

    • Le 29 décembre 2011 à 21:53, par Yffic En réponse à : Le plugin hash_documents

      Hello

      Concernant le point 3, c’est ma faute. J’ai corrigé et commité

      Pour le point 1, je viens de retester, ca fonctionne correctement sans mettre le code dans une fonction. Et ca fonctionne toujours si on le met dans la fonction, ce que j’aurais aussi du faire quand j’ai déplacé le fichier dans le dossier action. Mais à l’époque je n’étais pas bon en « action »... Juste un peu plus maintenant ;-) Par contre comment ça fait pour fonctionner sans, la je ne pige pas, car spip est censé chercher la fonction lors de l’aiguillage. Fil peut etre peux tu nous éclairer ? Et me dire si je peux commiter cette modif aussi ?

      Enfin, le point 2 : chez moi ta proposition ne fonctionne pas. Ca me semble normal, vu qu’on part du dossier ecrire (/ecrire/ ?action=hash_404 [L]) et qu’il faut remonter d’un niveau pour aller dans IMG. Non ?

    • Le 29 décembre 2011 à 22:28, par Julien Lanfrey En réponse à : Le plugin hash_documents

      salut, merci pour ce retour, j’ai compris 2,3 trucs du coup.

      Point 3 : ok
      Point 1 : à suivre... (dans mes tests, j’avais bien le message prévu en cas de fichier non trouvé mais en plus et au dessous, une erreur de spip dans un cadre blanc... indiquant « Fichier hash_404 introuvable »)

      Point 2 : tu ne dois pas avoir la même chose que moi dans ton htaccess. En fait j’ai pris la règle de réécriture de la doc :
      RewriteRule .* ../index.php ?action=hash_404 [L]

      L’appel se fait donc depuis la racine du site. Ce qui est mieux à priori car si on le fait dans /ecrire, on a droit à une page d’authentification il me semble)

      Mais effectivement, il faudrait mettre d’équerre les exemples de règles de réécriture en commentaire dans le hash_404.php pour que ce soit conforme à cette doc.

    • Le 29 décembre 2011 à 23:53, par Yffic En réponse à : Le plugin hash_documents

      Pour le point 1, j’avais bien comme tu dis, j’avais pas compris dans ton premier post.

      Concernant le point 3, le code à mettre dans le .htaccess est en commentaire dans le fichier action/hash_404.php

      Je mets cet article à jour

    • Le 30 décembre 2011 à 00:46, par Yffic En réponse à : Le plugin hash_documents

      Ouille, crise de panique, plus rien ne fonctionnait...

      Donc, si tu peux confirmer le point 3 :

      -  dans le fichier action/hash_404.php, le test doit se faire par rapport à la racine du site :
      file_exists('./'.$GLOBALS['meta']['dir_img'].$dest)
      -  dans le fichier .htaccess, dans un cas classique, on peux travailler en relatif :
      RewriteRule .* ../index.php?action=hash_404 [L]
      mais dans le cas d’une mutu, ça ne fonctionne qu’en absolu (je viens de vérifier) :
      RewriteRule .* /index.php?action=hash_404 [L]

    • Le 30 décembre 2011 à 11:49, par Julien Lanfrey En réponse à : Le plugin hash_documents

      Donc, pour résumer, le fichier php se base bien sur le répertoire courant (./) qui correspond dans notre cas à la racine du site vu qu’on appelle le script depuis la racine (index.php ?action=hash_404).
      Et ça doit bien se passer comme ça pour tous je suppose ?
      et donc je crois qu’il y a qu’un seul cas pour le fichier php effectivement.

      Ensuite, pour appeler ce script dans de bonne condition, il faut l’appeler depuis la racine du site. Et la je ne suis pas spécialiste des règles de réécritures mais dans mon cas « simple » suivant :
      www.domaine.com/IMG/jpg/photo.jpg

      mon .htaccess se trouvant dans IMG, le contexte de la règle de réécriture est ce dossier IMG et c’est pourquoi on fait ../ pour chopper la racine du site. (je suppose car si le contexte est IMG/jpg, je ne comprend plus pourquoi ça marche chez moi :-) )

      Je ne connais pas les différences avec les sites mutualisés.
      Par contre, je viens de faire le test en absolue chez moi :
      RewriteRule .* /index.php ?action=hash_404 [L]

      et ça fonctionne aussi (moyennant 2 ou 3 refresh d’écran, car un changement de htaccess à la volée pose parfois soucis...)

      Donc ce que je pense au niveau du htaccess :
      -  soit le ../ permet de tomber sur la racine du site dans tous les cas et c’est le plus simple (mais tu sembles dire que ce n’est pas le cas dans les mutualisés - ou pb lié au changement de htaccess à la volée ??)
      -  soit tout le monde se base en absolue mais dans ce cas, il faut préciser dans la doc d’écrire :
      — > /index.php si le site est à la racine du domaine
      — > /rep1/rep2/rep3/ si le site est ailleurs sur le domaine

    • Le 31 décembre 2011 à 12:58, par Yffic En réponse à : Le plugin hash_documents

      Hello

      J’ai commité les modifs. Je laisse les 2 exemples dans le .htaccess

    • Le 31 décembre 2011 à 13:24, par Julien Lanfrey En réponse à : Le plugin hash_documents

      Excellent !

    Répondre à ce message

  • Le 2 novembre 2009 à 10:31, par Manu_TJ En réponse à : Le plugin hash_documents

    Bonjour

    je voudrais tester ce plugin mais je ne trouve pas l’endroit où le télécharger. Suis-je mal réveillé ?

    Manu

    Répondre à ce message

  • Le 30 juin 2011 à 14:48, par Yffic En réponse à : Le plugin hash_documents

    Salut Fil

    Bon quand j’ai dis tout s’est déroulé sans problème... heu je me suis trompé... En fait environ 2000 fichiers sur les 55000 ont été déplacés dans les sous-répertoires mais le renommage en base ne s’est pas fait... Je pige pas bien comment mais bon, c’est une constatation... Donc j’ai modifié la fonction hasher_deplacer_document pour que si le fichier qu’on veut déplacer est déjà déplacé, on modifie juste le chemin en base... Ca m’a permis de remettre l’ensemble d’équerre...

    Je ne suis pas sur que ce soit une bonne idée de commiter cela, car faut quand même être sûr que les fichiers ont des noms uniques sinon, ca peut tout casser... Je garde pour moi, je laisse dans le code mais en commentaire ou je rajoute une case a cocher (avec explication) ?

    Répondre à ce message

  • Le 7 novembre 2009 à 06:07, par philooo En réponse à : Le plugin hash_documents

    oui le classement par date c’est l’ideal pour les gros sites, car en plus ca permet de localilser les documents anciens sur un serveur separe par exemple. avec quelque regle de htaccess, on peut rediriger le visiteur en fonction des dates d’images.

    Quand on a des centaines voir milliers de docs c’est tres vite indispendable d’utiliser plusieur serveurs dedie pour les images.

    • Le 7 novembre 2009 à 08:31, par Fil En réponse à : Le plugin hash_documents

      On pourrait ajouter une option « classement par date » à ce plugin, toute la mécanique est là.

      Mais quand tu parles de « plusieurs serveurs dédiés », je m’interroge. Est-ce qu’il s’agit de capacité disque ? Dans ce cas, personnellement, je recommanderais plutôt l’utilisation de serveur de type « cloud » (Amazon S3 pour ne pas le nommer). Je serais intéressé à avoir un exemple d’application auquel tu penses.

    Répondre à ce message

  • Le 2 novembre 2009 à 17:53, par goony En réponse à : Le plugin hash_documents

    J’ai de mon côté patché SPIP pour créer des sous-répertoire par date :

    jpg/200901/
    jpg/200902/
    jpg/200903/

    etc...

    Je n’avais pas conaissance de ce plugin, mais dans le passé j’avais fait la même chose que je fais maintenant avec le hash comme le cache (en gros comme ce système mais à un seul niveau).

    Ce système par date n’est pas mal car il nous permet de regrouper plus ou moins les documents par articles (à moins qu’on upload des documents sur une très longue période), et ca peut aider à situer leur date d’upload, les articles correspondants, et retrouver les documents plus vite et intuitivement sur le disque.

    Si ca peut donner des idées...

    Benoit

    Répondre à ce message

  • Le 2 novembre 2009 à 10:56, par Nicolas Hoizey En réponse à : Le plugin hash_documents

    Excellente nouveauté pour les sites avec beaucoup de docs !

    Je viens de le mettre en place sur un site SPIP 2, et il n’arrive pas à hasher 90 document sur les un peu plus de 3000 que j’ai. Tous ces 90 semblent avoir un nom comportant au moins un chiffre...

    Répondre à ce message

Répondre à cet article

Qui êtes-vous ?

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici Les choses à faire avant de poser une question (Prolégomènes aux rapports de bugs. )
Ajouter un document

Retour en haut de la page

Ça discute par ici

  • Acces Restreint 3.0

    11 décembre 2008 – 784 commentaires

    Le plugin accès restreint permet de définir et de gérer des zones de l’espace public en accès restreint. Cette version du plugin a été redévelopée et optimisée tout spécialement pour SPIP 2.0. Il en découle une amélioration des performances sur les gros (...)

  • Champs Extras 3

    16 janvier 2012 – 538 commentaires

    Ce plugin permet de créer et/ou de gérer des champs supplémentaires dans les objets éditoriaux de SPIP. Il permet donc de prendre en compte et d’afficher de nouveaux éléments dans n’importe quel objet éditorial de SPIP. Screencast Vous n’aimez pas (...)

  • Réservation d’événements

    16 mars 2015 – 190 commentaires

    Ce plugin permet d’offrir aux visiteurs de s’inscrire pour un évènement du plugin Agenda et de gérer les réservations enregistrées. Installation Le plugin s’installe comme n’importe quel plugin. il nécessite : Agenda API de vérification (...)

  • Les crayons

    23 avril 2008 – 815 commentaires

    Ce plugin permet d’éditer les contenus sur les pages publiques du site, sans passer par l’espace privé de SPIP.

  • LESS pour SPIP : Less-CSS (anciennement LESSpip)

    5 novembre 2010 – 43 commentaires

    Less-CSS (Anciennement LESSpip) est un plugin intégrant facilement le logiciel LESS dans SPIP. LESS est une extension de CSS ajoutant les variables, les classes, les opérations, les imbrications au langage. Facilitant ainsi l’écriture de (...)

Ça spipe par là