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

[pmleconte]

Bonjour,

Après quelques tests supplémentaires, j'ai constaté qu'il n'est pas nécessaire d'aller interroger le xml, le numéro de la nouvelle version est mis à jour automatiquement dans la table updates par la fonction findupdates.

Concernant la fréquence du onAfterInitialise, c'est lancé après lancement d'un "application initialise method", ce qui ne nous renseigne pas trop. J'y ai donc mis un breakpoint et c'est appelé un peu tout le temps quand on est dans l'administration....

Concernant le plugin cupdater, en regardant dans le code, il me semble qu'il va lancer à chaque fois (suivant la fréquence demandée) le contrôle et l'envoi de message pour toutes les extensions à mettre à jour. Donc, si tu tardes un peu, tu risques d'avoir pas mal de rappels dans ta boite mail.

Pascal

[RobertG]

Merci Pascal,

En fait, voilà comment je procède.
Pour le déclenchement automatique et journalier de la vérification, j'utilise un fichier texte "lazydbbackup.upd" dans lequel j'ai l'horodatage de la dernière alerte (je gère la première fois en créant une valeur de -24 heures à la place du contenu du fichier à lire, ce qui forcera la première vérification).
Je vérifie si cette valeur est inférieure de plus de 24 h (86400 secondes) à l'heure actuelle, et si ce n'est pas le cas, je ne fais rien.
Sinon, je cherche un fichier texte d'update sur le serveur de mise à jour, je compare la version actuelle (en dur dans le fichier principal de LDB pour éviter de chercher dans la base), et si la nouvelle version est supérieure, je déclenche le mail d'alerte (si l'utilisateur n'a pas décoché l'option dans les paramètres).
Je mets à jour le fichier horodaté pour ne plus rentrer dans cette vérification avant 24 heures.

Utiliser les fichiers manifeste ou la base éviterait d'avoir à mettre la version en dur dans le fichier principal et de gérer un fichier texte sur le serveur de mises à jour pour le numéro de version, mais çà alourdirait certainement nettement le code.

Pour l'instant, je butte sur un problème de traduction de variable de langue pour le sujet et le corps du mail, les variables ne sont pas traduites, elles restent sous forme de chaîne.
J'imagine faire une erreur dans cette ligne, car le fichier de langue est bien lu à l'affichage du plugin :

$updsubject = JText::_('PLG_LAZYDBBKP_UPDATE_SUBJECT');

Je récupère PLG_LAZYDBBKP_UPDATE_SUBJECT au lieu de sa valeur !

[pmleconte]

Je récupère PLG_LAZYDBBKP_UPDATE_SUBJECT au lieu de sa valeur !

Les plugins n'ont pas le chargement du fichier language en standard, il faut le faire "à la main" : JPlugin::loadLanguage('plg_xxxx');

Pascal

[RobertG]

Merci Pascal, ça fonctionne à moitié, peut-être parce que l'appel aux fichiers de langue n'est pas où il faut ou construit comme il faut...
Testé sous Joomla! 3.8 et 3.9dev, les chaines sont bien traduites, je reçois les mails (testé en français seulement pour le moment).

Sous PHP 7.2, Joomla! 3.9 l'administration me renvie une page d'erreur d'encodage, et sous Joomla! 3.8.6, j'ai cette alerte :

Deprecated: Non-static method Joomla\CMS\Plugin\CMSPlugin::loadLanguage() should not be called statically in /home/www/***********/plugins/system/lazydbbackup/lazydbbackup.php on line 16

la ligne 16 déclare l'appel :

jimport('joomla.filesystem.folder'); // september 07 2012
jimport('joomla.filesystem.file'); // september 07 2012
JPlugin::loadLanguage('plg_system_lazydbbackup',JP ATH_ADMINISTRATOR);

Je présume donc que cet appel doit se faire avec une autre méthode que cette ligne brute, et pour l'instant, je n'ai pas trouvé comment.

Trouvé ! J'ai déplacé dans onAfterInitialise que j'ai passé en "Public" et c'est bon

[RobertG]

J'essaie d'éviter la nécessité de penser à changer la version dans le fichier principal à chaque modification, et j'ai créé une requête allant lire dans la table des extensions le champ "manifest_cache", mais je n'arrive pas à en extraire la valeur de la variable "version".

            $query->select('e.manifest_cache')
                ->from('#__extensions AS e')
                ->innerJoin('#__update_sites_extensions AS se ON se.extension_id = e.extension_id INNER JOIN #__update_sites AS s ON se.update_site_id = s.update_site_id')
                ->where('s.name = "LazyDbBackup Updates"');
            $db->setQuery($query);
            $row = $db->loadRow();

Je récupère bien dans $row le champ :

stdClass Object ( [name] => plg_system_lazydbbackup [type] => plugin [creationDate] => March 25, 2018 [author] => Robert Gastaud [copyright] => GNU General Public License version 2 or later [authorEmail] => **********@robertg-conseil.fr [authorUrl] => www.joomxtensions.com [version] => 3.9.9 [description] => PLG_LAZYDBBKP_XML_DESCRIPTION [group] => [filename] => lazydbbackup )

Il y aurait aussi le décodage direct du fichier manifeste du plugin, pour récupérer cette version...

[RobertG]

C'était trop simple !
J'utilisais déjà le json_decode...

$data = json_decode($row[0]);
$version1 = $data->version;

[RobertG]

Comme je le disais, il serait peut-être plus rapide de lire le fichier manifeste du plugin pour en extraire la version actuelle, et interroger le XML d'updates déclaré dans ce même manifeste, mais pour l'instant, je n'ai pas été fichu de retrouver quelles fonctions du core utiliser pour ça !

Idem pour récupérer la version dans le fichier XML d'updates. J'ai retrouvé et adapté ce code depuis le fichier install.php de com_installer, en remplaçant la variable "downloadurl" par "version" :

            jimport('joomla.updater.update');
            $update = new JUpdate;
            $url='https://updates.joomxtensions.com/lazydbbackup_xxxxxx_upd.xml';
            $update->loadFromXml($url);
            $package_url = trim($update->get('version', false)->_data);

            if ($package_url)
            {
                $new_version = $package_url;
            }

Mais $package_url revient vide, avec cette erreur, que j'interprète comme une lecture du fichier qui ne renvoie rien :

Notice: Trying to get property '_data' of non-object in /home/www/************/plugins/system/lazydbbackup/lazydbbackup.php on line 111

Quelqu'un aurait-il une idée de pourquoi apparaît cette erreur et comment corriger ce code ?

[pmleconte]

Bonjour Robert,

J'ai ce message si le nom de fichier est incorrect.....c'est quoi ce xxxxxx dans le nom ? en mettant https://updates.joomxtensions.com/lazydbbackup_upd.xml, j'ai bien la version 3.7.4 qui en sort.

Pascal

[RobertG]

Je ne voulais pas mettre l'URL du fichier de test !

Finalement, j'ai lu les deux fichiers avec du code PHP standard, et j'ai plus rapidement mes versions :

            $url='https://updates.joomxtensions.com/lazydbbackup_xxxx_upd.xml';
            $xml=simplexml_load_file($url) or die("Error: Cannot create object");
            $new_version = $xml->update[0]->version;
            //echo($package_version);
            $url=JPATH_SITE."/plugins/system/lazydbbackup/lazydbbackup.xml";
            $xml=simplexml_load_file($url);
            $version = $xml->version;

Maintenant, il faut que je compare les numéros de version, et "4.0.0" n'est pas considéré comme supérieur à "3.9.9", il va falloir que je manipule ces chaînes.

[RobertG]

Bien, je pense être arrivé à mon but !
La procédure est la suivante, pour le cas où d'autres voudraient utiliser une méthode similaire ou auraient plus simple à me proposer :

• vérification que le paramètre de demande d'alerte est à "1" ou forçage s'il est absent ;
• si le paramètre a été mis à "0", on ne fait plus rien ;
• si le paramètre à 1 ou absent , recherche du délai (24 h) grâce à un fichier texte dans lequel est inscrit le "strtotime" de l'instant de passage précédent ;
• si le délai n'est pas atteint et que ce n'est pas le premier passage, on ne fait plus rien ;
• si le délai est atteint, ou lors du premier passage dans le code, on peut lancer la récupération des numéros de versions sur le site de mise à jour et sur le serveur, dans les fichiers XML manifeste et de mise à jour ;
• suit une transformation des numéros de versions en nombres pour comparaison ;
• si une nouvelle version existe, un mail est envoyé avec le numéro de la nouvelle version en sujet du mail ; que le mail ait été envoyé ou pas, le fichier repère est mis à jour avec le "strtotime" actuel pour n'autoriser une nouvelle vérification que 24 h plus tard.

Il me reste à tester les deux versions PDO et MySQLi du plugin...

Merci de votre aide !

[RobertG]

Je me doutais bien qu'il y aurait un hic !
Je n'ai pas tenu compte de la version visée dans le champ "targetplatform" du fichier d'update, ce qui va peut-être m'obliger à utiliser la fonction findUpdates et donc à récupérer l'ID du plugin dans la base, ce que je voulais éviter...

[RobertG]

L'amélioration n'a pas été longue à faire. Récupération de la version de Joomla! avec JVersion et de celles définies comme cibles dans targetplatform. Lecture de chaque section "update" : si la première occurrence trouvée comme correspondant à la cible propose une version plus récente du plugin, le mail part. Cela implique que l'ajout des parties update du XML d'updates se fasse en début de fichier.
Et je viens d'ajouter dans le mail un lien direct vers la page de mise à jour.

Tests en cours qui nécessitent de bricoler les sites afin d'utiliser le nouveau code tout en modifiant à la baisse la version dans le manifeste du plugin sur le site. Avantage, sauf erreur, Joomla! n'utilise pas ce manifeste pour vérifier la version de l'extension, mais les infos en cache dans la base.

[RobertG]

Bon, ça a l'air de fonctionner. Sur deux sites de test, un 3.8.6 et un 3.9.0dev, j'ai bien reçu un nouveau mail signalant l'existence d'une mise à jour, 24 heures après les premiers.
Reste la question de savoir si 24 heures est trop court, sachant que les utilisateurs visés sont surtout ceux qui ne se connectent pas très régulièrement à l'administration de leur site et que, donc, il est important qu'ils puissent être rapidement informés en cas de correction de bug.

Je viens de faire la modif sur un site 4.0dev, je saurai dans 24 h si ça confirme le fonctionnement correct sur cette version aussi.