Bonjour k5, merci pour ce retour,
je viens de corriger l'extension pour sa configuration du dépôt Git. À présent, une fois placée dans le dossier plugins/, l'archive zip de l'extension se décompressera bien automatiquement dans un sous-dossier fsrmp/. Par défaut cela se faisait dans le dossier plugins/ (probablement suite à des changements de nom, et mauvaises reconfigurations). Je pense que c'est la raison de l'échec de la mise à jour 1.2.0 -vers-> 1.2.3.
Pour corriger cela, j'ai remis à zéro la configuration du dépôt SVN/Git.
J'ai testé avec succès une mise à jour de 1.2.0 (dont le dossier plugin était bien nommé 'fsrmp') -vers-> 1.2.3.e
En espérant que ce sera bon pour tout le monde.

Bonjour @ddtddt,

Je ne sais pas, car je n'ai encore qu'une 2.8.6 sous la main.
Je pense qu'essayer n'apporte pas beaucoup de risque.
- Le plugin, enregistre une configuration dans la base de données (d'après le modèle fournis par le simili-plugin skeleton). Donc il devrait même se désinstaller proprement.
- Il y a une commande exec avec un risque d'injection modéré (Maintenant que j'y pense, au pire l'entier configuré n'est pas limité `find /path/to/gallery -type f -mtime 999999999999999...999999999999999999`, tout de même !). Le `find` ne peut faire que de la lecture pour constituer une liste.
- Je ne suis pas satisfait du nom du répertoire compressé téléchargé... en fait sous-jacente la question "À quoi est-il important que le nom du répertoire du plugin corresponde dans le code ? dans un dépôt git ? svn ?". Il faudra peut-être que je fasse quelques corrections en ce sens, voire modifier le nom du dépôt git (repository). (Ce sont mes débuts)

En espérant avoir répondu de manière satisfaisante

Ok merci TOnin, A tester :)

je pense que oui, 2.8.6 le fait, pourquoi 2.9 ne le ferait plus ? d'autant que cela apparait dans la deuxième capture d'écran de la partie design. http://fr.piwigo.org/releases/2.9.0#design

Ce qu'il me manque c'est le filtre adapté pour sélectionner les dernières images modifiées sur le système. Il est vrai que cette situation ne se produit que lorsque les images sont hébergées et éditées par un autre logiciel sur le même serveur. À moins qu'il existe un système de synchronisation qui écrase les images du serveur d'hébergement à partir des terminaux alimentant le serveur en images, et qui conserverait la date de modification issue des terminaux...

Bonsoir,

avec presque 60000 photos, je ne fais pas de synchronisation à la légère (même rapide). Surtout que l'idée est de le faire pour la centaine de photos dont les mots clés auraient été actualisés. Mais cela concerne des répertoires/catégories éparpillés. Comment synchroniser les méta-données en un clin d’œil ?

Avec la gestion par lot, y aurait-il un moyen de sélectionner les photos récemment modifiées sur le système au cours des dernières 24 h ?
Sur Linux il suffit de lancer la commande suivante pour avoir la liste de ces fichiers :
find path/to/gallery -type f -mmin -1440
find path/to/gallery -type f -mtime -1

les lignes retournées par la commande sont du type :
path/to/gallery/subpath/to/picture.jpg

explication
"-mmin -1440" = "modifié depuis moins de 1440 min" (60*24=1440)
"-mtime -1" = "modifié depuis moins de 1 jour"

S'il fallait développer un plugin, ma première idée serait de récupérer les noms picture.jpg via un exec($cmd, $list) puis de construire une requête MySQL avec WHERE file IN (...). J'ai un peu peur de la longueur potentielle de la liste qui se trouverait entre parenthèses.

Alors... je me lance ou ça existe déjà ?

Version de Piwigo: 2.8.6
Version de PHP: 5.6.32
Version de MySQL: 5.5.5-10.1.29-MariaDB
URL Piwigo: http://