[RÉGLÉ] Enregistrement d'un paramètre de plugin

[RobertG]

Bonjour,

A la fin du code d'un plugin, je cherche à enregistrer l'instant de fin pour le comparer lors des prochains passages et savoir si le code doit de nouveau être exécuté :

 $dateToday = time();
$this->params->set('lastrun', $dateToday);

"lastrun" est un champ caché (type "hidden").
Alors que $this->params->get() me donne bien les informations enregistrées dans les paramètres du plugin dans la base, "lastrun" n'est pas modifié et conserve la valeur précédente (vérifié en modifiant manuellement cette valeur.
J'en déduis que ma façon de procéder est erronée.
Que dois-je faire à la place ?

Merci de votre aide !
Robert

[RobertG]

Bonjour,

Pensant donc que j'étais en cause, j'ai fait une recherche et trouvé que le plugin actionlogs utilise aussi un champ "hidden" pour enregistrer l'heure de son dernier nettoyage. J'ai donc cherché le code et trouvé le même

$this->params->set('lastrun', $now);

J'ai donc remplacé le mien par celui-ci (si le délai entre deux purges n'est pas atteint, on sort, sinon on enregistre l'heure et on exécute le code), mais ce champ n'est toujours pas enregistré dans la base, ce qui fait que restant à sa valeur par défaut, 0, il est impossible de sortir et le code est utilisé, inutilement, à chaque fois.

J'ai oublié de préciser que les autres paramètres modifiables dans la gestion du plugin sont bien enregistrés lorsqu'on enregistre le plugin.

Pour compléter : voici le début de la fonction :

 public function ebpurge()
{
$frequency = (int) $this->params->get('freqnc') * 3600 * 24 ; // nettoyage tous les x jours
$lastdel= (int) $this->params->get('lastrun',0); // date du dernier nettoyage
$datetrt = ($lastdel + $frequency); // date du futur nettoyage
$now = time();
// comparer la date actuelle avec la date de la précédente suppression : si elle n'est pas supérieure à la date précédente plus le nombre de jours de fréquence on sort
if ((abs($now - $lastdel) < $deleteFrequency) && ($lastdel > 0))
{
return;
}

// Update last run status
$this->params->set('lastrun', $now);

$TraceFile = JPATH_SITE .'/administrator/logs/delfiles.log';

[RobertG]

J'ai tenté d'utiliser ce code sur un autre plugin : pas plus d'enregistrement de ce paramètre caché "lastrun" !

[RobertG]

Bon, en forçant la mise à jour du champ params du plugin par une requête sur la base, les choses se sont réglées.

Cela dit, si quelqu'un peut m'expliquer pourquoi les modifications des autres champs sont automatiquement enregistrées mais pas celle de ce champ masqué, ça m'intéresse !

[RobertG]

Bonjour,

Autre question : y a-t-il autre chose que "onAfterRender" ou "onPrepareContent" qui ne déclencherait pas le code du plugin à chaque changement de page du site ? Même si on sort immédiatement lorsque le délai pour le nettoyage suivant n'est pas atteint, il faut aller chercher, inutilement dans la plupart des cas, les valeurs à comparer.

[dolmenhir]

Bon, en forçant la mise à jour du champ params du plugin par une requête sur la base, les choses se sont réglées.

Cela dit, si quelqu'un peut m'expliquer pourquoi les modifications des autres champs sont automatiquement enregistrées mais pas celle de ce champ masqué, ça m'intéresse !

J'ai absolument pas mis le nez là-dedans, mais à chaud je chercherai la procédure qui se charge de les enregistrer pour comprendre pourquoi ton champs en est exclu.
Il y a peut être une règle dans le nommage des champs, ou la présence d'un attribut/paramètre spécifique, ou son positionnement par rapport aux autres...

[roland_d_alsace]

Hello.

Pour ma part j'utilise régulièrement les champs de type hidden dans mes configurations pour mes tâches cron qui doivent s’exécuter en séquence et bien sur hors session,
ou pour savoir dans la configuration générale de mes composants si un composant dépendant ou un plugin est installé, pour cacher ou pas les champs de configuration de ces extensions facultatives dans la configuration générale du composant de base.

Il me semble effectivement que j'ai aussi eu des problèmes comme ceux que tu rencontres.

J'ai donc mon "petit framework" et je fais mes écritures / lectures dans les config.xml par une fonction qui me permet d'écrire dans n'importe quelle extension :

public static function get_param_component($PExtension_Name='',$Pparam='' ,$Pdefault=''){
 jimport('joomla.application.component.helper'); // Import component helper library
 if($PExtension_Name==''){
  $PExtension_Name=self::Component_Name();
 }
 $params = ComponentHelper::getParams($PExtension_Name);
 if($Pparam==''){
  return $params;
 }else{
  $Lparam=$params->get($Pparam,$Pdefault); // Get an individual parameter
  return $Lparam;
 }
}

public static function set_param_component($tabparam,$PExtension_Name='') {
 $app=JFactory::getApplication();
 if(!is_array($tabparam))return false;
 if($PExtension_Name==''){
  $PExtension_Name=self::Component_Name();
 }
// Load the current component params.
 $params = JComponentHelper::getParams($PExtension_Name);
// Set new value of param(s)
 foreach ($tabparam as $Pname => $Pvalue){
 $params->set($Pname, $Pvalue);
 }

// Save the parameters
 $componentid = JComponentHelper::getComponent($PExtension_Name)->id;
 $table = JTable::getInstance('extension');
 $table->load($componentid);
 $table->bind(array('params' => $params->toString()));

// check for error
 if (!$table->check()) {
  $app->enqueueMessage($table->getError(),'ERROR');
  return false;
 }
// Save to database
 if (!$table->store()) {
  $app->enqueueMessage($table->getError(),'ERROR');
  return false;
 }
 return true;
} 

Concernant ta 2ème question, pour éviter de lancer +ieurs fois des actions qui ont déjà été faites j'ai +ieurs méthodes selon les besoins :

Par exemple en utilisant une constante (valable dans une même instance, donc fait à chaque appel de page) :

Fonction vérifiant si un composant est présent du type :

public static function ComposantPhocaGalleryIsInstalled(){
 if(!defined('GSKIPHOCAGALLERYINSTALLED')){
  if ( ! file_exists( JPATH_ROOT . '/components/com_phocagallery/phocagallery.php' ) ) {
  define('GSKIPHOCAGALLERYINSTALLED',false);
 }else{
  define('GSKIPHOCAGALLERYINSTALLED',true);
 }
}
 return GSKIPHOCAGALLERYINSTALLED;
} 

Ou alors une variable de session (valable pour toute le session, donc tant que le navigateur n'est pas fermé) :

public static function CtrlInfoLicenceDejaFait($tabParams){
if(!is_array($tabParams)) return false;
$app = JFactory::getApplication();
if(array_key_exists('num_lic',$tabParams) && $tabParams['num_lic'] != ""){
if($app->getUserState('gskititres.ctrlvaliditeligne.num_lic.'.$tabParams['num_lic'],'') == "ok"){
  // on ne fait qu'1 seule fois par session le contrôle de ce numéro de licence par API sur le site de la Fédération
  return true
 }
 return false;
} 

Tu peux aussi essayer de mieux cibler l'event avec un plugin de type user et onUserAuthorisation ou onUserAfterLogin,

Mais je préfère l'une des 2 méthodes précédentes.

@+

[RobertG]

Merci à vous deux,

Roland, tu confirmes donc que pour que les valeurs de champs hidden soient enregistrées, il faut le forcer (moi par une requête sur la base, toi avec $table->store()), alors que les autres valeurs, modifiées dans le paramétrage du plugin, s'enregistrent automatiquement lorsqu'on sauvegarde celui-ci.

Je veux bien comprendre que lorsque le plugin est activé par un autre événement les paramètres n'ont pas à être enregistrés, mais j'ai eu beau sauvegarder le plugin pour les tests, en forçant ainsi son fonctionnement et l'exécution du code, jamais le champ lastrun n'a été sauvegardé tant que je n'ai pas ajouté la requête de mise à jour des paramètres du plugin.

Pour ce qui est du déclenchement de la fonction de purge, Tuan (de Joomdonation) m'a proposé 4 événements Event Booking, celui qui est le plus simple à tester est onEventDisplay qui se produit lorsqu'un visiteur affiche un événement sur le site, mais je testerai aussi celui de validation d'une inscription, ce qui sera moins fréquent, le but étant d'effacer les données plus vieilles d'un mois, a priori.

Au fait, j'ai omis de préciser que c'est une version pour Joomla! 4 que j'étais en train de mettre au point.

[RobertG]

Bien,

J'ai tenté d'utiliser $table->store() mais certainement mal, je suis donc resté à mon utilisation de requête. Je suis resté à onEventDisplay pour son déclenchement.

Le plugin est maintenant fonctionnel en local, il va me falloir le tester sur une copie du site que j'ai mise sur mon serveur avant de l'installer sur le site de production. Dans la mesure où il s'agit de supprimer des données dans la base et des fichiers, je serre les fesses !