Journal Galerie photo en php, simple, facile et encore plus complète

Posté par  .
Étiquettes : aucune
4
18
déc.
2010
Ce journal fait suite au journal http://linuxfr.org/~cosmocat/30457.html qui présentait la première version de la galerie que je développe.

Comme certains paraissaient intéressés (et ont fait quelques demandes d'évolution), je me fends d'une petite suite...

Pour rappel, quelles sont les particularités de cette galerie :
- pas de base de données
- gestion des données exif ET iptc
- géolocalisation des images et galeries sur une carte google map
- panorama d'une galerie

Sur le dépot github ( https://github.com/pmiossec/Facile-Gallery ) est donc disponible une nouvelle version apportant les fonctionnalités suivantes :
- style configurable facilement (donc maintenant, si c'est moche, c'est plus de ma faute...)
- gestion des sous-répertoires (ou sous galeries)
- possibilité de faire plusieurs galeries privées accessibles par login/mot de passe (le lien vers les galeries privées est en haut à droite dans la page principale)
- possibilité de permettre aux visiteurs de laisser des commentaires sur les photos (en utilisant disqus --car les commentaires c'est pas si important que çà :) et qu'il peuvent être exportés de disqus --).

J'ai bien eu une demande pour améliorer la navigation par les vignettes précédente/suivante sur les notebooks (pour que ça prenne moins de place en largeur à l'écran) et bien qu'ayant essayé, je n'ai pas trouvé de solution satisfaisante. Donc, si un expert css a un peu de temps, il peut bien essayer de me contacter pour trouver une solution. Je pressens que ce n'est pas si compliqué à faire.

Pour la demande de la génération d'un fichier zip d'album pour téléchargement, c'est pas gagné non plus car sur les serveurs php de free, y'a pas d'api convenable d'installée :(

Donc, j'espère un petit peu noël avant l'heure quand même... ( http://linuxfr.org/comments/1183048.html#1183048 )

  • # génération ZIP à la volée

    Posté par  . Évalué à 5.

    Pas besoin d'une api pour générer des zip à mon avis, vu qu'il s'agit d'images il y aura pas de compression donc le plus simple est de créer une "coquille" zip qui intègre les fichiers tels quels => t'as juste à générer un header zip qui va bien et balancer les fichiers ensuite. J'avais fait ça il y a quelques années pour un besoin très similaire et ça avait l'air de marcher :) Si tu veux le code, je dois pouvoir le retrouver qq part...

    • [^] # Re: génération ZIP à la volée

      Posté par  (site web personnel) . Évalué à 1.

      Ou alors utilisé PclZip : http://www.phpconcept.net/pclzip/

      Born to Kill EndUser !

    • [^] # Re: génération ZIP à la volée

      Posté par  . Évalué à 3.

      Autant faire du tar. C'est fait pour.

      Même les logiciels pas libre (et donc kipu) savent ouvrir des .tar depuis des années.



      Sinon, j'ai renoncé à faire ça sur mes galeries.

      J'ai tenté le zip ou le tar par album, mais ça prend trop de place à partir d'une certaine quantité d'albums (en gros, ça fait du x2, plus lorsque l'on multiplie les albums et les sous albums). Et puis c'est chiant à scripter et à maintenir.

      J'ai aussi tenté la création du .zip ou du .tar à la demande. D'abord de manière interactive : clic sur télécharger, message « génération du fichier en cours » attendre, attendre, attendre, timeout. Quand il y a trop d'images, ça consomme énormément de ressources et ça n'aboutit pas forcément avant le timeout.

      Du coup j'ai fait ça en mode batch. Après le clic, un message « votre demande a été prise en compte, vous recevrez un lien de téléchargement par mail ». Mais encore ça pose des problèmes. C'est pas noob-proof (le noob une fois qu'il a fermé son navigateur, il est passé à autre chose, ça le perturbe de devoir attendre pour avoir quelque chose. Si ce n'est pas interactif, il ne se passe plus rien. Internet s'éteint avec le navigateur).

      Et puis la création de tarballs (surtout en mode batch) à la demande a le désavantage de nécessiter une gestion du cache : Combien de temps on conserve le fichier ? Vaut-il mieux perdre un peu d'espace disque plus longtemps ou bien prendre le risque de tout recalculer rapidement ? C'est déjà à moitié une usine à gaz et je n'ai pas encore commencé à évoquer la possibilité d'analyser les logs dynamiquement pour voir ce qui est téléchargé le plus souvent, tenter de les recréer le moins souvent, voir même anticiper le prochain téléchargement.


      Du coup j'ai laissé tomber tout ça. Et plutôt que de réinventer la roue, je me suis dit que j'allais me reposer sur les technologies existantes et éprouvées : le (s)ftp. Un compte ftp anonyme, des instructions et ça roule.

      Pour les galeries privées, un compte sftp chrooté dans le répertoire des photos avec un accès en lecture uniquement et ça suffit largement. Avec des instructions sur la manière de faire avec filezilla classique (dommage qu'il y ait beaucoup d'anglais, c'est rebutant pour beaucoup de monde. Mais une fois l'étape d'installation passée, l'utilisation ne pose généralement pas de problème).

      En plus, ça a le double avantage de permettre aux membres d'uploader leurs photos dans un dossier en DMZ afin de pouvoir l'ajouter à la galerie à postériori. Plutôt que d'être confronté aux mêmes problèmes de timeout lors d'upload de trop gros fichiers (zip ou vidéo) ou bien de se farcir plusieurs centaines de photos à la main une par une.


      My 2c.

      • [^] # Re: génération ZIP à la volée

        Posté par  . Évalué à 1.

        Effectivement tar c'est fait pour ça aussi mais Mme Michu si elle a pas son p'tit neuveu qui lui a installé winzip/winrar/powermachin, son Windows de base ne reconnait que les zip (et encore, de manière merdique mais ça c'est une autre histoire :). Bon, ça a peut-être changé avec Windows Vista/Seven!

        Sinon, pas besoin de générer des fichiers/de les maintenir et tout le bordel qui va avec effectivement. Vu qu'on parle de fichier sans compression (images/videos) il suffit de les envoyer directement les uns à la suite des autres dans la réponse HTTP qd le p'tit gars clique sur 'télécharger' (avec le header zip/tar/<ce que tu veux> avant. Avantages:
        - Pas de place perdue par les archives
        - Pas de CPU perdu pour compresser des fichiers qui vont sortir avec 1% de compression max
        - Possibilité de choisir un direct "fais moi un zip avec ce fichier là, celui là, et encore celui-là"

        • [^] # Re: génération ZIP à la volée

          Posté par  (site web personnel) . Évalué à 1.

          Justement, chez free, ils limitent (en tout cas ils limitaient, maintenant je n'en sait rien), les quantités de données autorisées à transiter directement par le flux http.
          Pour le point 2, n'est-il pas possible de ne pas compresser mais d'ajouter les en-têtes zip, pour que ce soit simple pour un utilisateur néophyte mais pas gourmand en ressources?
          Pour le point 3, même en créant un zip/tar à la volée, tu peux le faire dynamiquement.

          Ceci n'est pas une signature

        • [^] # Re: génération ZIP à la volée

          Posté par  . Évalué à 2.

          Vu qu'on parle de fichier sans compression (images/videos) il suffit de les envoyer directement les uns à la suite des autres dans la réponse HTTP Comment faire ça en pratique ?

      • [^] # Re: génération ZIP à la volée

        Posté par  (site web personnel) . Évalué à 1.

        Pour le plugin Download Multi pour Piwigo j'ai utilisé au début pclzip mais pour simplifier le code je suis passé à la lib de php 5. Le principe reste le même, je définis un paramètre qui donne la taille max des fichiers que je peux mettre par archive et je génère les archives en fonction et à la demande. Ça marche pas trop mal, je l'utilise au boulot depuis 2 ans et sur Piwigo il y en a d'autres qui ont l'air content du plugin.

        Pour contourner le timeout j'utilise le buffer (j'ai plus la fonction php sous la main), c'est pas propre mais ça marche. Le mieux serait de la faire avec une couche d'ajax mais trop la flemme de me plonger dans ce truc ignoble.

        Philippe.

        Born to Kill EndUser !

    • [^] # Re: génération ZIP à la volée

      Posté par  . Évalué à 2.

      effectivement, je suis intéressé...

  • # Un petit reproche

    Posté par  . Évalué à 2.

    Enfin je n'ai pas encore testé hein ... Donc il y en a peut-être d'autres à faire mais les commentaires stockés sur un autre site internet, je n'aime pas du tout !
    C'est quand même dommage d'avoir un outil si simple pour créer ses propres galeries et se libérer de Picassa & co mais rester dépendant d'un autre service pour les commentaires ...
    Cela dit je comprend que le stockage des commentaires nécessiterait une base et donc nuirait à la simplicité du truc.

    Pour le reste c'est exactement ce que je cherchais, une galerie simple qui ne nécessite pas de passer par une interface web et/ou une base de donnée pour uploader ses photos.
    Merci

    • [^] # Re: Un petit reproche

      Posté par  . Évalué à 1.

      Pourquoi le stockage de commentaires nécessiterait-t-il une base de données ? Les fichiers textes n'ont pas la capacité de stocker des commentaires ?.

      • [^] # Re: Un petit reproche

        Posté par  . Évalué à 1.

        Oui mais même un fichier texte est une base de données ... Et il faudrait coder un simili-SGBD pour les manipuler. Après si le but est d'éviter à l'utilisateur d'installer un véritable SGBD sur son serveur, oui ça pourrait faire l'affaire.

        • [^] # Re: Un petit reproche

          Posté par  . Évalué à 2.

          Ça pourrait être fait avec SQLite ou du XML mais il ne faudra pas trop de commentaires alors.

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: Un petit reproche

        Posté par  . Évalué à 2.

        En fait, moi, les commentaires, je m'en fiche un peu pour une galerie. J'ai donc implémenté cette fonctionnalité via disqus car ça peut faire plaisir à quelqu'un et surtout parce que ça m'a demandé que très peu de temps 10min pour l'ajout et 2 ou 3h pour fignoler les paramètres, la doc, coder un css pour disqus sur fond noir,... (et seulement 10 lignes de code)

        Mais si quelqu'un veut faire quelque chose de mieux, je suis ouvert à l'intégration...

    • [^] # Re: Un petit reproche

      Posté par  . Évalué à 0.

      Du coup il sert a quoi le php dans l'histoire.
      Pourquoi ne pas utiliser un générateur de gallerie telque lazygal & co ?

      • [^] # Re: Un petit reproche

        Posté par  . Évalué à 1.

        Il sert (je suppose, et si j'ai bien compris le fonctionnement de lazygal que je ne connaissais pas) à ne pas avoir à re-générer sa galerie chaque fois qu'on rajoute une photo.
        On dépose ses images dans un dossier et c'est tout.

        • [^] # Re: Un petit reproche

          Posté par  . Évalué à 0.

          Mais mais l'intérêt reste assez limité : si on utilise le même pc, il suffit d'ajouter les photos en local et un script se charge de faire le reste (régénérer la gallerie pour les photos manquantes et upload par ftp des nouveaux fichiers).

          • [^] # Re: Un petit reproche

            Posté par  . Évalué à 1.

            Surtout vu le temps que ça prend pour générer les miniatures et disqus qui ne fonctionne pas dans les galeries privées ... Je ne vais pas tarder à être d'accord avec toi.
            Ça manque cruellement d'une gestion interne des commentaires.
            Plus quelques petites remarques :

            - de nombreux warning lorsqu'on affiche les erreurs (notamment la fonction eregi qui est obsolète sous PHP 5.3 et peut-être remplacée par preg_match)

            - l'encodage Windows 1252 ?!

            -il faut avoir visité un dossier pour que la miniature s'affiche + 120 secondes de max_execution_time c'est très juste pour un dossier de photos de voyage par exemple ...

            Un script vraiment très intéressant mais qui mérite quelques améliorations. À partir de mercredi j'essaierai de me pencher dessus.

            • [^] # Re: Un petit reproche

              Posté par  . Évalué à 2.

              l'encodage Windows 1252 ?!
              Tu fais bien de me le rappeler. Je m'étais dis qu'il fallait que je le corrige mais je l'ai pas mis dans ma todo list et j'ai oublié. C'est du au fait que :
              1. c'était comme ça dans le script d'origine (c'est la meilleure excuse :) )
              2. si on choisi un autre encodage, l'affichage de certaines données IPTC pose problème du fait de leur encodage. Il doit falloir les convertir mais je me suis pas penché sur le sujet...

              de nombreux warning lorsqu'on affiche les erreurs (notamment la fonction eregi qui est obsolète sous PHP 5.3 et peut-être remplacée par preg_match)
              je connais pas beaucoup php (et cf point 1. ci dessus) mais je regarderais.

              il faut avoir visité un dossier pour que la miniature s'affiche + 120 secondes de max_execution_time c'est très juste pour un dossier de photos de voyage par exemple ...
              tiens, ça me donne une idée. Mettre un max_execution_time en fonction du nombre de photos du dossier. Je vais regarder çà. Merci!

              Pour les commentaires, voir ma réponse au dessus...

              • [^] # Re: Un petit reproche

                Posté par  . Évalué à 1.

                Pour la conversion de l'encodage, je te recommande de passer par la fonction mb_convert_encoding (http://fr2.php.net/manual/fr/function.mb-convert-encoding.ph(...) ).

                Je l'utilise sans problème dans un contexte similaire au tien : conversion en UTF-8 de métadonnées IPTC pour insertion en BDD.

                • [^] # Re: Un petit reproche

                  Posté par  . Évalué à 2.

                  en fait, j'ai déjà fait la correction de l'encodage ce soir mais en utilisant utf8_encode(). Ta fonction est-elle mieux?

                  • [^] # Re: Un petit reproche

                    Posté par  . Évalué à 1.

                    man utf8_encode
                    ;)
                    De façon plus constructive, utf8_encode() convertit une chaîne ISO-8859-1 en UTF-8 (http://fr2.php.net/manual/fr/function.utf8-encode.php ), alors que mb_convert_encoding() convertit une chaîne d'un encodage vers un autre.

                    Je n'ai plus le contexte en tête, mais j'ai dû tester sans succès utf8_encode() sur des chaînes à convertir depuis d'autres jeux de caractères qu'ISO-8859-1 : avec un nom pareil, utf8_encode() est sûrement la première fonction que j'ai essayée !

  • # Merci papa noël

    Posté par  . Évalué à 1.

    C'est pas très constructif, mais tant pis : Merci beaucoup !

  • # Pour la generation d'un fichier zip

    Posté par  (site web personnel) . Évalué à 1.

    Hello,
    J'ai moi même, à l'époque de la naissance de ma p'tiot, décidé de me faire un site de photos perso.
    A ce moment j'avais également voulu créer automatiquement un fichier zip et j'avais trouvé ce lien pour faire ca en PHP:
    [http://www.phpfrance.com/tutoriaux/index.php/2005/12/29/36-c(...)]

    J'étais également chez free et le problème, c'est qu'il n'était alors pas possible de générer un flux http dépassant une certaine taille.
    Donc, j'avait opté pour la solution d'un fichier temporaire à télécharger (cf. commentaire 18 et 22 dans le liens plus haut) et modifié en conséquence le code dans la version qui se trouve ici:
    [http://www.box.net/public/egsv16tinq]

    bref, le système de création de photo de mon site est très pourri (en fait j'ai laissé tomber le projet), mais le script php pourrait, qui sait, t'être utile.
    A noter que je ne suis pas l'auteur du script initial, seulement je l'ai patché, donc si tu l'inclus dans ton projet, il faudrait sans doute voir avec l'auteur principal (son adresse est en en-tête du script).
    voila voila...
    a++

    Ceci n'est pas une signature

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.