PhpWebGallery 1.4.0

Posté par (page perso) . Modéré par Florent Zara.
Tags :
0
17
mar.
2005
PHP
PhpWebGallery est une application web, écrite en PHP, sous licence GPL, permettant de créer facilement une galerie de photos en ligne. Après un an et demi de développement (et de repos), une nouvelle branche stable est enfin disponible.

Au menu des nouveautés, on trouvera notamment le support des métadonnées (EXIF, IPTC), une réécriture des templates, la gestion de tout type de fichiers. Les nouveautés ne se situent pas qu'en terme de fonctionnalités, mais aussi sur le projet en lui même : deux nouveaux membres à l'équipe, migration sur Gna!, outil de suivi de bogues, "development builds". PhpWebGallery n'est pas unique en son genre, puisque des projets comme The Gallery ou Coppermine remportent déjà un retentissant succès. PhpWebGallery est un projet français, d'ailleurs, la section française du forum est la plus active, incontestablement. Les points forts de PhpWebGallery sont la capacité de gérer efficacement des galeries à fort volume (nombreuses catégories imbriquées, nombreuses photos), la fonctionnalité "site distant" est assez unique en son genre :-), la possibilité d'associer une photo à plusieurs catégories est également originale.

PhpWebGallery utilise un backend MySQL. C'est un choix fait lors de la conception initiale de l'application, le but étant de pouvoir intégrer facilement des fonctionnalités du type recherche avancée (et rapide), gestion des permissions, commentaires utilisateurs, associer des photos à plusieurs catégories de manière logique, etc.

Liste plus complète des nouveautés en branche 1.4 :
- réécriture des templates HTML (meilleur respect des standards du web, mais perfectible)
- gestion de tout type de fichiers, plus seulement les images
- nouvelles catégories spéciales : images au hasard, nouvelles catégories, mieux notés, calendrier
- outil de recherche avancée (selon des plages de date, dans une sous-arborescence de catégories, etc)
- utilisation (et/ou affichage) des méta-données EXIF et IPTC
- nouveau frontend pour la gestion des sites distant
- image grand format optionnelle
- visualisation des catégories liées à l'élément (un élément peut appartenir à plusieurs catégories)
- gestion globale des options des catégories (commentables, autorisations d'ajout d'images, verrouillage, privée/publique)
- possibilité d'effectuer une simulation de synchronisation entre l'arborescence de fichiers et la base avant de la valider
- verrouillage globale de galerie
- gestion normalisée des mise à jour depuis les précédentes versions stables
- très nombreuses optimisations (suppression maximale de la récursivité lorsqu'inutile, utilisation de données calculées pertinentes)

Ceci ne constitue que les nouveautés, les fonctionnalités principales, sont :
- sous GPL
- import d'images automatique à partir du système de fichier (1 répertoire = 1 catégorie, simple et facile)
- import d'image par upload HTTP
- usage multiple (virtuel) des images (une image peut appartenir à plusieurs catégories)
- administration simple des images, commentaires, utilisateurs, groupes, catégories
- installation simple (détarer puis install.php)
- possibilité de générer les miniatures
- catégories automatiques : récentes et plus vues
- notification par mail
- diaporama (automatique)
- multilingue
- sites de stockage d'image distants
- différents modes d'accès (libre ou réservé aux membres)
- gabarits HTML

Evolution dans le projet :
- 1 développeur a rejoint l'équipe début 2004, doublant ainsi les effectifs :-) Gweltas s'occupe principalement de l'i18n et des templates
- 1 webmaster/développeur nous a rejoint fin 2004. Sephi prépare activement le nouveau gestionnaire de MODs (voir roadmap 2005)
- le projet a partiellement migré sur Gna! : CVS, mailing list, espace de téléchargement
- la mise à disposition des "builds" de développement a permis d'anticiper beaucoup de corrections de bugs avant les Release Candidate
- l'utilisation d'un véritable outil de suivi de bogues (Mantis) améliore la qualité globale de l'application
- migration du forum de IPB (la licence est devenue gênante) vers l'excellent punbb

Dans la roadmap 2005, on trouve en vrac :
- nouveau nom pour le projet : enfreint la licence de PHP, trop long, pas facile à retenir, voir le topic dédié sur le forum
- documentation wiki (articles de base déjà partiellement écrit)
- un véritable gestionnaire des MODs, template, languages...
- branche 1.5 : la fréquence des nouvelles branches doit s'accélérer sous peine de rendre le projet trop statique
- migration de CVS vers Subversion dès disponibilité sur Gna!

Aller plus loin

  • # Nom illégal ?

    Posté par (page perso) . Évalué à 1.

    Je croyais que l'utilisation du nom "PHP" dans une application faite en PHP était légale mais qu'un fork de PHP utilisant son nom serait illégal, j'ai faux ?
    • [^] # Re: Nom illégal ?

      Posté par . Évalué à 5.

      Q. I've written a project in PHP that I'm going to release as open source, and I'd like to call it PHPTransmogrifier. Is that OK?

      A. We cannot really stop you from using PHP in the name of your project unless you include any code from the PHP distribution, in which case you would be violating the license. But we would really prefer if people would come up with their own names independent of the PHP name.

      Why you ask? You are only trying to contribute to the PHP community. That may be true, but by using the PHP name you are explicitly linking your efforts to those of the entire PHP development community and the years of work that has gone into the PHP project. Every time a flaw is found in one of the thousands of applications out there that call themselves "PHP-Something" the negative karma that generates reflects unfairly on the entire PHP project. We had nothing to do with PHP-Nuke, for example, and every bugtraq posting on that says "PHP" in it. Your particular project may in fact be the greatest thing ever, but we have to be consistent in how we handle these requests and we honestly have no way of knowing whether your project is actually the greatest thing ever.

      So, please, pick a name that stands on its own merits. If your stuff is good, it will not take long to establish a reputation for yourselves. Look at Zope, for example, that is a framework for Python that doesn't have Python in the name. Smarty as well doesn't have PHP in the name and does quite well.


      En gros, c'est pas illegal, c'est deconseillé par PHP
  • # se passer du système de fichier

    Posté par . Évalué à 5.

    Mon problème avec Coppermine, The Gallery et PhpWebGallery c'est qu'ils stoquent tous les photo dans un système de fichier tandis que les metadonnées sont stockées dans une base de données. Ca pose plusieurs problèmes d'administration. Quelqu'un connait-il une gallerie qui stoque les photos et les metadonnées dans une base de données?
    • [^] # Re: se passer du système de fichier

      Posté par (page perso) . Évalué à 4.

      Je reponds pas vraiment à ta question, mais j'ai toujours entendu dire que stocker des fichiers binaires dans une DB était loin d'etre la panacée (espace disque, charge serveur ...).
      A part quelques cas très spécifiques, les données relationnelles vont en DB relationelle et les données binaires vont dans le fs ! C'est fait pour ca non ?
      Quand aux problèmes d'administrations, PhpWebGallery semble disposer de fonctionalitées de synchronisation entre la DB et le fs.
      • [^] # Re: se passer du système de fichier

        Posté par . Évalué à 4.

        Il y a un article très intéressant là dessus sur developpez.com :

        http://sql.developpez.com/stockerimages/(...)

        Certains disent que ça marchent très bien... d'autres que ça marche pas top....

        En gros, le problème est effectivement la synchronisation des données. DB2 ajoute un le type de données DATALINK qui permet d'allier le meilleur du système de fichier et de la base de données (intégrité référentielle, atomicité etc...)

        L'article et les commentaires sont très intéressants. De mon expérience, sous Oracle, c'est assez déconseillé car la manière d'accéder aux BLOB change entre les versions... j'ai eu quelques grosses surprises...

        Ce qu'il faudrait c'est que quelqu'un se tape à coder sous (My|Postrgre)SQL le type de données DATALINK... à moins qu'il y ait un brevet logiciel déposé dessus (ce qui ne serait pas étonnant de la part d'IBM)
    • [^] # Re: se passer du système de fichier

      Posté par . Évalué à 2.

      Je sais pas pourquoi certains te moinssent....

      Les gens ont le choix de cliquer sur "pertinent" ou "inutile"....

      On a ici un post d'une personne se posant la question : "Y'a des BLOBs dans les bases de données, pourquoi personne les utilise ?". Je trouve cette question pertinente... peut être pas exactement en rapport avec PHPWebGallery, mais en aucun cas "inutile"....
    • [^] # Re: se passer du système de fichier

      Posté par (page perso) . Évalué à 1.

      en général, on conseille justement de stocker les données dans une BD et les fichiers dans un FS qui est fait pour ça, c'est accédé + rapidement, et évite de mettre la base à genoux.
      Sinon tu à l'inverse, il existe des galleries qui stocke tout dans le FS, voir à se propos le package gallery dans Templeet. http://templeet.org(...)
      normalement, un package pour faire des planches contacts devrait arriver sous peu mais j'ai pas encore eu le temps :-)
      • [^] # Re: se passer du système de fichier... ou de la BD ?

        Posté par (page perso) . Évalué à 3.

        en général, on conseille justement de stocker les données dans une BD et les fichiers dans un FS qui est fait pour ça, c'est accédé + rapidement, et évite de mettre la base à genoux.

        Evidemment, je confirme que ce choix est très généralement admis comme étant le bon. Concernant PhpWebGallery, je n'ai pas hésité, ce choix n'en était pas vraiment un.

        Pour anecdote, lorsque le projet débutait, j'étais stagiaire dans une boîte d'édition de CMS (Content Management System) qui avait choisi de tout stocker en base, même les documents binaires (fichiers images, vidéos, documents PDF). J'avoue sincèrement que c'était à la fois complexe et particulièrement peu fiable.

        Eventuellement, le seul avantage que je vois concernant le stockage des images en base concerne la sécurité : difficile d'obliger l'application à vous montrer une image à laquelle vous n'avez pas accès normalement (sauf bug dans l'application...). Il est de toute façon très possible d'interdire l'accès à un répertoire web en navigation directe... l'argument devient donc difficile à défendre.

        il existe des galleries qui stocke tout dans le FS

        En effet et je trouve ça plus propre, notamment pour les sauvegardes. Malheureusement, ce choix conceptuel freine les possibilités d'abstraction logique offerte par la base de données. Je ne dis pas que certaines fonctionnalités deviennent impossible à coder, mais qu'elle seront bien plus difficiles à implémenter et risque de faire chuter les performances.

        A titre d'exemples, il est intéressant de pouvoir associer une image à plusieurs catégories sans dupliquer physiquement le fichier, de créer des catégories virtuelles logiques. Ce type de fonctionnalité est triviale avec une BD comme backend, lourd à implémenter avec uniquement un FS.

        NB : je conçois parfaitement que ce type de fonctionnalité puisse être considéré comme inutile par certains.
        • [^] # Re: se passer du système de fichier... ou de la BD ?

          Posté par . Évalué à 1.

          SQLite ?
          • [^] # Re: se passer du système de fichier... ou de la BD ?

            Posté par (page perso) . Évalué à 1.

            SQLite

            C'est plus ou moins une idée qui germe dans mon esprit : supporter un autre SGBD que MySQL. PostGreSQL par exemple, SQLite ensuite. Pour cela, il sera nécessaire de rajouter une couche d'abstraction entre l'application et la base de données. C'est un tavail conséquent que je ne suis pas prêt à entreprendre pour le moment.

            Sur le principe, SQLite me plaît évidemment, et il se pourrait bien qu'il soit plus rapide que MySQL pour une application du type galerie d'images.
        • [^] # Re: se passer du système de fichier... ou de la BD ?

          Posté par (page perso) . Évalué à 1.

          Pour associer une image à plusieurs catégories, on peut utiliser les liens symboliques ou physiques (sauf sous woinwoin).
        • [^] # Re: se passer du système de fichier... ou de la BD ?

          Posté par (page perso) . Évalué à 2.

          ouais, c'est vrai que pour le backup, mysqldump ça marche pas avec le fs.... mais un bon .tar.bz2 des familles, ça marche pas mal. (surtout si toute les photos sont dans la même sous-arborescence.)

          Je vois juste un avantage à mettre toutes les photos dans la BDD : certains hébergeurs mutualisés ne comptent pas la taille de la BDD dans le quota... plutot pratique avec de grosses bases.
          et toutes les infos dans le FS : pratique lorsqu'on a pas de BDD justement...
          • [^] # Re: se passer du système de fichier... ou de la BD ?

            Posté par (page perso) . Évalué à 1.

            Je vois juste un avantage à mettre toutes les photos dans la BDD : certains hébergeurs mutualisés ne comptent pas la taille de la BDD dans le quota... plutot pratique avec de grosses bases.

            Oui mais si tu es sur un hébergement mutualisé, tu as généralement des performances moins bonnes (en tout cas aux heures d'affluence) et mettre les images en base risque de bloquer complètement :-(
            • [^] # Re: se passer du système de fichier... ou de la BD ?

              Posté par (page perso) . Évalué à 2.

              oui, j'imagine assez. mais en même temps c'est une solution moins cher qu'un serveur entier. (d'ailleurs, du temps de daCode, les pièces-jointes aux dépêches était stocké dans la base de données... ).
              Enfin, je dis ça, il me semble que c'est ce que fait phpBB, cette usine à gaz (plus du GD à tire larigot, hein ?)...
  • # Pourquoi des templates ?

    Posté par (page perso) . Évalué à 0.

    J'apprécie énormément cet outil qu'est phpwebgalery mais je trouve vraiment dommage d'avoir utiliser phplib comme moteur de templates. Et d'ailleurs je trouve dommage d'en avoir utiliser un; mais là c'est plus une affaire personnelle.

    Comme le souligne l'auteur lui même le code html généré est perfectible. Le fouillis induit par phplib rend le "nettoyage" bien plus difficile. Il n'y a pas une bonne séparation du contenu et du contenant. Une partie du code html généré est déportée au niveau du moteur de templates et pas du template lui-même.
    • [^] # Re: Pourquoi des templates ?

      Posté par (page perso) . Évalué à 2.

      Jusqu'à la branche 1.2 incluse, le code HTML était confondu avec le code PHP. Pour les développements de la future branche 1.3, j'ai choisi d'utiliser un moteur de template. J'ai pesé le pour et le contre de l'utilisation de templates, c'est un débat récurrent parmi les développeurs web. Même Rasmus LERDORF (développeur à l'origine de PHP) a un avis tranché : l'utilisation de moteur de template est une hérésie car PHP est lui même déjà un moteur de template, et qu'il est inutile d'avoir à réapprendre un nouveau langage.

      Je ne partage pas complètement l'avis de l'auteur de PHP car seuls les moteurs de template permettent d'imposer la séparation de l'HTML et du PHP. Par contre, en effet, je trouve inutile d'avoir besoin de connaître un langage de programmation supplémentaire. C'est pour cela que le moteur de template doit selon moi rester simple (troll : éliminant ainsi Smarty, que j'utiliserai volontiers sur un projet perso). Seul, mon choix s'était porté sur VTemplate pour la branche 1.3. Malheureusement, ce moteur n'est plus maintenu et les messages d'erreurs sont difficiles à interpréter. Un nouveau membre a rejoint l'équipe (Gweltas) et a pris en main la gestion des templates. Son premier travail fut de passer à PHPLib.

      La séparation actuelle du HTML et du PHP est bien plus claire et rend l'application bien plus simple à maintenir tout en restant facile à faire évoluer. Il ne faut pas non plus oublier que l'un des premiers objectifs de cette séparation est de permettre à des non développeurs (des graphistes) de créer des templates sans avoir besoin de plonger dans le code PHP.

      Une partie du code html généré est déportée au niveau du moteur de templates et pas du template lui-même.

      ??? je ne comprend pas ce que tu veux dire. Si tu cites un exemple de code HTML généré par PHPLib qui n'est pas dans un template, je me ferai une meilleure idée.
      • [^] # Re: Pourquoi des templates ?

        Posté par (page perso) . Évalué à 0.

        Tout d'abord merci pour ta réponse.
        Je rejoins l'avis de Rasmus!

        > Je ne partage pas complètement l'avis de l'auteur de PHP car seuls les moteurs de template permettent d'imposer la séparation de l'HTML et du PHP.

        Pardon ? Tu as seulement l'impression de la séparer. De toute manière tu obliges php à parser tes templates donc je n'en vois pas l'intérêt.

        > Par contre, en effet, je trouve inutile d'avoir besoin de connaître un langage de programmation supplémentaire.

        C'est bien le principal aspect qui me gêne dans les templates. On donne l'illusion au graphiste qu'il peut agir sur le contenu de la page sans connaitre autre chose que le html!

        > ??? je ne comprend pas ce que tu veux dire. Si tu cites un exemple de code HTML généré par PHPLib qui n'est pas dans un template, je me ferai une meilleure idée.

        Je n'ai plus d'exemples précis sous la main mais j'ai été confronté au problème en voulant adapter un template.

        J'espère malgré que tu as pris mes remarques comme des critiques constructives. J'apprécie le travail fait. Je trouve la gestion des droits très bien faite.

        Bonne continuation.
  • # Mise à jour chez Free ?

    Posté par . Évalué à 1.

    PWB est la (une des ?) gallerie fournie par l'hébergement de Free. Savez-vous s'ils ont l'intention de mettre à jour PWB ?
    • [^] # Re: Mise à jour chez Free ?

      Posté par (page perso) . Évalué à 1.

      Je n'en ai pas la moindre idée. Il ne m'avaient d'ailleurs pas contacté pour mettre à disposition PhpWebGallery (PWG) pour leurs abonnés. Cela ne m'avait pas spécialement gêné (contrairement à d'autres auteurs d'applications, voir la controverse concernant l'excellent DotClear : http://www.neokraft.net/blog/2004/12/03/559-la-liberte-ca-a-un-prix(...) )

      S'ils me contactent, je leur donnerai les billes pour faire ça proprement et sans perte d'informations stockées en base.

      Pour ceux qui n'utilisent pas l'installation automatique chez free.fr, sachez que les scripts d'upgrade depuis toutes les versions de la branche 1.3 sont inclus dans l'archive. La lecture du README, section "mise à jour" vous guidera.

Suivre le flux des commentaires

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