Avertir les utilisateurs d'une mise à jour d'extension ?

**pmleconte** · 25/03/2018, 10h49

Bonjour Robert,

Cela suppose que les utilisateurs soient enregistrés sur ton site, or, ce n'est pas le cas (je le sais, j'ai tout téléchargé et ton site ne me connait pas). Je pourrais avoir moi-aussi le souci car "mes modules" sont en libre-service.

Pascal

**RobertG** · 25/03/2018, 11h01

Merci Pascal, mais si tu regardes le plugin d'Akeeba (system/akeebaupdatecheck), il est capable de vérifier le serveur de mise à jour et de comparer les versions, mais en se basant sur le code du composant qui est utilisé pour afficher la présence de mise à jour dans la page principale du composant.
Un seul des sites dont je m'occupe avait ce plugin activé, et il n'est pas déclaré sur le site Akeeba (pas de download ID).

Je pense donc qu'il doit être possible de créer un plugin soit générique dans lequel mettre en paramètre l'URL du XML de mise à jour (ou les URL des XML pour gérer plusieurs extensions), soit dédié à telle ou telle extension, avec recherche une fois par jour et envoi du mail d'info.

**lomart** · 25/03/2018, 11h14

Bonjour Robert,

Dans le cas de LazyDbBackup, il suffirait de lire, au moment de la sauvegarde, le dernier numéro de version dans un fichier sur ton site puis le comparer à celui en cours. En cas de différence, le site peut envoyer un mail à l'administrateur avec le message que tu as prévu. Cette méthode fait que tu n'as pas besoin de gérer une liste d'utilisateur.
Plus délicat avec les modules de Pascal ou les miens car il n'ont pas d'exécution périodique. C'est aussi moins grave qu'une sauvegarde et un dysfonctionnement se voit

**RobertG** · 25/03/2018, 11h27

Merci Loïc, j'y ai pensé, mais l'inconvénient est le temps entre deux sauvegardes et l'éventuelle non-réactivité du ou des super utilisateurs (je le vis avec le site dont j'ai parlé et dont le gestionnaire ne réagit pas aux mails de mises à jour d'Akeeba backup... alors que je ne suis qu'intervenant exceptionnel pour ce site qui a été mon premier "vrai" site Joomla!).

Il n'est pas question de gérer une liste d'utilisateurs sur un de mes sites, mais que le plugin détecte la mise à jour de l'extension et qu'il envoie un mail au(x) super utilisateur(s) déclarés dans le site, c'est ainsi que fonctionne le plugin Akeeba, ou encore celui de Joomla! pour la mise à jour système (auquel je ne viens de penser que parce que je reçois à l'instnat une nfo pour un site dont je m'étais occupé il y a quelques mois et où j'avais laissé la case cochée pour être informé.

**lomart** · 25/03/2018, 12h01

l'éventuelle non-réactivité du ou des super utilisateurs

Sauf aller physiquement lui tirer les oreilles, je ne vois pas de solution à ce souci

l'inconvénient est le temps entre deux sauvegardes

C'est la périodicité que le superadmin a choisi. Donc on e prévient que la dernière sauvegarde n'est pas bonne !

Non testé, il y a ceci https://extensions.joomla.org/extens...rity/cupdater/

**pmleconte** · 25/03/2018, 12h01

J'avais mal compris ton problème. Je pensais que tu souhaitais informer tes utilisateurs actuels de la nécessité de mettre à jour, donc, réponse : pas faisable en l'état.

Pour LazyDBBackup, comme il est "tout automatique" et s'exécute tout seul, il suffirait peut-être de rajouter un

Code:

JUpdater::getInstance()->findUpdates($eid, $cache_timeout, $minimum_stability);

comme tu peux le voir dans administrator/components/com_installer/models/updates (ligne 260), avec $eid = no de composant.

Je vais faire quelques tests en fin d'après-midi si tu n'as pas trouvé la solution d'ici là (il ne pleut pas, je vais en profiter....)

Pascal

**RobertG** · 25/03/2018, 14h26

Merci à vous deux !

L'idéal serait en effet d'intégrer cette fonctionnalité à LazyDbBackup, histoire de simplifier les choses, le mieux étant de pouvoir différencier mise à jour simple et mise à jour critique...

LDB utilise déjà un fichier enregistrant l'horodatage de la dernière sauvegarde, je pourrais envisager le même principe pour la recherche de mise à jour, ou voir si je pourrais enregistrer cette info dans la base et ne chercher que si un délai de 24 heures, par exemple, s'est écoulé depuis la précédente. De plus LDB possède déjà une fonction d'envoi de mail.
Utiliser aussi la fonction "findUpdates" serait en effet ne pas réinventer la roue. Je verrai si j'en suis capable.

Cupdater est ce que je cherchais, mais nécessite d'être installé et paramétré en plus, il ne pourrait être intéressant qu'intégré (et adapté) dans un package avec LazyDbBackup.

Envoyé par lomart Voir le message

Sauf aller physiquement lui tirer les oreilles, je ne vois pas de solution à ce souci

En effet !

J'ai beaucoup de mal avec les gens qui traînent dans de tels cas, ou lorsqu'ils vous posent des questions mais oublient de tenir compte de la répons...

**RobertG** · 25/03/2018, 15h20

Après une première analyse, si je ne me trompe, si je voulais me passer de findUpdates, il me faudait :

trouver le numéro ID de l'extension "update_sites_extensions.extension_id" en faisant une jointure entre les tables "#__update_site" et "#__update_sites_extensions" en cherchant dans update_site le "name", à savoir "LazyDbBackup Updates" ;
utiliser un repère (fichier comme pour la sauvegarde ?) pour décider si je dois ou non lancer la recherche, sachant que le champ "last_check_timestamp" de"update_site" est alimenté par le core donc pas utilisable, et éviter que plusieurs mails soient envoyés chaque jour ;
si la recherche doit être faite, récupérer dans les infos "manifest_cache" la version actuelle du plugin ou interroger le fichier XML du plugin sur le serveur du site pour la connaître ;
ouvrir l'URL du XML de mise à jour pour y chercher la nouvelle version... et comparer ;
si une mise à jour doit être faite, envoyer le mail et mettre à jour le repère.

Maintenant, si je veux avoir une chance de pouvoir utiliser findUpdates, il faut que je comprenne comment il fonctionne, trouver l'ID de l'extension pour lui passer et savoir si une mise à jour existe , mais avoir quand même un repère indépendant du timestamp que le core enregistre pour faire appel ou non à cette fonction.

Edit : en fait, les points 1 et 2 resteraient nécessaires même si je peux utiliser findUpdates.

Est-ce que mon analyse vous semble correcte ?

**lomart** · 25/03/2018, 16h26

Je ferais plus simple. Avant chaque envoi ou réalisation de la sauvegarde, je teste le n° de version. Tu as toutes données (fichier xml, n° de version). Tu envoies un mail si dépassé avec un message d'erreur spécifique récupéré dans le XML ou un changelog pour motiver le superadmin

**RobertG** · 25/03/2018, 16h58

C'est sûr que ce serait plus simple, mais avec comme inconvénient de pouvoir laisser passer plusieurs jours et deux sauvegardes vides avant que l'utilisateur soit informé pour la première fois. Une sauvegarde qui ne contient que la structure, ce n'est pas l'idéal !
Il faut aussi que je prenne en compte les utilisateurs qui ne reçoivent pas la sauvegarde par mail : il faudra alors chercher l'adresse d'un super utilisateur.

Si Gerald Berger ne m'avait pas prévenu de l'absence de sauvegarde des données dans cette version MySQLi 3.7.3 (un double slash de neutralisation de ligne de code au mauvais endroit, j'avais dû être déconcentré par autre chose...), je ne m'en serais pas aperçu avant un bon moment, ne faisant pas attention au poids du fichier joint, et j'imagine aussi ceux qui ne reçoivent pas de mail et conservent les sauvegardes sur le serveur. Tout utilisateur de cette version MySQLi qui n'a pas rouvert son administration et été informé de la présence de la maj 3.7.4 continue à faire des sauvegardes inutiles, c'est pourquoi je cherche une solution pour ne pas devoir attendre que l'utilisateur se connecte à son administration si un tel incident se reproduit.

Si je ne me trompe, actuellement le plugin ignore sa propre version, il faut donc que je la retrouve et la compare avec celle de la nouvelle en analysant (en l'état actuel) deux fichiers XML pour en extraire ces infos.
Il faudrait que je pense à l'ajouter sous forme de variable au fichier PHP principal et à la modifier à chaque fois.
Pour le délai de nouvelle recherche, je pourrais facilement utiliser le même type de fichier que celui qui sert de repère pour les sauvegardes. Une simple duplication de code et changement de nom de variables, plus un peu de ménage suffirait.
Idem pour l'envoi du mail d'information, en me basant sur la fonction actuelle.

Pour le moment, je laisse décanter...

**pmleconte** · 25/03/2018, 17h55

Bonsoir,

En faisant quelques essais, j'ai effectivement trouvé que le problème est de connaître son id et sa propre version (un peu de SQL), mais pas seulement....

La fonction findUpdates retourne juste "true" s'il y a une mise à jour, et après il faut ramer un peu pour trouver la nouvelle version : accès au site de mise à jour et lecture du XML.

Comme toi, je suis parti de ton plugin pour lancer périodiquement la recherche (car elle n'est pas anodine au niveau durée...) et, si mise à jour, il faut garder la version du module afin de ne pas envoyer des informations de mise à jour à chaque fois (j'ai un peu saturé ma boite mail

)

Pascal

**RobertG** · 25/03/2018, 18h23

Merci Pascal !

Si j'intègre la version en cours sous forme de variable dans mon fichier principal, que mon fichier repère me dit que je dois tester parce que l'intervalle est atteint ou dépassé, et que j'interroge alors le fichier d'update pour connaître la nouvelle version (ou un simple fichier texte ne contenant que le numéro de version en cours), je sais illico si je dois envoyer le mail d'alerte. Donc je vais peut-être plus vite que findUpdates, puisque je n'ai pas à interroger la base.

Et si ma comparaison signale une nouvelle version, j'informe l'utilisateur et je mets à jour mon repère de vérification pour que le test ne se fasse que 24h plus tard.

Ce que je ne sais pas, par contre, c'est à quelle fréquence le plugin est sollicité par le core.

Pour le moment, j'ai prévu la modification du XML (et des variables de langue) pour permettre à l'utilisateur de ne pas recevoir les alertes et la procédure d'envoi du mail de signalement.

**lomart** · 26/03/2018, 08h47

Bonjour,

Pour info, j'ai testé https://extensions.joomla.org/extens...rity/cupdater/
elle fonctionne bien et en français. Elle reprend des méthodes de Akeeba Update pour la gestion de la périodicité (voir doIHaveToRun).

**RobertG** · 26/03/2018, 08h54

Merci pour ces infos !

Avertir les utilisateurs d'une mise à jour d'extension ?

Avertir les utilisateurs d'une mise à jour d'extension ?

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Annonce

Partenaire de l'association