Le plugin hash_documents - commentaires

Le plugin `hash_documents`

OK,
et bien c'est releasé sous le numero v3.0.1

Le plugin `hash_documents`

Cela fonctionne : les logos sont désormais hashés.
Pour le 2è problème, il semble avoir disparu avec cette branche.

Le plugin `hash_documents`

Cela fonctionne : les logos sont désormais hashés.
Pour le 2^d, il semble avoir disparu lorsque j'ai installé cette branche, peut-être une mauvaise installation lors du passage à la 3.0.0 ?

Le plugin `hash_documents`

Pour le premier problème, peux tu tester la branche suivante :

https://git.spip.net/spip-contrib-extensions/hash_documents/src/branch/bugs_gilles

pour le second problème, difficile de dire, mais vu ce que je te disais sur les compats de spip 4 avec php 8 ce serait pas impossible que le pb viennent de là.

Tu a accès aux logs PHP ?

Le plugin `hash_documents`

Ah oui, car il y a un presupposé dans la regexp que le nom du dossier = le nom de l'extension.

Bon, faut reussi à trovuer une regexp qui passe aussi pour les logos...

Le plugin `hash_documents`

J'ai identifié un premier soucis : désormais, les logos apparaissent dans la table spip_documents. Or, le plugin ne les hashe pas.
Lorsque, depuis la page de configuration, on souhaite hasher 100 documents, mais qu'il n'y a que des logos, le plugin ne hashe rien, alors qu'il peut y avoir des documents à hasher en 101è position.
En revanche, je n'ai pas trouvé pourquoi l'adresse n'est pas hashée lorsqu'on ajoute un nouveau document.

Le plugin `hash_documents`

En 8.1 mais avec la version de dev de SPIP : ca marche.

En 8.1 avec spip 4.1.0-alpha : ca marche

En 8.1 avec spip 4.0.4 : j'ai trop de warning pour ne serait-ce qu'arriver à une page d'upload de document.

A vu de nez, je dirais qu'à mon avis vue que spip 4 n'est pas censé être compatible php 8.1 mais uniquement 8.0, cela pourrait venir de là...

Le plugin `hash_documents`

Ah c'est possible... je vais voir si j'arrive à me mettre une 8.1...

Le plugin `hash_documents`

Cela vient peut-être de PHP8.1 (mais c'était déjà le cas auparavant). Comment le vérifier ?

Le plugin `hash_documents`

Est-ce que ça pourrait venir de PHP 8.1 ? Comment le vérifier ?

Le plugin `hash_documents`

Je viens de tester avec spip 4.0.4 + plugin en v3.0.0 > pas de souci de mon côté.

Le plugin `hash_documents`

Bonjour,
Depuis le passage de SPIP à la version 4.0.2, le plugin ne fonctionne plus : les nouveaux documents sont stockés à la racine du répertoire de l'extension.
De plus, étrangement, s'il est toujours possible de hasher et déhasher les anciens documents (ceux ajoutés avant le passage à la 4.0.2), cela n'est plus possible pour ceux ajouter après le passage (la liste des Id des documents modifiés est vides). Je dis « étrangement » parce que rien dans la base de données ne semble différencier les uns et les autres...

Le plugin `hash_documents`

Je vais en profiter pour corriger tous les appels aux vieilles fonctions.

Le plugin `hash_documents`

Après quelques recherches, il suffit de remplacer la fonction spip_fetch_array() par sql_fetch() dans le fichier hasher_fonctions.php

Le plugin `hash_documents`

Il faudrait tester en modifiant les bornes dans paquet.xnl pour voir si cela marche, et si c'est le alors on pourra modifier la version distribué. Sinon faudra que quelqu'un s'attelle à la tache d'une maj.

Le plugin `hash_documents`

Bonjour, le plugin ne fonctionne plus sous SPIP 4.0. Sa mise à jour est-elle prévue ?

Le plugin `hash_documents`

Pour compléter la documentation, pourrait-on préciser à partir de quand ce plugin devient intéressant. De l'ordre de 10kdocument ? 100kdocument ? 1MDocument ?

Le plugin `hash_documents`

Bonjour,

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

Le plugin `hash_documents`

Excellent !

Le plugin `hash_documents`

Hello

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

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 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 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 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 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 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 :

function action_hash_404_dist(){ [ici le code du fichier]
}

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 :

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

remplacé par :

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 plugin `hash_documents`

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

RewriteBase /

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 plugin `hash_documents`

S'il n'y a pas de lien en haut à droite de cet article, il est disponible sur le site des plugins spip : http://plugins.spip.net/hasher.html

Le plugin `hash_documents`

Quelle proposition ? avec la case à cocher ?

Le plugin `hash_documents`

oui, ok, n'hésite pas

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) ?

Le plugin `hash_documents`

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

Le plugin `hash_documents`

OK, c'est fait

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

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 plugin `hash_documents`

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

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 plugin `hash_documents`

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

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 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.

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 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

Le plugin `hash_documents`

Via Subversion, oui.

Le plugin `hash_documents`

Comment avez vous fait pour récupérer le plugin ? Il faut obligatoirement utiliser svn ?
Je ne le trouve pas ici : http://files.spip.org/spip-zone/
Merci par avance pour votre aide.

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 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 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 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...

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