Piwigo 2.7 : un chez-soi pour vos photos

Posté par (page perso) . Édité par BAud, Benoît Sibaud et palm123. Modéré par Benoît Sibaud. Licence CC by-sa
Tags :
41
4
oct.
2014
Graphisme/photo

Piwigo est un logiciel libre de galeries photos pour le web. La version 2.7 est sortie il y a quelques jours. Parmi les nouveautés, un nouvel uploader (téléverseur (?) en HTML5, qui remplace l'ancien en flash), une visite guidée interactive pour les débutants, un champ recherche amélioré et tout un tas de petites améliorations.

Logo Piwigo

Pour éviter de répéter ici ce que l'annonce de la sortie de la version 2.7 dit déjà mieux que moi, voici une dépêche d'un point de vue subjectif assumé : j'ai moi-même franchi le pas, il y a quelques semaines, après avoir comparé Piwigo et d'autres. Voici ce que je retiens de mes premières expériences avec Piwigo et des nouveautés de la nouvelle version.

Sommaire

Un logiciel communautaire et un hébergement commercial

Avant de rentrer dans les détails techniques, Piwigo un logiciel libre, gratuit et facilement auto-hébergeable (écrit en PHP). En parallèle avec l'association Piwigo, une entité commerciale Pigolabs propose un hébergement (piwigo.com) et des services autour du logiciel Piwigo.

La communauté et l'entité commerciale sont toutes les deux dans l'esprit du logiciel libre (liberté du logiciel, mais aussi conserver le contrôle de l'utilisateur sur ses données).

Si on opte pour le service d'hébergement piwigo.com, il est payant, mais sans pub et sans revente d'informations personnelles à des tiers. Clairement pas dans la même catégorie que les géants américains du domaine…

Piwigo : l'outil de galeries photos paramétrable à souhait

Ce qui distingue Piwigo d'autres solutions libres d'hébergement de photos, c'est sans doute le degré de personnalisation de l'outil.

On est à l'opposé de la philosophie des solutions de partages de photos orientés « réseaux sociaux » comme Flickr ou Google+ : en visitant deux galeries Piwigo différentes, on n'a pas du tout l'impression de voir la même chose (alors que par construction, un album Google+ ressemble à tous les autres).

Thèmes et greffons

Comme pas mal d'autres outils, Piwigo a un système de thèmes qui permet de changer l'apparence de l'ensemble de la galerie en quelque clics. 53 thèmes disponibles en version 2.6, pas encore tous portés pour la 2.7 : c'est largement assez pour faire en sorte que votre galerie photos ne ressemble pas aux autres.

Le système de greffon permet à la fois d'ajouter des fonctionnalités (comme permettre aux visiteurs d'ajouter des photos, de télécharger tout un album en une fois ou de faire leurs propres sélections de photos), mais aussi de modifier l'apparence de certaines parties de la galerie. Par exemple, je trouve l'affichage des miniatures de la plupart des thèmes assez old school, mais avec un greffon comme gThumb+ ou gdThumb, on arrive à une apparence beaucoup plus « moderne ».

Cette diversité a un prix : une fois un thème choisi, le fait qu'il en existe 52 autres n'est plus si important. Par contre, certaines fonctionnalités sont développées spécifiquement pour un thème et on se trouve parfois contraint de faire un choix sur l'apparence de la galerie pour bénéficier d'une fonctionnalité. Par exemple, le thème Modus propose une fonctionnalité similaire à celle du greffon gThumb, mais supérieure en certains points. Si vous voulez cet fonctionnalité, vous devrez vous faire à l'apparence générale de Modus.

Le fait qu'on ait une cinquantaine de thèmes et une centaine de greffons implique aussi que les couples (thème, greffons) ne peuvent pas tous être testés (50 * 100 = 5000 combinaisons…) et, sans grande surprise, il y a beaucoup de bugs liés à la compatibilité d'un thème avec un greffon. En deux mois d'utilisation, j'ai rapporté 11 bugs ; 6 sont des problèmes de compatibilité thème/greffon.

LocalFiles editor : retoucher la CSS du site

Quand un thème s'approche du résultat souhaité sans l'atteindre, il est assez facile d'ajouter quelques règles CSS pour retoucher la mise en forme.

Le greffon LocalFiles editor permet de faire ça en ligne, à travers l'interface web. On peut donc faire ces modifications même sans avoir d'accès type ftp pour éditer les fichiers sur le serveur et, bien sûr, on édite un fichier CSS séparé du reste de l'outil, qui sera conservé lors des mises à jour. En particulier, ce greffon est disponible sur l'hébergement piwigo.com. Je ne connais pas d'autre hébergeur qui propose ce genre de configuration.

Avec les greffons appropriés (PWG Stuffs, Add < head > element), on peut injecter des morceaux de HTML ou de JavaScript un peu partout dans les pages, toujours sans toucher au code de Piwigo bien sûr.

Les templates

Je n'ai pas testé, mais le moteur de génération de HTML de Piwigo est basé sur un système de templates, et l'utilisateur peut remplacer tout ou partie des templates fournis par les siens. Cette possibilité n'est pas offerte sur piwigo.com par contre.

Avec tout ça, Piwigo commence à ressembler à un gestionnaire de contenus comme SPIP ou Wordpress : le logiciel s'occupe de la base de données qu'il y a derrière et donne le cadre. Le webmestre peut en faire ce qu'il veut.

Des exemples !

Juste pour vous donner une idée du genre de choses qu'on peut faire, voici quelques exemples de galeries (style dépouillé ou chargé !) :

Exemple 1

Exemple 2

Exemple 3

D'autres sont disponibles dans l'annuaire.

Bien sûr, un inconvénient du système de thèmes est aussi qu'il faut décider lequel est le plus beau, et comme chacun sait, des goûts et des couleurs, on ne discute pas ;-).

API de programmation externe

Piwigo propose aussi une API accessible à distance (pour plus de détails). C'est ce qui permet un écosystème assez riche en dehors de Piwigo, comme le client lourd pLoader ou le greffon KIPI qui permet d'uploader des images depuis Digikam, Gwenview, Kphotoalbum ou KSquirrel.

Autre exemple : intégrer une image aléatoire dans une page d'un autre site web se fait en quelques lignes de PHP.

Et les nouveautés de la 2.7 ?

La grande nouveauté technique de la 2.7, c'est le nouvel uploader. En 2.6, on avait le choix entre un upload HTML traditionnel, qui ne marche que pour un fichier à la fois, ou un uploader en flash, qui permettait de sélectionner plusieurs fichiers d'un coup (en plus, bien sûr de la possibilité d'envoyer les photos via ftp ou autre, sans passer par l'interface web). Piwigo a maintenant une solution basée sur HTML5, à la fois plus pratique que l'ancien (on peut envoyer les photos par glisser-déposer) et sans utiliser Flash.

Uploader HTML5

Une autre nouveauté (qui arrive un peu tard pour moi ;-) ), c'est le greffon « take a tour », qui propose une visite guidée de l'interface pour les débutants. C'est assez bien fait, c'est vraiment un bon point de départ pour faire le tour des fonctionnalités de l'outil.

Greffon Take a Tour

Le champ « recherche » a aussi été largement amélioré et il y a tout un tas de petites améliorations sur l'ergonomie générale : un lien direct « vider le panier » (je l'ai cherché en vain dans la 2.6, mais le voilà !), plus de filtres pour la gestion par lots, un champ recherche pour filtrer la liste des greffons… et beaucoup d'améliorations dans l'architecture interne et l'API pour les greffons.

Pour les détails, les notes de versions de Piwigo 2.7 vous raconteront tout ça en détails et en images !

Alors, Piwigo ou un autre ?

Au final, la flexibilité de Piwigo compense assez bien les défauts que je lui trouve. Esthétiquement, je n'ai pas trouvé de thème Piwigo que je trouve aussi joli que le rendu d'outils comme Lychee ou qui occupe aussi bien l'espace de l'écran que celui de PhotoShow. Mais dans les deux cas, ce sont des outils conçus pour un besoin en particulier (en général développés par une seule personne) et c'est difficile de leur faire faire autre chose que ce pour quoi ils ont été conçus. Bref, si ces outils vous conviennent, ils seront peut-être meilleurs que Piwigo pour votre utilisation et plus dans la philosophie « let one tool do one thing, and do it well », mais si vous cherchez la flexibilité alors Piwigo est probablement un meilleur candidat.

Dans la catégorie « outil libre, flexible, avec une communauté active », il n'y a pas beaucoup d'alternatives. Gallery 3 qui était une référence à une époque est abandonné par ses développeurs. Il reste Zenphoto, assez proche de Piwigo sur beaucoup de points mais pas forcément aussi complet. On peut aussi citer OwnCloud, qui propose un outil de galeries photos simple mais efficace.

  • # Thèmes

    Posté par . Évalué à 4.

    Au final, la flexibilité de Piwigo compense assez bien les défauts que je lui trouve. Esthétiquement, je n'ai pas trouvé de thème Piwigo que je trouve aussi joli que le rendu d'outils comme Lychee ou qui occupe aussi bien l'espace de l'écran que celui de PhotoShow.

    T'as essayé le thème Stripped&column : http://piwigo.org/ext/extension_view.php?eid=568

    • [^] # Re: Thèmes

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

      Oui. Il y a des choses que j'aime vraiment bien dans ce thème, mais je n'ai pas réussi à le faire marcher avec le plugin Automatic Size. La fonctionnalité numéro 1 pour moi, c'est d'utiliser tout l'espace disponible pour afficher la photo par défaut, et la majorité des thèmes est très mauvaise sur ce point.

      Sinon, je ne suis pas fan du texte en rouge par défaut, mais ça, c'est configurable.

      • [^] # Re: Thèmes

        Posté par . Évalué à 2.

        Stripped (white) avec Gthumb+ fait bien le boulot aussi ! L'espace est vraiment optimisé :
        http://piwigo.com/blog/2012/01/23/new-plugin-gthumb/

        • [^] # Re: Thèmes

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

          Sur un petit écran, je veux bien croire. Mais le mieux que j'arrive à obtenir même avec gThumb+, c'est un <div> de 1120 pixels de large. C'est moins de la moitié de la largeur de mon écran.

          Et pour l'affichage de la photo elle-même, gThumb ne change rien, les photos sont toutes petites (avec une lightbox pour agrandir, mais pourquoi ajouter une étape ?).

          • [^] # Re: Thèmes

            Posté par . Évalué à 2.

            Est-ce que ce n'est pas lié à la configuration de Piwigo ?
            Piwigo utilise différentes tailles fixes (XXS -> XXL) dont les dimensions sont configurables dans Configuration > Options > Tailles de photo.
            Ensuite, suivant la mise en page, Piwigo choisira la taille juste en dessous.

            Mais bon, malgré tout, bien souvent, c'est le thème qui limite. J'en suis arrivé à la conclusion que le mieux est de modifier un thème pour en faire ce que l'on souhaite…

  • # Il y a aussi

    Posté par . Évalué à 3.

    Il y a aussi sfpg qui est très simple à installer (nginx ou apache +php, sans sql) et a un rendu qui ressemble à Lychee. La question que je me pose est de savoir outre le rendu si il y a une différence de performance entre ces différentes solutions ou si c'est le débit ascendant qui est le goulet d'étranglement. Par exemple, il y a la possibilité que le script upload la photo suivante en cache avant que ce ne soit demandé par l'utilisateur, ce qui augmente la vitesse ressentie par le-dit utilisateur. Sfpg le fait, je ne sais pas si c'est le cas des autres.

    • [^] # Re: Il y a aussi

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

      Le préchargement avec Piwigo, certains thèmes le font, mais pas tous.

      (et on tombe pile sur un des reproches que je fais au système de thèmes : on devrait choisir un thème pour son apparence, pas pour des fonctionnalités « sous le capot » comme le préchargement)

    • [^] # Re: Il y a aussi

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

      J'utilise depuis pas mal de temps Koken. Il n'y a pas les mêmes fonctionnalités et la politique est pas tout à fait la même mais l'interface admin ou utilisateur est moderne et responsive.

      Born to Kill EndUser !

      • [^] # Re: Il y a aussi

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

        Bonjour Philippe M,

        […] Koken […]

        Koken est sans doute très joli, mais n'est absolument pas libre/opensource http://koken.me/eula.html donc sur un site comme Linuxfr qui fait la promotion des logiciels libres, c'est un peu "hors sujet" à mon avis. Mais oui sur le fond, les gens utilisent Piwigo et Koken pour la même chose : créer leur site photo (à ce titre ils sont tout à fait comparable). Je trouve cela dommage que simplement parce que le package de base de Koken est gratuit, on le compare à Piwigo de cette façon. Piwigo fait énormément plus de choses que Koken et tout est libre et gratuit. C'est un tout autre gage de pérennité. Ceci étant dit, je comprends très bien le choix de Koken en terme de modèle économique, il faut simplement souligner les contraintes pour les utilisateurs :-)

        […] interface admin ou utilisateur est moderne et responsive

        L'interface admin de Piwigo n'est pas obsolete vieille pour autant :-) On a également en discussion de passer l'interface admin sur Bootstrap (ou autre équivalent) pour notamment l'aspect responsive/mobile, voir http://piwigo.org/forum/viewtopic.php?id=24256

        • [^] # Re: Il y a aussi

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

          Koken n'est effectivement pas libre mais distribué gratuitement et si besoin en échange d'argent il est possible de faire appel au support.

          J'ai longtemps été utilisateur de Piwigo, depuis l'époque PhpWebGallery même. Vous avez réalisé un énorme travail pour maintenir et faire évoluer Piwigo vers la modernité. Lorsque je suis passé à Koken c'était principalement parce que je voulais quelque chose d'extrêmement simple à faire fonctionner au quotidien (je parle pas de l'installation qui est aussi simple d'un côté comme de l'autre). Dans Koken je créé un Set, je le définie comme privé ou public et j'ajoute les photos par un glissé/déposé et voila c'est tout. Certes avec la dernière version de Piwigo et le nouvel uploader c'est faisable il est même possible que maintenant cela soit aussi simple avec Piwigo que je n'ai pas retesté depuis la version 2.5 de mémoire.

          Il est clair que cette simplicité que je recherche se fait au détriment des fonctionnalités. Koken est mono-utilisateur donc pas de groupes utilisateurs, pas de commentaires en natif, pas de formulaire de contact, pas de sites distants, peu de plugins, peu de thèmes, pas d'upload possible depuis digikam, une communauté réduite et deux ou trois dev à la tête du projet et je pense à terme une évolution vers deux versions : Community et Enterprise et bien sûr ça sera cette dernière qui sera privilégié.

          Je suis conscient que la situation n'est pas top mais pour le moment à défaut d'avoir trouvé/pris le temps de tester une autre solution, je trouve Koken assez bien foutu.

          Born to Kill EndUser !

          • [^] # Re: Il y a aussi

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

            Dans Koken je créé un Set, je le définie comme privé ou public et j'ajoute les photos par un glissé/déposé et voila c'est tout. Certes avec la dernière version de Piwigo et le nouvel uploader c'est faisable […]

            Avec Piwigo + le plugin "Admin tools", tu peux par exemple aller à l'endroit où tu veux ajouter des photos dans l'interface publique, puis un clic sur "ajouter des photos" dans la barre de menu ajoutée par admin tools, et tu te retrouves sur la page de l'uploader. Là, tu peux créer un nouvel album ou ajouter les photos dans l'album existant (cf. le screenshot de la dépêche).

            Sur la page d'ajout des photos, piwigo te propose de choisir le niveau de confidentialité des photos. Avec ce système, la gestion des droits est faite par photo, avec un système assez primitif (famille, amis, contacts, autres) mais suffisant pour 90% des utilisations et très simple à utiliser. Si tu veux le système plus avancé (permissions par utilisateur, par groupe), il faut passer par les permissions de l'album, c'est quelques clics de plus.

            Et oui, maintenant c'est juste un glisser-déposer pour envoyer les photos ;-).

            Il y a parfois un peu plus de clics que nécessaire pour faire des choses simples, mais c'est quand même très raisonnable.

            • [^] # Re: Il y a aussi

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

              Merci pour cette précision mais comme j'ai pu le lire dans un commentaire précédent à propos d'une autre fonction, il faut passer par un plugin.

              Born to Kill EndUser !

              • [^] # Re: Il y a aussi

                Posté par . Évalué à 5.

                J'avoue que pour le coup, les commentaires donnent l'impression qu'une bonne partie des griefs sont résolus par ce plugin, y a t'il une volonté d'ajouter les fonctionnalités d'Admin Tool sur le tronc commun (pour les rendre plus accessibles (il faut savoir qu'il existe ce plugin), pour avoir un meilleur support (les fonctions seront jamais cassées) et peut être bénéficier d'une meilleure intégration dans les différents thèmes ?

                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                • [^] # Re: Il y a aussi

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

                  Je ne répondrais pas à la place de Pierrick (ou l'équipe piwigo) pour ce qui est de l'intégration des fonctionnalités d'Admin Tool dans le tronc commun. Mais en revanche une chose est sûre : ce plugin a un statut un peu particulier. En effet, il est sur le même dépôt que le pot commun et est livré en même temps que la distribution. Il n'est juste pas activé par défaut.

                • [^] # Re: Il y a aussi

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

                  y a t'il une volonté d'ajouter les fonctionnalités d'Admin Tool sur le tronc commun

                  Une volonté de ma part, oui ;-). Mais je ne fais pas partie de l'équipe.

                  J'ai évoqué l'idée au détour d'autres conversations, pour l'instant la réponse est « A discuter. ». Ça fait partie de mes projets de lancer une discussion plus précise et de tenter un patch.

  • # Ça tombe bien, j'allais l'installer

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

    Je suis actuellement l'heureux propriétaire d'une installation de Gallery Menalto (en v.2, la v.3 n'était pas encore stable quand je l'ai installée), et j'aimerais la mettre à jour.

    J'ai l'impression que ce type de site (galeries photo perso) est complètement tombé en désuétude, comme les forums : on ne trouve que des projets assez vieux (12 ans pour Piwigo, par exemple), la plupart sont même morts (Piwigo a l'air d'être un des derniers survivants), et je n'ai rien trouvé avec des solutions plus modernes (Django ou RoR, par exemple), ou des projets qui ne sont pas aussi aboutis.

    Bon, ok, il y a là-dedans un peu de racisme envers PHP (j'aimerais bien me débarrasser du PHP sur mon serveur), et accessoirement on a le choix entre MySQL et MySQL pour la BDD (j'aimerais bien n'avoir qu'un PostgreSQL ; les frameworks type RoR ou Django permettent de choisir facilement sa bdd).
    Concrètement, je n'ai pas grand-chose à reprocher à Piwigo, à part le couplage à MySQL et l'absence de thèmes en Bootstrap 3 (j'aimerais coupler ma galerie photo à un site et un forum en Bootstrap 3, et ça facilite bien les choses), du coup, je pense que je vais vraiment partir sur du Piwigo.

    • [^] # Re: Ça tombe bien, j'allais l'installer

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

      Bonjour flan,

      Je suis le fondateur de Piwigo et j'ai lu avec beaucoup d'intérêt ton commentaire :-) voyons voir :

      J'ai l'impression que ce type de site (galeries photo perso) est
      complètement tombé en désuétude, comme les forums […]

      Le partage de photo est pourtant l'une des utilisations les plus courantes pour le "grand public" sur internet. C'était vrai il y a quelques années, ça l'est encore plus aujourd'hui. Oui mais en quelques années, le paysage de l'internet a changé. Les mega-réseaux-sociaux sont arrivés et parce qu'ils sont simples à utiliser et gratuits, les gens les ont naturellement adopté. Facebook est le plus gros hébergeur de photos perso (et de très très loin). Ensuite on doit avoir Google+ Photos (ex Picasa Web Albums) et Flickr.

      Le fait que de nombreux utilisateurs aient choisi d'utiliser ces plateformes plutôt que des outils comme Piwigo est sans doute la raison de l'arrêt de nombreux projets.

      Piwigo propose clairement une alternative à ce mode de partage des photos. Une alternative où l'utilisateur maîtrise ses données personnelles et où il n'est pas l'objet d'un profilage pour rendre la publicité plus efficace. C'est à dire le coeur de métier de Google, Facebook ou Yahoo (c'est un fait, pas une attaque). Une alternative qui est également très personnalisable (ce qu'une partie des utilisateurs recherche aussi).

      : on ne trouve que des projets assez vieux (12 ans pour Piwigo,
      par exemple), la plupart sont même morts (Piwigo a l'air d'être
      un des derniers survivants)

      Le fait que Piwigo soit vieux mature ne veut pas dire qu'il n'a pas évolué. Piwigo a à peu près le même âge que Wordpress par exemple… Le grand âge de Piwigo est surtout un excellent signe pour ses utilisateurs, c'est le gage d'une stabilité du projet sur de longues années. Lors du choix d'un logiciel, est-ce que tu privilégies celui qui est là depuis longtemps, qui continue à évoluer et qui est activement maintenu, ou bien celui qui vient de naître, maintenu par une seule personne et qui a statistiquement peu de chance de survivre longtemps ?

      Oui Piwigo a survécu à la vague des réseaux sociaux, mais il n'a pas arrêté d'évoluer pour autant :-)

      , et je n'ai rien trouvé avec des solutions plus modernes (Django ou
      RoR, par exemple), ou des projets qui ne sont pas aussi aboutis.

      "plus moderne" ? Là c'est une simple critique de PHP par rapport à d'autres technologies. Personnellement je suis très content d'avoir misé sur PHP et par sur les autres technologies que tu cites. Si Piwigo était écrit en RoR, il serait réservé à une petite minorité d'utilisateurs car RoR n'est pas disponible aussi largement que PHP (c'est vraiment peu de le dire…). Mais bon, le choix technologique c'est vraiment une problématique de développeur. Les utilisateurs s'en moquent, ils veulent un logiciel facile à installer, facile à utiliser, qui évolue et qui est bien maintenu.

      […] le choix entre MySQL et MySQL pour la BDD (j'aimerais bien
      n'avoir qu'un PostgreSQL ; les frameworks type RoR ou Django permettent
      de choisir facilement sa bdd).

      Tu peux aussi utiliser MariaDB :-)

      Il y a quelques années, Piwigo a tenté l'expérience d'être compatible avec PostgreSQL et SQLite, à partir de la version 2.1 (mai 2010). Un an et demi plus tard, avec la version 2.3, nous avons arrêté l'expérience, essentiellement par manque d'intérêt des utilisateurs (je parle de l'immense majorité) et par le surplus de travail que cela demandait aux développeurs. Pour des détails lire http://piwigo.org/forum/viewtopic.php?id=18008

      absence de thèmes en Bootstrap 3

      Je crois que le nouveau thème greydragon http://piwigo.org/ext/extension_view.php?eid=775 utilise Bootstrap. Il a été créé par un utilisateur qui a switché de Menalto Gallery à Piwigo. Peut-être aussi le thème SimpleNG.

      J'espère que cela te rassure et te conforte dans le choix de passer sur Piwigo ;-)

      • [^] # Re: Ça tombe bien, j'allais l'installer

        Posté par . Évalué à 3.

        Avant tout, Pierrick, merci infiniment pour avoir créé et continuer à maintenir ce programme, je pense que l'existence de ce type de programmes est absolument vitale, car ils offrent une porte de sortie face à l'omniprésence dictatoriale des réseaux soit-disant sociaux.

        Piwigo propose clairement une alternative à ce mode de partage des photos. Une alternative où l'utilisateur maîtrise ses données personnelles et où il n'est pas l'objet d'un profilage pour rendre la publicité plus efficace. C'est à dire le coeur de métier de Google, Facebook ou Yahoo (c'est un fait, pas une attaque). Une alternative qui est également très personnalisable (ce qu'une partie des utilisateurs recherche aussi).

        C'est très exactement dans cette optique que je l'ai installé il y a deux ans, comme "proof of concept" pour mes amis à qui je disais "tes photos sont sur facebook, je n1ai pas de compte et n'en aurai jamais, mets-les ailleurs si tu veux que je les regarde", et aussi pour ma fille pour lui donner une possibilité de partager ses photos sans passer par FB.

        Je voulais un outil simple, qu'un usager sans grandes connaissances informatiques puisse utiliser. Piwigo n'est pas trivial à installer (pour un novice), mais il l'est à l'utilisation, une fois installé.

        En plus, le système de droits est très flexible, j'ai vraiment bien aimé. Bravo.

        • [^] # Re: Ça tombe bien, j'allais l'installer

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

          Bonjour sebas,

          Avant tout, Pierrick, merci infiniment pour avoir créé

          C'était pour le plaisir et le "défi" :-)

          et continuer à maintenir ce programme

          Cela fait maintenant parti de mon métier, mais cela reste un plaisir et une véritable aventure :-)

          Piwigo n'est pas trivial à installer (pour un novice)

          On ne va pas pouvoir simplifier davantage l'installation de Piwigo. C'est très exactement pour cela que Piwigo.com existe : pour que les non techniciens puissent avoir leur Piwigo sans avoir besoin de créer une base de données ou faire des sauvegardes.

      • [^] # Re: Ça tombe bien, j'allais l'installer

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

        Je suis tout à fait d'accord avec toi, sur l'ensemble des points.

        Quand je parle de vieux projets, ce n'est pas une attaque, c'est une constatation. Je mets Piwigo un peu dans le même sac que Wordpress et PhpBB : ils sont vieux, mais ils ont évolué, ils ont acquis avec le temps énormément de fonctions et ils ont une installation extrêmement bien fichue (avec des mises à jour directement depuis l'interface d'admin, par exemple).

        Je te rejoins également sur le fait que le monde des galeries perso/forums/blogs a été mangé par Facebook/Instagram/Google. Du coup, tout comme ils ont tué nombre de projets existant depuis longtemps, ils empêchent les nouveaux d'apparaître (faute d'audience potentielle, je pense).

        Et en dernier lieu, je suis encore d'accord avec toi pour dire que les solutions PHP restent les plus simples à mettre en place ; je m'étais d'ailleurs fait fortement moinsser quand j'avais dit ça, sous prétexte qu'on pouvait faire la même chose en Python (même si je n'ai jamais vu faire). Installer ou mettre à jour un site Django ou RoR est beaucoup plus compliqué qu'installer un site PHP, et demande pas mal de connaissances en ligne de commande (sans compter que ça ne se passe jamais bien avec Python :o)

        Par contre, je maintiens ce que je dis sur les vieilles technos, et les difficultés à passer à du PostgreSQL en sont une preuve. N'importe quel site en Django (sauf cas exceptionnel) peut passer à volonté à du MySQL, du PostgreSQL, du Oracle, du SQLite ou autre. J'ai dû faire du PhpBB, et c'est une galère à modifier (le moteur de template est un truc spécifique et pas terrible), les mods s'installent en modifiant le code d'origine, … Après, ce sont des outils (Piwigo, Wordpress ou PhpBB) qui ont commencé avant l'apparition de ces nouveaux outils, je ne peux pas reprocher qu'ils n'aient pas été utilisés :)

        Je vais regarder le thème avec attention, merci pour l'info :)

      • [^] # Re: Ça tombe bien, j'allais l'installer

        Posté par . Évalué à 4.

        Piwigo propose clairement une alternative à ce mode de partage des photos.

        Personellement je ne trouve pas. Les manière d'utiliser sont vraiment différentes entre ce que font les gens avec fb/g+/instagram et ce que propose piwigo. Piwigo est une bibliothèque d'album très accès sur cette organisation en album alors que les 2 autres sont très accès chronologie.

        Avec piwigo celui qui publie aura plutôt tendance définir un album potentiellement dans une arborescence, là où l'utilisateur de fb/g+ va publier un groupe de photo et donner un nom à se groupe.

        La gestion de la confidentialité était (je ne sais pas où ça en est) bien plus compliqué avec piwigo qu'avec fb/g+. Savoir qui à droit de voir quoi est complexe et les règles s'empile (le droit du dossier, de l'album et de la photo). C'est probablement plus flexible, mais plus long à prendre en main et ça risque de créer des erreurs1.

        Coté utilisateur cette focalisation sur les albums plutôt que sur une chronologie rend aussi l'utilisation très différentes. Il n'est pas simple de voir les nouveautés sur un compte piwigo et encore moins de voir les nouvelles photos d'un album déjà existant.

        Pour tout ça piwigo me semble plus être une alternative à flickr, un portfolio qu'au réseau sociaux classiques.


        1. une fonction qui pourrait être pratique c'est d'avoir une interface dans l'admin où on choisi un compte et on voit tout ce qu'il peut voir de manière concise (la liste des chemins de photo qu'il peut voir par exemple). 

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Ça tombe bien, j'allais l'installer

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

          une fonction qui pourrait être pratique c'est d'avoir une interface dans l'admin où on choisi un compte et on voit tout ce qu'il peut voir de manière concise (la liste des chemins de photo qu'il peut voir par exemple).

          Tu as à peu près ça avec admin tools : une fois activé, tu as un menu qui te permet de voir la galerie comme la verrait un autre utilisateur :

          Voir en temps que

          Tu peux voir exactement quelle photo il voit, et tu peux naviguer dans l'arborescence des albums pour voir lesquels il peut voir. Tu peux aussi ouvrir la page « photos récentes » pour voir si ce que tu viens d'ajouter est visible ou pas.

          Par rapport à ce que tu imagines, il manque sans doute la concision.

        • [^] # Re: Ça tombe bien, j'allais l'installer

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

          En effet Piwigo met beaucoup en avant l'organisation par album et assez peu une chronologie automatique. Une sorte de "photostream". Je compte bosser dessus dans quelques temps. Moi perso je fais un album par évènement et mes albums sont classés par ordre du plus récent au plus ancien. Quand les anciens albums "encombrent" ma page d'accueil, je les déplace dans une arborescence d'archivage (année/mois/évènement).

          A noter qu'on peut très bien laisser tous les albums à la racine sans faire de sous-albums. Il y a de toute façon une pagination automatique, avec par défaut 12 albums par page.

          Ceci étant dit, je ne cherchais pas à comparer "strictement" le fonctionnement d'un Facebook/G+Photos avec Piwigo, mais juste la problématique de fond qui est le partage de photo.

    • [^] # Re: Ça tombe bien, j'allais l'installer

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

      En plus de la réponse de Pierrick

      on ne trouve que des projets assez vieux

      Pourquoi ce jeunisme "que"? Linux a 23 ans, pas de nouveau noyau (utilisé) depuis, est-ce que ça veut dire que les noyaux ne sont plsu utilisés?
      C'est Open-Source, ça veut dire qu'on peut forker, et donc si un projet est "vieux", c'est bon signe : ça veut dire que le projet est viable.

      L'age des projets n'est que le signe que l'informatique n'est plus tout jeune, et qu'il y a des besoins auxquels on a pensé à répondre assez tôt. Pas besoin de recommencer à zéro, on fait évoluer l'existant. Une voiture de 1991 n'est pas une voiture de 2014, c'est pourtant une voiture avec des marques qui ont des dizaines d'années, pareil pour une galerie photo.

      • [^] # Re: Ça tombe bien, j'allais l'installer

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

        Comme dit plus haut : les technos modernes ont quand même des avantages, surtout les frameworks comme Django :

        • ils ont tous la même structure, donc on se plonge beaucoup plus facilement dans leur code quand on connaît déjà un projet,
        • les composants non-spécifiques sont standardisés (moteur de template, ORM, gestion des fichiers statiques, authentification, …) et réutilisables,
        • le code spécifique est souvent réutilisable au sein d'un autre projet,
        • on peut choisir son moteur de bdd,
        • on développe tellement plus vite avec ces nouveaux frameworks !
        • [^] # Re: Ça tombe bien, j'allais l'installer

          Posté par (page perso) . Évalué à -1. Dernière modification le 05/10/14 à 08:33.

          les technos modernes ont quand même des avantages, surtout les frameworks comme Django :

          Voit pas le rapport : si il y a un besoin, un projet "de plus de 10 ans" peut très bien migrer vers un framework qui va bien. Ca n'a rien à voir avec l'âge d'un projet. Comme si Linux n'utilisait pas MMX (les fonctions avancées d'un CPU) ou le 64-bit sous couvert que ça n'existait pas en 1991.

          on peut choisir son moteur de bdd,

          Ca a déja été répondu (=on s'en fout un peu, c'est surtout pour faire beau sur le papier, en pratique ça amène 0.05% de personnes interessées en plus)
          En fait, tu ne comprends pas, le développeurs préférent priorisé ce qui est utile (des nouvelles fonctionnalités en plus) quand toi tu préféres un truc "propre" qui permet de choisir sa BDD mais qui n'a pas de foncitonnalités derrières. Lespriorités sont simplement différentes.

          les composants non-spécifiques sont standardisés

          Ha ha ha : tiens, c'est nouveau, Django est passé par un organisme de standardisation et il y a plusieurs implémentation du standard? Admettons standard "de facto" (que n'est pas Django, qui n'est qu'un framework parmi des centianes d'autres, genre Symphony pour parler PHP), ça fait ça quand même.


          Comme dit plus haut : du jeunisme.

          • [^] # Re: Ça tombe bien, j'allais l'installer

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

            En fait, je ne vois pas bien où tu veux en venir…

            En l'occurrence, les projets dont je parle depuis tout à l'heure n'utilisent pas les frameworks plus récents comme Django ou RoR. Sinon, je ne dirais pas qu'ils ne les utilisent pas… Je sais que je suis un peu bête, mais quand même…

            Quant à ton second argument, je ne vois pas à quoi il répond.
            Je dis qu'on ne peut pas utiliser PostgreSQL et que je le regrette, et que c'est justement un des avantages des frameworks que j'ai cités. Qu'est-ce que je ne comprends pas là-dedans ? C'est purement factuel.
            Je ne crois pas avoir dit que Piwigo devrait se mettre à PostgreSQL et qu'ils sont vraiment trop mauvais de ne pas l'avoir fait…

            Quant à ton dernier paragraphe : je parle des sites codés en Django (oui, il faut lire toute la phrase, avec le contexte). Et quand tu veux te plonger dans le code d'un site Django, tu t'y plonges facilement, parce qu'il a exactement la même structure que n'importe quel autre site en Django, et que parmi les sites utilisant Django, l'ORM et le moteur de template de Django sont des standards de fait.
            (et je ne vois pas où je parle de faire un nouveau standard, bien autre contraire je parle de composants qui existent depuis 10 ans.

            Bref, je ne vois pas l'intérêt de ton message, celui de Pierrick est bien constructif et agréable.

        • [^] # Re: Ça tombe bien, j'allais l'installer

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

          Bonsoir flan,

          Je n'ai pas envie de me lancer dans un grand débat sur l'utilisation d'un framework. On pourrait très bien le faire avec Symphony par exemple. Pour moi ce genre de framework est idéal quand une société de service développe et livre un projet à un client. Cela permet au client de reprendre le code facilement et/ou de le faire maintenir par un autre prestataire. L'inconvénient c'est la performance. A chaque fois que je vois des logiciels utilisant ces frameworks, il y a 2 ou 3 niveaux de cache pour pallier au fait que le code n'est pas du tout optimisé. Je parle surtout des accès à la base de données. Quand une société de service livre à un client entreprise, pas de soucis, on adapte le hardware et ça tourne nickel. Pour Piwigo c'est un peu différent.

          Je vais répéter ce que j'ai déjà dû écrire 3 fois sur LinuxFR (oui, à chaque fois qu'une nouvelle version de Piwigo est annoncée sur LinuxFR, il y a au moins un commentaire sur le fait qu'on devrait utiliser un framework…) : il y a fort longtemps un contributeur nous a dit qu'il fallait tout refaire avec le framework X. Je lui ai dit "pourquoi pas, mais d'abord on regarde un prototype et voit ce que ça donne". Résultat, même avec 10% des fonctionnalités, le temps de génération des pages passait de 50ms (code Piwigo) à 500ms (code framework). Le contributeur a dit qu'il ne pensait pas qu'on puisse faire mieux. Alors moi tant qu'on ne me prouve pas que l'utilisation d'un framework ne va pas ruiner les perfs (attention, Piwigo doit fonctionner sur un mutualisé) et qu'il ne va pas falloir tout redévelopper (des milliers d'heure de travail), je pense que le code actuel va très bien :-)

          Encore une fois, l'histoire de coder avec tel framework ou telle techno, c'est une problématique de développeur, certainement pas celle des utilisateurs. La première cible ce sont les utilisateurs. J'ajoute qu'ici on est sur Linuxfr, dont l'objectif est de promouvoir les logiciels libres (je viens de relire la page "à propos"), donc je ne comprends pas pourquoi on revient toujours sur ce genre de question qui sont des questions d'implémentation technique :-/ Mais bon, chacun est libre de voir Piwigo sous cet angle et de le "critiquer" en conséquence.

    • [^] # Re: Ça tombe bien, j'allais l'installer

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

      Concrètement, je n'ai pas grand-chose à reprocher à Piwigo, à part le couplage à MySQL et l'absence de thèmes en Bootstrap 3 (j'aimerais coupler ma galerie photo à un site et un forum en Bootstrap 3, et ça facilite bien les choses), du coup, je pense que je vais vraiment partir sur du Piwigo.

      Il y a quelques mois, j'ai commencé un fork de piwigo qui supporte PostgreSQL et SQLite en plus de mysql. D'un point de vue visiteur, pas de différence entre piwigo et mon fork. Sous le capot cela commence un peu à diverger.

      • [^] # Re: Ça tombe bien, j'allais l'installer

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

        Est-ce que le but est de fusionner un jour avec Piwigo ? Si non, quelle est la raison pour avoir forké au lieu de contribuer directement ?

        • [^] # Re: Ça tombe bien, j'allais l'installer

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

          Parce que le support multi-base n'intéresse pas l'équipe derrière Piwigo.

          • [^] # Re: Ça tombe bien, j'allais l'installer

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

            Je vois que tu travailles aussi sur des tests automatisés, du nettoyage de code, et d'autres fonctionnalités que Piwigo n'a pas. Rien que les tests, c'est vraiment bien, je pense que c'est un gros manque de Piwigo. J'aimerais vraiment avoir ça remonté en upstream, perso.

            • [^] # Re: Ça tombe bien, j'allais l'installer

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

              Je vois que tu travailles aussi sur des tests automatisés, du nettoyage de code, et d'autres fonctionnalités que Piwigo n'a pas. Rien que les tests, c'est vraiment bien, je pense que c'est un gros manque de Piwigo. J'aimerais vraiment avoir ça remonté en upstream, perso.

              Mes tests ne sont pas trop spécifiques à mon fork donc ils sont facilement intégrables dans piwigo. En revanche c'est long, très long à intégrer ces tests à partir de zéro mais très intéressant à faire.

          • [^] # Re: Ça tombe bien, j'allais l'installer

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

            Sinon, je vais peut-être dire un truc bête, mais si je lis bien http://piwigo.org/forum/viewtopic.php?id=18008, la raison principale était que ça demandait du travail que les développeurs n'étaient pas prêts à fournir (je suppose que tu es le « Nicolas » mentionné dans le message ?). Si le travail est maintenant fait de toutes façons (par toi), ça me paraîtrait intéressant que les autres en bénéficient.

            Je suis assez d'accord avec Pierrick sur le fait que ce n'est pas une fonctionnalité majeure pour les utilisateurs (encore que, le support SQLite est sympa pour quelqu'un qui veut se simplifier la vie avec les backups, une arborescence à sauvegarder et tout est dedans), mais je suis aussi d'accord avec toi sur le fait qu'exposer le code à plusieurs environnements aide à trouver des bugs.

            Enfin, je dis ça d'un point de vue parfaitement naïf, tu connais mieux la question que moi.

    • [^] # Re: Ça tombe bien, j'allais l'installer

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

      Pour Pg, il existe Phyxo, un fork de Piwigo. http://www.nikrou.net/post/2014/09/28/Phyxo-1.2.0-est-de-sortie-!
      Mes 0.02€ :)

  • # Dommage

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

    Je suis utilisateur de Piwigo et j'en assez content. Avant j'utilisais Gallery 2 qui était plus complexe à appréhender et Gallery 3 ne propose pas les fonctionnalités qu'avait Gallery 2, en particulier la géolocalisation. C'est aussi pour cela que j'utilise maintenant Piwigo car l'extension "RV Mqps & Earth" http://piwigo.org/ext/extension_view.php?eid=122 est excellent.

    Piwigo a toutefois deux défauts que je trouve assez importants:
    - Les images ne sont pas protégées si on connait leur chemin. Voir http://piwigo.org/forum/viewtopic.php?id=20372 . Tous les liens d'images devraient passer par un script PHP qui vérifie qui accèdent à l'image. Malheureusement ce n'est pas le cas :(
    - Les tags des photos auxquelles on n'a pas le droit sont tout de même affichées dans la page "Tags". J'ai tendance à taguer les noms de mes amis ou ma famille sur mes photos privées et je n'ai pas envie que leurs noms apparaissent sur cette page pour les personnes qui n'ont pas accès à ces images.

    Autre souci, il ne faut (fallait ?) pas d'espaces dans les chemins des photos sinon il est paumé. Mais ça on peut s'y faire lorsqu'on range ses photos.

    L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

    • [^] # Re: Dommage

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

      Bonjour,

      Je suis le fondateur de Piwigo. Voici quelques précisions :

      Les images ne sont pas protégées si on connait leur chemin […]

      Les choses ont un peu évolué depuis 2012. On peut imposer à Piwigo de passer systématiquement par un script PHP (i.php, i comme image) pour "servir" la photo. Pour cela il faut ajouter dans sa configuration locale : $conf['original_url_protection'] = 'images'; ainsi que $conf['derivative_url_style'] = 2; + ajouter un fichier .htaccess "Deny from all" dans les répertoires "upload", "galleries" et "_data/i". On n'a cependant pas encore implémenté complètement l'idée, car i.php ne vérifie pas les permissions de Piwigo. On réfléchit à le faire pour bientôt. D'un côté on ne veut pas nuire aux performances, de l'autre on veut répondre à cette problématique de sécurité. Peut-être qu'on le proposera en option seulement.

      Remarque importante : en dehors de l'ajout de photo par FTP et synchronisation, les fichiers sont enregistrés avec un nom modifié, comportant une partie "aléatoire". Ce qui rend la "découverte" très compliquée… (mais pas impossible).

      Les tags des photos auxquelles on n'a pas le droit sont tout de même affichées dans la page "Tags" […]

      Ca c'est un bug (que je ne reproduis pas). Normalement on ne peut voir un tag que si on accède à au moins une photo qui est associée à ce tag. Donc ce serait bien que tu ouvres un sujet sur le forum et que tu décrives le problème (on aura sûrement besoin d'aller regarder pour comprendre).

      Autre souci, il ne faut (fallait ?) pas d'espaces dans les chemins des photos […]

      Depuis Piwigo 2.4, tu peux modifier la liste des caractères autorisés, avec me paramètre de configuration locale sync_chars_regex (voir le plugin LocalFiles Editor).

      Attention : certains nous ont fait la remarque qu'en autorisant certains caractères spéciaux comme l'apostroque ou le slash, ça cassait des choses ensuite. Pour moi ce n'est pas un soucis majeur (à l'utilisateur de ne pas autoriser "n'importe quoi" non plus). En tout cas ça marche très bien pour les espaces ou les caractères accentués.

      • [^] # Re: Dommage

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

        Merci pour ta réponse. Je vais regarder tout cela.

        L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

        • [^] # Re: Dommage

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

          Tout d'abord, au temps pour moi, les tags affichées sont bien uniquement celles des images auxquelles ont a accès. Par contre (mais c'est moins grave), on peut retrouver les tags existantes via les URL http://…../index.php?/tags/XXX en incrémentant XXX de 0 à l'infini.

          Sinon pour $conf['original_url_protection'] = 'images' le souci c'est que cela ne gère que les images (qu'est ce qu'une image pour Piwigo ?) et pas les autres formats SVG, MP4, XCF,… car en effet ma galerie contient aussi des formats moins standards. Alors j'ai essayé $conf['original_url_protection'] = 'all' (trouvé sur le forum de Piwigo) mais ça ne change rien.
          Et comme tu l'as indiqué, il n'y a pas de vérification des droits dans i.php donc si on a une connaissance qui diffuse cette URL (intentionnellement (Facebook, Twitter,…) ou pas MSN, Hangout,…) elle peut devenir public. Certes il pourrait aussi faire un "Enregistrer sous" et tout de même diffuser l'image mais ça serait de sa responsabilité pas une négligence de l'hébergeur.

          Sinon avec la migration vers Piwigo 2.7, l'extension "Advanced Metadata" http://fr.piwigo.org/ext/extension_view.php?eid=364 est définitivement cassée. J'avais réussi à la bidouiller pour fonctionner aec la version 2.6 mais là c'est mort. Et là j'ai découvert cette page http://fr.piwigo.org/doc/doku.php?id=pwg22:utilisation:fonctionnalites:meta qui explique comment importer les données eXIF et IPTC des photos. En particulier, cela récupère les keywords pour les transformer en tags. Bref, je retrouve en partie les possibilités d'extension "Advanced Metadata". Mais par contre, pourquoi ce n'est pas intégré de base ? Pourquoi ne pas fournir une interface pour configurer cela plutôt que d'ajouter des clés sorties de nulle part à un fichier de configuration ?
          Il me reste à voir comment importer le titre et la description de mes images dans les champs correspondants de la base de données Piwigo.

          Bon, certes j'apporte surtout des critiques négatives et j'ai une position facile en tant que simple utilisateur. Aussi, je voudrais te dire un grand merci et faire de même pour les contributeurs car malgré ces quelques défauts, Piwigo est un logiciel fantastique qui je suis sûre va continuer de s'améliorer à chaque version.

          L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

          • [^] # Re: Dommage

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

            on peut retrouver les tags existantes via les URL
            http://…../index.php?/tags/XXX en incrémentant XXX
            de 0 à l'infini.

            Bien vu. A corriger. http://piwigo.org/bugs/view.php?id=3155

            Sinon pour $conf['original_url_protection'] = 'images' le
            souci c'est que cela ne gère que les images […]

            Je n'ai pas bossé sur cette fonctionnalité. Peux tu ouvrir une discussion sur le forum à ce sujet ?

            […] il n'y a pas de vérification des droits dans i.php […]

            On va le faire. Eventuellement désactivable mais je suis d'accord que c'est quelque chose qui compte. Il n'y pas d'opposition "idéologique" sur la question :-)

            Piwigo 2.7, l'extension "Advanced Metadata" cassée […]

            En effet, ce plugin n'est plus maintenu par son auteur. Personnellement je trouve qu'il est assez lourd au niveau de la base de données et pour sa configuration (il en fait "trop"), mais il a l'avantage de proposer une configuration par page d'administration et il y a un très intéressant moteur de lecture des EXIF/IPTC.

            importer les données eXIF et IPTC […] pourquoi ce n'est pas
            intégré de base ?

            Mais c'est une "core feature". Désactivé par défaut, mais c'est "de base" quand même.

            Pourquoi ne pas fournir une interface pour
            configurer cela plutôt que d'ajouter des clés sorties de nulle
            part à un fichier de configuration ?

            Ca fait longtemps que j'aimerais la faire cette interface "simple" pour configurer le mapping des IPTC avec les propriétés de la photo. Pour le moment je n'ai pas réussi à faire quelque chose. Mais je suis d'accord il faudrait une interface graphique où l'on ne manipule pas des 2#025… pour info :

            $conf['use_iptc'] = true;
            $conf['use_iptc_mapping'] = array(
            'keywords' => '2#025',
            'author' => '2#122',
            'name' => '2#005',
            'comment' => '2#120'
            );

            dans la configuration locale (voir le plugin LocalFiles Editor), en général ça suffit.

            je voudrais te dire un grand merci et faire de même pour les contributeurs
            car malgré ces quelques défauts, Piwigo est un logiciel fantastique

            Merci :-) c'estun travail sur la durée, avec de nombreux contributeurs passionnés et volontaires !

          • [^] # Re: Dommage

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

            Et comme tu l'as indiqué, il n'y a pas de vérification des droits dans i.php donc si on a une connaissance qui diffuse cette URL (intentionnellement (Facebook, Twitter,…) ou pas MSN, Hangout,…) elle peut devenir public.

            Attention, l'URL « confidentielle », c'est celle du fichier .jpg, pas l'URL de la page web qui permet de la visualiser (i.e. si tu partages http://demo.piwigo.com/picture?/115/category/birthday-party, tu restes en sécurité, il faudrait que tu partages une URL du style http://demo.piwigo.com/uploads/v/8/z/v8z3358vr7/2010/06/25/20100625235929-97d0f688.jpg pour prendre un risque). Le partage « par mégarde » me parait peu probable. Pour le partage intentionnel, ça n'est pas beaucoup plus difficile de partager l'image que de partager son URL.

            Et ce n'est pas du tout spécifique à piwigo. Au moins Google+ et Facebook font pareil (ce qui leur permet d'avoir les images sur des serveurs optimisés pour les pages statiques, et d'utiliser des CDN pour que les téléchargements se fassent depuis des serveurs proches de l'utilisateur).

            Ça ne veut pas dire qu'il n'y a pas de problème du tout, mais c'est quand même beaucoup moins problématique que ça pourrait en avoir l'air.

            Dans le cas de Piwigo, on devrait pouvoir s'en sortir avec mod_xsendfile sous Apache (https://www.tn123.org/mod_xsendfile/) quand il est présent pour ne pas plomber les perfs.

      • [^] # Re: Dommage

        Posté par . Évalué à 8.

        D'un côté on ne veut pas nuire aux performances, de l'autre on veut répondre à cette problématique de sécurité

        Clairement en ce moment, c'est l'aspect sécurité qui est recherché … Demandez à jeniffer Lawrence (d'ailleurs il y a des prospects à démarcher de ce coté là). Non sérieusement ceux qui veulent de la simplicité et/ou des performances, picasa/google/flickr réponds à leur besoin. Ceux qui installent piwigo sur leurs serveurs, c'est surtout dans l'optique de sécuriser ses données.

        • [^] # Re: Dommage

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

          Bonjour FabienC,

          Ceux qui installent piwigo sur leurs serveurs, c'est surtout
          dans l'optique de sécuriser ses données.

          Je ne serais pas si catégorique. L'aspect gratuit et personnalisable est très apprécié…

          Attention à ne pas penser qu'une photo hébergée sur un Piwigo est accessible comme ça facilement. Si on utilise autre chose que le FTP (soit la très très grande majorité des utilisateurs) alors les chemins sont "aléatoires". Et ceux qui utilisent le FTP + synchro peuvent très ajouter un code aléatoire sur le nom de leurs fichier (moi je faisais ça à a lointaine époque où j'utilisais le FTP).

          Demandez à jeniffer Lawrence (d'ailleurs il y a des prospects
          à démarcher de ce coté là)

          Je ne me risquerais pas à prétendre que Piwigo est un coffre-fort inviolable. Il y a des failles qui sont découvertes (comme sur tous les logiciels populaires) et que l'on corrige aussi efficacement que possible.

          La différence avec iCloud (ou Flickr, ou Google+ Photos, ou Facebook…) c'est que Piwigo est naturellement "décentralisé". Cela complique évidemment le travail des "pirates".

  • # Ergonomie

    Posté par . Évalué à 2.

    J'administre une galerie privée depuis quelques années. J'avais choisi Gallery 3 de Menalto. Pour moi, ce qui fait la différence entre Gallery 3 et les autres galeries, c'est le soin qui a été apporté à l'ergonomie.

    Ma galerie me sert principalement à partager des photos d'événements (vacances, week-end, repas, sorties, …) avec des connaissances (amis, famille). Chaque utilisateur (ou groupe d'utilisateurs) a un login/mot de passe. J'ai donc un panel d'utilisateurs assez varié : de ceux qui maitrisent bien la "chose" informatique à ceux qui galèrent pour joindre un fichier à un email. La galerie doit donc être (littéralement) KISS, pour qu'ils puissent tous naviguer, télécharger et envoyer des photos/vidéos.

    Après l'annonce de la fin du projet G3 (ça semble acquis, il y a eu un petit espoir de reprise du projet, mais ça bouge plus), j'ai testé différents logiciels de galeries, dont Piwigo. Il m'a semblé qu'aucun d'entre eux n'a apporté le même soin de faire une interface simple d'utilisation. Je suis donc toujours "coincé" sur Gallery 3, jusqu'au jour ou je n'aurais plus le choix (faille de sécurité non patché)

    Un exemple en ce qui concerne Piwigo : pour envoyer une photo il faut aller dans "administration > ajouter une photo", puis choisir l'album. C'est 3 étapes de trop. Lorsque je suis dans l'album, ça me parait naturel d'avoir un bouton "envoyer des photos" sans que le contexte change. Envoyer une photo ou créer un album, c'est pas acte d'administration, c'est de l'utilisation.

    Il ne faut voir aucune attaque dans mon message, juste une critique qui j'espère sera constructive. Je souhaites une longue vie à Piwigo, même s'il ne me convient pas, c'est une belle réussite.

    • [^] # Re: Ergonomie

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

      Je ne sais pas exactement ce que tu mets derrière ergonomie (c'est un vrai métier ergonome) mais je partage ton avis quoi qu'il en soit. Je crois que c'est le problème de beaucoup de logiciels fait par des développeurs. Faire du code (au sens large) c'est un métier. Faire des interfaces jolies, fonctionnelles, riches, et ergonomes c'est difficile sans l'appui d'un ergonome (ou de quelqu'un ayant des compétences approchantes).

    • [^] # Re: Ergonomie

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

      Un exemple en ce qui concerne Piwigo : pour envoyer une photo il faut aller dans "administration > ajouter une photo", puis choisir l'album. C'est 3 étapes de trop. Lorsque je suis dans l'album, ça me parait naturel d'avoir un bouton "envoyer des photos" sans que le contexte change. Envoyer une photo ou créer un album, c'est pas acte d'administration, c'est de l'utilisation.

      Pourquoi tu ne vas pas dans ton album et "ajouter des photos" ? Cela ressemble à ce que tu voudrais non ?

    • [^] # Re: Ergonomie

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

      Je te conseille l'extension "Admin Tools" qui permet l'ajout de photos depuis un album http://fr.piwigo.org/ext/extension_view.php?eid=720 et d'autres facilités du genre.

      L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

      • [^] # Re: Ergonomie

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

        J'allais répondre la même chose. Pour moi, le problème d'ergonomie de Piwigo, c'est que les trucs bien et pratiques sont dans des plugins désactivés par défaut, et que le débutant doit trouver ceux qui vont lui faciliter la vie parmi une centaine d'autres.

        Mais effectivement, une fois le choix de plugins fait, c'est quand même agréable à utiliser.

    • [^] # Re: Ergonomie

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

      Bonsoir ondex2,

      J'avais choisi Gallery 3 de Menalto. Pour moi, ce qui fait la différence
      entre Gallery 3 et les autres galeries, c'est le soin qui a été apporté
      à l'ergonomie.

      En tant que fondateur de Piwigo, mon avis est totalement biaisé bien sûr, mais pour avoir récemment testé Gallery 3 (pour écrire le plugin de conversion Menalto2Piwigo) je n'ai pas trop aimé l'ergonomie proposée par Gallery3. En particulier, je n'apprécie pas d'avoir l'impression d'être dans l'administration quand je suis en train de naviguer dans la galerie. Dans Piwigo, sur les pages de l'album et de la photo, il y a un bouton pour aller sur la page d'administration correspondante puis revenir. Avec le plugin Admin Tools, on peut aussi faire quelques opérations d'administration depuis la galerie (mais sans que ça soit omniprésent sur la page). Bref, c'est un peu une question de goût aussi.

      Sur le fond je suis totalement d'accord sur l'importance de l'interface utilisateur (certains diraient "expérience utilisateur"). Nous y accordons beaucoup d'importance sur Piwigo et si tu regardes l'historique des versions, tu pourrais voir que depuis quelques années, il ne s'agit pas tant d'ajouter des nouvelles fonctionnalités que de revoir l'interface utilisateur pour la rendre plus simple à utiliser.

      La galerie doit donc être (littéralement) KISS, pour qu'ils puissent tous
      naviguer, télécharger et envoyer des photos/vidéos.

      Il y a des centaines de milliers de Piwigo qui tournent et chacun a de nombreux visiteurs qui l'utilisent. Il y a donc quand même des gens qui s'en sortent avec Piwigo et qui le trouve très simple :-) On a des témoignages qui nous le disent très clairement. Bon évidemment, je mentirais si je disais que tout le monde trouve le fonctionnement limpide. Dans 95% des cas qui trouvent Piwigo pas assez simple, c'est une question de gestion des permissions. On y travaille, on réfléchit à ce qu'on peut faire pour simplifier tout en gardant un système aussi souple et puissant qu'aujourd'hui.

      Un exemple en ce qui concerne Piwigo : pour envoyer une photo il faut aller
      dans "administration > ajouter une photo", puis choisir l'album.

      Tu peux aussi aller sur ton album côté galerie, cliquer sur "éditer" puis sur la page d'administration de l'album cliquer sur "ajouter des photos", donc 2 clics. Si tu actives le plugin Admin Tools, tu auras ce bouton "ajouter des photos" directement en haut sur la page de l'album, donc 1 seul clic.

      juste une critique qui j'espère sera constructive.

      Tout à fait constructive, mais je pense assez subjective car liée à l'utilisation de Gallery 3 depuis un moment.

      Je souhaites une longue vie à Piwigo, même s'il ne me convient pas, c'est une belle réussite.

      Merci pour ces encouragements. Je te recommande de ne pas t'attacher aux détails sur les différences de fonctionnement entre Piwigo et Gallery3 et de refaire un essai plus poussé. Si tu as des questions ou autres, le forum Piwigo.org (dispo en français) saura te guider :-)

  • # Quand est-il de la sécurité ?

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

    Salut, je voulais savoir si piwigo avait une bonne sécurité, car j'aimerais l'utiliser afin d'héberger mes photos personnelles et en faire profiter mes proches. Donc forcément, la sécurité est un élément déterminant pour le choix de cette application.

    Merci !

  • # Le défaut de tous les albums

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

    La plupart des albums et galeries utilisent une base de données pour stocker des informations relatives aux images. C'est intéressant mais cela a un gros inconvénient : les méta-données ne sont pas dans l'image mais stockées en dehors.
    Si on extrait ou donne une image, on perd l'information de savoir qui est sur la photo ou ce que signifie une image.

    Il y a une solution, c'est d'utiliser les commentaires JPEG qui sont comme les EXIF intégrés dans la photo. Cela va dans le sens de l'histoire, les EXIF sont de plus en plus précis: il permettent de savoir quand et où la photo a été prise, avec quel appareil et dans quelles conditions, mais le contenu de la photo doit faire l'objet d'une saisie car il n'est pas automatisable.

    Pour mettre un commentaire, l'utilitaire wrjpgcom est votre ami. Il permet de mettre d'un coup "Vacances 2014 à Arcachon" sur un ensemble de photos avec une seule ligne de commande.
    Ensuite, il faut compléter cette information soit avec wrjpgcom, soit avec un logiciel d'affichage qui permet de compléter l'information. C'est ainsi que l'on pourra savoir dans 50 ans que c'est l'oncle Jean qui est au centre, entouré de ses nièces Julie et Hélène.

    Les commentaires peuvent être lus avec rdjpgcom, inclus ainsi que wrjpgcom dans le paquet jpeg-progs (disponible dans toutes les bonnes distributions).

    La pérennité de l'information est un point capital : Il est à peu près certain que les images JPEG seront toujours affichables dans 50 ans mais qui saura encore ce qu'elles représentent ? Il est peu probable que les albums actuels fonctionnent encore sur les ordinateurs que nous aurons dans un demi-siècle.
    À l'époque des photos argentiques, on écrivait au crayon au dos des photos ce qu'elles représentaient. Les photos ont jauni ou pâli mais on sait toujours ce qu'elles représentent. Les photos numériques seront intactes mais on aura perdu leur signification. On a remplacé une fragilité par une autre d'un nouveau genre.

    Il existe un logiciel qui fabrique un album automatiquement et affiche les commentaires JPEG. C'est Squarely http://www.framasoft.net/article4569.html dont je possède une version légèrement améliorée : http://pjarillon.free.fr/docs/squarely_v1.0.2.tar.gz qui ne demande qu'à être perfectionnée et à être source d'inspiration pour d'autres applications.

    • [^] # Re: Le défaut de tous les albums

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

      Bonsoir Pierre,

      Utiliser une base de données (ou un système de stockage des infos, peu importe la technologie) est absolument indispensable si on veut pouvoir faire des recherche par exemple.

      Piwigo est capable de lire les EXIF/IPTC pour remplir les propriétés de la photo. Avec le plugin Write Metadata http://piwigo.org/ext/extension_view.php?eid=769 Piwigo peut aussi écrire les IPTC (donc dans la photo) à partir de ce que l'utilisateur a renseigné dans Piwigo.

      Je suis 100% d'accord que c'est génial d'avoir des métadonnées (données intégrées dans les photos).

  • # Utilisateur de Piwigo ...

    Posté par . Évalué à 8. Dernière modification le 06/10/14 à 22:49.

    .. depuis plusieurs années en tant que photographe amateur auto-hebergé (voir ma page perso pour un aperçu du résultat notamment le côté mosaïque JS avec Gthumb+), j'en suis très content.
    Malgré la méga tonne de bidouilles que j'ai apporté au thème/framework que j’utilise, j'arrive toujours à faire les MAJ lorsqu'elles sont proposées. Effectivement de mon point de vue je n'ai pas besoin du côté collaboratif puisqu'il s'agit de ma galerie perso.

    Honte à moi j'utilise aussi Koken (juste pour tester comme ça), sur une version Beta (c'est joli, ce n'est pas open source, ça t'incite à mettre la main au porte monnaie, c'est pété de bug dans l'interface d'admin notamment, ce n'est pas du tout aussi bidouille friendly que Piwigo, notamment pour la partie bloging, y a pas vraiment de communauté etc …), bref j'suis pas près de migrer ;)

  • # Attention aux très très gros sites photo, cependant

    Posté par . Évalué à 1.

    Si vous envisagez un site avec plusieurs centaines de milliers de photos, une mise en garde, Piwigo persiste à faire de nombreux SELECT DISTINCT lors de la mise en ligne de nouveaux paquets d'images, de quoi mettre à genoux le processeur des plus gros serveurs, au moins en php fcgid (selon leurs forums).

    • [^] # Re: Attention aux très très gros sites photo, cependant

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

      Bonjour Beuar,

      Il y a plusieurs comptes Piwigo.com avec des centaines de milliers de photos et cela ne pose pas le moindre problème de performances. Donc on ne peut pas "généraliser" cette histoire de "SELECT DISTINCT" (qui ne doit poser aucun soucis avec les bons indexes).

      Hors Piwigo.com, l'été dernier, j'ai travaillé sur un cas particulier, avec effectivement des énormes montées de la charge du serveur (plus de 200). Il y avait sur ce Piwigo plusieurs centaines de visiteurs en simultané et le problème n'était pas spécifique à l'ajout de photos. Après de nombreuses heures de tests, le problème a été identifié : c'était le fait de faire tourner PHP derrière Apache en suPHP. J'ai alors appris que ce mode d'exécution était particulièrement lent lorsqu'il y a de la forte concurrence (nombreuses visites simultanées).

      La solution mise en place : nginx + php-fpm, sans la moindre modification de Piwigo. Et cela tourne "comme une horloge".

      Il y a sans doute des cas "particuliers" où on peut voir des dégradations de performances, mais on fait tout notre possible pour que Piwigo tourne aussi vite avec 1000 (mille) photos et avec 1000000 (million) photos.

  • # Paquet Debian

    Posté par . Évalué à 2.

    Bonjour,

    Je fais partie de ceux qui ont une galerie perso avec Menalto Gallery3 (qui s'est malheureusement arrêté), je migre vers Piwigo.

    J'ai fait un paquet Debian de piwigo:

    http://thocar.org/debian/piwigo_2.7.0-1_all.deb

    ma clef publique qui a signé le paquet est ici

    http://thocar.org/piwigoThocarOrgPublic.key

    La création de ce paquet répond à différents buts:

    • que ce soit plus aisé d'expérimenter des galeries sans abîmer sa galerie principale (fonctionnalité multi-site avec plus grande isolation entre sites)
    • meilleure intégration à debian
    • respect du standard de rangement de Linux (taper "man hier")

    Ca a comme effet de bord de passer au crible les permissions et propriétaires appropriés pour chaque fichier de piwigo, la conf est dans /etc/piwigo, les données sont dans /var/piwigo, les binaires dans /usr/share/piwigo.

    Mais comme je suis nouveau sur piwigo, je ne sais pas tester rapidement l'ensemble des fonctionnalités, il se peut que les droits sur quelque dossiers soient encore un peu trop scricts en terme de sécurité, et qu'il faille les changer.

    A part ça, je n'ai pas d'avertissement car aucun fichier de piwigo 2.7.0 n'a été changé pour faire l'empaquetage debian.

    Une fois le paquet installé (des binaires auront été mis dans /usr/share/piwigo, la doc dans /usr/share/doc/piwigo); ensuite lancez piwigo-instance-manager, il vous dira la suite ("piwigo-instance-manager create monInstance").

    Si vous voulez tout enlever proprement:

    $ piwigo-instance-manager list
    $ piwigo-instance-manager delete monInstance
    $ dpkg -r piwigo
    Si vous avez envie d'essayer le paquet et que vous trouvez un bogue, écrivez-moi.

    Thomas

Suivre le flux des commentaires

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