Accéder à une fonction dans un plugin

[jfque]

J'ai créé un plugin "finder" qui fonctionne correctement au moment de l'indexation.
Je voudrais maintenant pouvoir mettre à jour l'index quand une donnée est modifiée mais je n'arrive pas à "entrer" dans le plugin.

Le plugin s'appelle "produits".
Son namespaces est :

namespace Joomla\Plugin\Finder\Produits\Extension

La classe est :

final class Produits extends Adapter

Dans le controller de mon composant, j'ai :

use Joomla\Plugin\Finder\Produits\Extension\Produits;

Mais si j'essaie d'atteindre une méthode dans le plugin (n'importe laquelle), avec :

Produits::onFinderAfterSave('com_produit.form', $oResponse, $isNew);

j'ai une erreur : ERR_HTTP2_PROTOCOL_ERROR (qui n'est - apparemment - pas une erreur 500).

Je ne comprends pas pourquoi je ne peux pas accéder aux fonctions qui se trouvent dans le plugin. Merci d'avance à quiconque aurait une explication.

[roland_d_alsace]

Hello.
Un plugin est fait pour traiter des évènements généré par un composant.
Le composant lance l'appel à un évènement d'un groupe de plugin.
Ces évènements ont interceptés par les plugins actifs de le groupe concerné, et qui traitent le dit évènement.

Tu peux bien sur créer tes évènements onQuelqueChose selon tes besoin mais aussi tes groupes de plugin (cas des plugins non prévus/gérés par le framework de Joomla et nécessaires à tes composants)
Le protocole est bien défini voir : https://docs.joomla.org/J4.x:Creatin..._for_Joomla/fr § utiliser un plugin dans votre code

Si ce n'est pas ce que tu veux faire mais appeler une fonction "commune", utilisée par ton plugin et quelque par dans un ou plusieurs autres endroits de tes extensions,
cette fonction il faut la définir par exemple dans un helper ou un model de ton composant dont dépend le plugin, ou encore dans une librarie qui sera installé avec le le composant (et éventuellement avec le plugin),
mais pas la définir dans le plugin.

Et le plugin et tes extensions devront faire appel à cette fonction à l'emplacement commun où tu l'auras placée.


Bon dev.

[jfque]

Merci pour la référence, mais ça reste encore très obscur pour moi...
Je crois que je pourrais y arriver si ce plugin appartenait à mon composant mais ici il s'agit d'activer un évènement se trouvant dans un plugin (finder) lié à la recherche avancée (com_finder) mais depuis un autre composant (que j'ai créé), de préférence depuis le Controller de celui-ci.
Je n'arrive pas à mettre les pièces ensemble.

[roland_d_alsace]

Je n'ai jamais programmé d'action pour finder, mais j'ai rapidement regardé.

Inspire toi de ce que fait com_content à la publication d'un article.

Quand on enregistre un article :

• le model général (/libraries/src/MVC/Model/AdminModel.php) utilisé par com_content déclenche l'évènement onContentAfterSave.
• Ensuite le plugin de contenu finder (/plugins/content/finder/finder.php ligne 41) intercepte cet évènement et déclenche les évènements onFinderAfterSave.

Dans la logique de Joomla, com_finder pourrait être remplacé par un autre composant d'indexation/recherche.
On passe donc par un intermédiaire, un plugin "finder" pour com_content qui lance les plugins du groupe 'finder' de com_finder

Si tu veux lancer directement les plugins de finder
C'est cette dernière manip ((/plugins/content/finder/finder.php lignes 43 à 46)) qu'il te faut faire dans ton composant :

 use Joomla\CMS\Factory;
 use Joomla\CMS\Plugin\PluginHelper;
 .
 .
​ .
 PluginHelper::importPlugin('finder'); // selection du groupe de plugin
 Factory::getApplication()->triggerEvent('onFinderAfterSave', [$context, $data, $isNew]); 

en définissant bien sûr :

• $context : ton contexte (string) (exemple 'com_content.form' à la publication d'un nouvel article sinon 'com_content.article' au traitement batch)
• $data : tes données (object),
• $isNew (boolean) à true ou false s'il s'agit d'un insert ou d'un update

Et normalement le lancement des plugins, c'est le boulot de ton model, à l’enregistrement d'un item, pas vraiment celui d'un contrôleur.
Car un enregistrement peut être déclenché par une autre méthode d'un model (traitement batch par exemple) et pas uniquement par une méthode particulière d'un contrôleur.
C'est donc à la méthode d'enregistrement de l'item (généralement nommée store) du model (qui gère ce type d'item) de lancer les plugins du groupe et contexte adéquats.

Bon dev.

[jfque]

Grand merci pour ton aide. C'est la pièce qui me manquait pour comprendre le fonctionnement !
Il me reste encore un problème à régler parce que la table que je dois indexer n'a pas une PK appelée "id" mais "idproduit" et ça me donne une erreur Mysql : unknown a.id field.
Il faut que je trouve où sont traités

$this->itemAccessChange($row);
$this->reindex($row->id);

[roland_d_alsace]

Comme dit je n'ai jamais programmé pour finder.
Ton code :

$this->itemAccessChange($row);
$this->reindex($row->id);​ 

Il est où ?

Il me semble que si on utilise la classe Table (anciennement JTable) du framework, on peut définir un index principal de nom différent de id pour la table en question.

Sinon il est certainement aussi possible de gérer un mappage dans ton plugin.

[jfque]

Le code en question se trouve dans le plugin finder, dans la méthode onFinderAfterSave.
La piste de la classe Table semble prometteuse. Je vais essayer d'en savoir plus.

[roland_d_alsace]

Concernant la classe Table, j'ai rapidement regardé.

On trouve les infos dans la classe mère en /librairies/src/Tables/Table.php c'est au niveau des paramètres du constructeur que l'on défini le nom de la clé primaire.

Dans ton constructeur qui hérite de Table

use Joomla\CMS\Table\Table;
  use Joomla\CMS\Factory;

  /**
  * Template Field class
  *
  */
  class TableProduit extends Table
  {
 .
.
​.
function __construct() {
  parent::__construct('#__produit', 'id_produit', $db);
  }
.
.
. 

Mais vu que l'on ne passe pas la classe ou son nom en paramètre au plugin, je vois pas comment com_finder pourrait utiliser ceci.

[roland_d_alsace]

En fait effectivement la classe Table n'est pas utilisée et à priori avoir un autre nom de champ que 'id' en index primaire semble assez complexe à faire.

Ton plugin redéfini la classe mère 'Adapter'

et si tu te balades dans celle-ci (en /administrator/components/com_finder/src/Indexer/Adapter.php),

en particulier les méthodes que tu appelles justement (itemAccessChange en ligne 811 qui appelle getStateQuery ligne 664),

tu te rends compte qu'il n'est pas possible de définir un autre nom d'index primaire que 'id' sans redéfinir dans ton plugin la plupart des fonctions définies dans la classe mère...
...mais ce n'est pas impossible.

Mais apparemment il n'y a pas que cette contrainte du nom de l'index primaire, il faut aussi la jointure sur #__categories via le champ catid et la champ access qui doivent être présents dans la table à indexer si on veut utiliser les méthodes définies dans la classe mére Adapter.

[jfque]

Oui, c'est ce que je craignais. J'ai regardé les tables générées par différents composants et, avec J4, toutes les clés primaires sont toujours appelées 'id', même avec des composants de chez Akeeba où il avait pourtant l'habitude d'utiliser d'autres intitulés pour les clés primaires (par exemple, ats_tickets_id).