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
- PhpWebGallery (37 clics)
- PhpWebGallery sur Gna! (5 clics)
- Forum de support (9 clics)
- Demo en ligne (13 clics)
- Historique des versions (6 clics)
- Bogues et demandes de fonctionnalités (1 clic)
# Nom illégal ?
Posté par Dinofly (site web personnel) . Évalué à 1.
[^] # Re: Nom illégal ?
Posté par domo . Évalué à 5.
En gros, c'est pas illegal, c'est deconseillé par PHP
# se passer du système de fichier
Posté par flyer . Évalué à 5.
[^] # Re: se passer du système de fichier
Posté par jjl (site web personnel) . Évalué à 4.
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 Damien Metzler . Évalué à 4.
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 Damien Metzler . Évalué à 2.
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 Pooly (site web personnel) . Évalué à 1. Dernière modification le 04 décembre 2021 à 20:31.
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 (NdM: remplacé en 2021 par un lien archive.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 Pierrick Le Gall (site web personnel) . Évalué à 3.
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.
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 Bouiaw . Évalué à 1.
[^] # Re: se passer du système de fichier... ou de la BD ?
Posté par Pierrick Le Gall (site web personnel) . Évalué à 1.
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 Yann Cochard (site web personnel) . Évalué à 1.
Il existe deja de nombreuses couches d'abstraction pour l'acces a la BdD. Quand j'ai commence a me renseigner, on m'a recommande celui-ci :
- http://adodb.sourceforge.net/(...)
Il l'air ultra simple a utiliser, mais je n'ai pas encore mis en pratique.
Yann
[^] # Re: se passer du système de fichier... ou de la BD ?
Posté par rouby (site web personnel) . Évalué à 1.
[^] # Re: se passer du système de fichier... ou de la BD ?
Posté par Pooly (site web personnel) . Évalué à 2.
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 Pierrick Le Gall (site web personnel) . Évalué à 1.
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 Pooly (site web personnel) . Évalué à 2.
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 Nicolas (site web personnel) . Évalué à 0.
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 Pierrick Le Gall (site web personnel) . Évalué à 2.
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.
??? 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 Nicolas (site web personnel) . Évalué à 0.
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 Mes Zigues . Évalué à 1.
[^] # Re: Mise à jour chez Free ?
Posté par Pierrick Le Gall (site web personnel) . Évalué à 1.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.