Français
Tu peux configurer OpenStreetMap pour avoir une petite photo carrée à la place du marqueur bleu.
C'est rigolo ton thème de chemises hawaïennes, on se croirait dans Magnum ! Moi, sur mon site, j'ai tagué "châle" toutes les photos où l'on me voyait avec un de mes châles bariolés.
plg > bon j'ai dépassé ma flemme, j'ai racheté un nouvel hébergement pour avoir du php 8.3 et faire une migration en douceur
Galerie courante
https://chemise.grall.xyz
Migrée
https://chemise.grall.ovh
J'utilisais que pour le plugin RV Map & Earth qui me permettait de localiser toutes les photos de chemise hawaienne prises dans le monde entier. Il est plus supporté, maintenant c'est openstreetmap. Il faut que je vois si je peux faire pareil, je l'avais custom pour afficher directement les photos a la place des pins si un seul résultat
ddtddt a écrit:
sur un mutualisé t'est vraiment sur de toi ?
non, mutualisé je ne pense pas, mais dédié certainement, c'est pourquoi j'écrivais 'hébergement pro'
Bonjour,
Mon usage de Piwigo est amateur et essentiellement familial.
Je suis désolé de vous chagriner mais de fait, je fais partie de ceux qui ne mets pas à jour les différentes versions et les raisons sont multiples.
- Il m’est arrivé dans le passé de mettre à jour et de voir certaines fonctionnalités ne plus fonctionner, de mémoire, les fichiers pdf et les petits extraits vidéo, suite à certains plugins.
- Avec l’âge, je deviens « fatigué » de subir cette course à l’innovation, je rêve de stabilité, de ne plus me pencher sur des problèmes techniques qui me dépassent, de ne plus voir mon environnement changer.
- Le fait aussi de devoir réserver un certain temps, au calme, avec sauvegarde, peur de casser quelque chose, de devoir éventuellement restaurer. Le site fonctionne, alors pourquoi encore mettre à jour.
Ceci dit, je vous remercie pour le travail que vous faites. Je dois reconnaître que j’ai eu peu de problème avec piwigo, contrairement à certain cms
PS: je mets à jours ce we :-)
Bonjour
al.piwigo a écrit:
ddtddt a écrit:
Bonjour
poof65 a écrit:
Dans mon cas je suis hébergé sur un mutualisé ovh ........
C'est impossible d'avoir une version de php différente pour chaque site sur un seul hébergement mutu
....c'est pas vraiment vrais chez ovh tu peux avoir des versions de php différente sur un même abonnement après 5.6 et dans legacy donc tu peux monter en 7 pour certaine partie de ton hébergement
Il y a aussi docker qui embarque le PHP dans l'image officielle, et même la BDD si on laisse le fichier compose tel que proposé. Comme ça on reste à jour en permanence. Ceci dit il faut l'infra qui le permette : auto hébergement ou hébergement 'pro'.
sur un mutualisé t'est vraiment sur de toi ?
Sur mon mutualisé Ionos, la version php se spécifie sous-domaine par sous-domaine. Bien sûr il faut alors une organisation en sous-domaines et pas en sous-répertoires.
ddtddt a écrit:
Bonjour
poof65 a écrit:
Dans mon cas je suis hébergé sur un mutualisé ovh ........
C'est impossible d'avoir une version de php différente pour chaque site sur un seul hébergement mutu
....c'est pas vraiment vrais chez ovh tu peux avoir des versions de php différente sur un même abonnement après 5.6 et dans legacy donc tu peux monter en 7 pour certaine partie de ton hébergement
Il y a aussi docker qui embarque le PHP dans l'image officielle, et même la BDD si on laisse le fichier compose tel que proposé. Comme ça on reste à jour en permanence. Ceci dit il faut l'infra qui le permette : auto hébergement ou hébergement 'pro'.
Bonjour
poof65 a écrit:
Dans mon cas je suis hébergé sur un mutualisé ovh ........
C'est impossible d'avoir une version de php différente pour chaque site sur un seul hébergement mutu
....
c'est pas vraiment vrais chez ovh tu peux avoir des versions de php différente sur un même abonnement après 5.6 et dans legacy donc tu peux monter en 7 pour certaine partie de ton hébergement
poof65 a écrit:
Dans mon cas je suis hébergé sur un mutualisé ovh et j'ai 3 sites dessus (dont le piwigo)
Ils tournent tous sur php 5.6. Si je veux mettre a jour piwigo il faudrait que j'upgrade le php (simple), mais aussi que j'upgrade les autres applications en même temps, j'ai un interblocage.
C'est impossible d'avoir une version de php différente pour chaque site sur un seul hébergement mutu
Il faudrait que je prenne un 2e hébergement et que je fasse les migrations une par une mais flemme pour le moment
Très intéressant. On a un peu le même sujet sur piwigo.org : certaines parties du site fonctionnent en PHP 5. Si si. Le présent forum, à la date de ce jour (24 mars 2026) tourne en PHP 5.6 (au secours).
En 2020, le 1er mai pour être précis, on a subi une attaque majeure sur le site. L'avalanche d'attaques sur tous les fronts ne nous ont pas permis d'isoler l'attaque qui a fonctionné. On ne savait donc pas si c'était le forum, le gestionnaire d'extensions, la plateforme de traduction... qui avait permis l'intrusion d'un vil pirate.
Nous avons donc totalement changé l'architecture : chaque application est hébergée sur son propre VPS. Tout est cloisonné. Le VPS qui héberge le forum est donc en PHP 5.6 mais le gestionnaire d'extension est en PHP 8. Effectivement mettre en place une telle infrastructure n'est pas à la portée de tout le monde (et surtout pas d'un individu)
En tout cas, tu vas devoir dépasser ta flemme ;-) car PHP 5.6, à moins d'isoler les apps comme on le fait, tu ne sortiras jamais de l'impasse.
Katryne a écrit:
Je fais toujours une sauvegarde complète avant la moindre mise à jour.
C'est une bonne pratique. Et encore mieux si on a une sauvegarde automatique journalière par exemple.
Moi je recommande de synchroniser (en incrémental, sans suppression) les répertoires de données ("galleries", "upload" et "local") et d'avoir un dump complete de la base journalier et archivé par date. Oui ça double (au moins) le stockage nécessaire, mais c'est une vraie source de sérenité :-)
Katryne a écrit:
[...] suffit de restaurer, toujours via l'admin, la base et sa structure, pour remettre tout d’aplomb. Serait-ce possible d'implémenter un tel système sur un Piwigo ?
Il y a quelques années, on avait une fonction pour générer le dump de la base de données depuis la page de mise à jour. On l'a retiré. Ce n'était pas assez fiable. La génération d'un dump peut prendre davantage de temps que le temps maximal autorisé pour l'execution d'une page PHP par le serveur. C'est le même problème pour d'autres opération potentiellement très longue comme la sauvegarde du répertoire "upload" ou la restauration d'une base à partir d'un dump. Donc plutôt que de faire "moyen voire mal", on a préféré ne pas le faire directement dans Piwigo.
Dans mon cas je suis hébergé sur un mutualisé ovh et j'ai 3 sites dessus (dont le piwigo)
Ils tournent tous sur php 5.6. Si je veux mettre a jour piwigo il faudrait que j'upgrade le php (simple), mais aussi que j'upgrade les autres applications en même temps, j'ai un interblocage.
C'est impossible d'avoir une version de php différente pour chaque site sur un seul hébergement mutu
Il faudrait que je prenne un 2e hébergement et que je fasse les migrations une par une mais flemme pour le moment
C’est tellement simple et rapide que je fais toujours la mise à jour dès que je reçois la notification. Je n’utilise que très peu de plug-ins et si certains ne sont pas mises à jour immédiatement, en général cela va assez vite pour que cela ne me dérange pas.
Merci pour le boulot avec Piwigo, c’est assez remarquable.
nicolas a écrit:
Mon avis n'est peut-être pas représentatif mais tant pis je vous le donne quand même !
T'as raison, faut pas se gêner ;-)
Je suis totalement d'accord avec tout ce que tu as écrit SAUF :
nicolas a écrit:
[...] une nouvelle version qu'on a préparé pendant de longues semaines
LOL (sans vouloir froisser quiconque) : en général sur Piwigo, il y a 12 mois entre 2 versions majeures. On ne travaille pas dessus quelques semaines, mais... 12 mois. Pour les versions mineures, là c'est différent effectivement le processus est beaucoup plus court en temps.
D'ailleurs on essaie, entre 2 versions mineures, de minimiser les changements dans le code, dans l'espoir secret de limiter les bugs de régression. On corrige donc "à minima" en tentant de limiter l'impact des changements. Cela nous amène parfois à corriger différemment sur la branche stable et sur la branche de développement.
djom a écrit:
Ça me rassurerait de savoir que des gens travaillent sur la fiabilité du processus (points de reprise, etc.).
On peut travailler autant qu'on veut sur l'amélioration du processus de mise à jour (et c'est déjà plutôt bien ce qu'on a dans Piwigo), on ne coupera à devoir faire une sauvegarde de son Piwigo. Le principe même d'un bug, c'est d'être imprévisible. Si on pouvait le prévoir, on ne le laisserait pas :-) (il n'y a pas de bug injecté volontairement dans Piwigo, croyez-moi)
Si le processus de mise à jour comporte un bug (ce fut le cas sur la 13.4.0, de mémoire) alors la seule vraie solution était d'avoir la capacité de restaurer sa sauvegarde.
Achromep a écrit:
J’aimerai que les maj soient séparées en deux catégories : les maj de sécurité, indispensables, et les maj qui apportent ou améliorent les fonctionnalités que l’on devrait pouvoir ignorer un certain temps (dans l’esprit d’une Debian stable).
Cela existe "un peu". Si on trouve une faille vraiment très très majeure, on peut décider de sortie une 14.6.0 + 15.8.0 + 16.4.0 mais il faudrait vraiment que ce soit grave. Comme par exemple on trouverait que dans certaines conditions, un visiteur peut supprimer vos données. En dehors de cela, on ne corrige les failles que dans la branche stable en cours. C'est aussi pour pousser les utilisateurs à mettre à jour. On n'a pas vraiment les moyens de maintenir plusieurs branches stables.