Effectivement, maintenant ça fonctionne. En fait ca fonctionnait depuis le début (j'avais essayé avec loc_begin au début), mais comme je ne voyais pas mon printf, je pensais que cela ne marchait pas.

Par contre je ne comprend pas pourquoi avec le loc_end je peux récuperer les $_POST des autres bouttons submit?

dans cat_modify.php quand le formulaire est soumis (test sur $_POST['submit']) la page est redirigée (vers elle meme) après la sauvegarde

donc vous ne voyez jamais votre printf("Get POST!");
mettez un die; à la place et vous verrez que ça marche

ensuite mettez votre code de traitement à la place de printf("Get POST!"); et ça sera bon

Oui je comtais faire comme ca. Je peux faire autrement si cela pose un problème. Mais dans mon cas actuel, j'ai tout supprimé, plus de prefiltre, je cherche juste à recupérer la variable $_POST du submit ... mais j'ai l'impression que cela se passe ailleurs ...

je comptais utiliser celui de la page

Je m'y remet un peu après une petite pause. Je dois faire quelque chose de faux pour le moment. Je tente de récupérer la variable $_POST avec un trigger ... mais elle est toujours vide.

J'ai un peu regardé dans le plugin META et l'ai un peu instrumentalisé avec des printf, chez eux ca marche sans problème.

Pourtant ma fonction est on ne peux plus simple pour le moment:

add_event_handler('loc_end_cat_modify', 'get_post_data');

function get_post_data(){
  if (isset($_POST['submit'])){
    printf("Get POST!");
  }
  else {
    printf("Post empty!");
  }
}

Dans tous les cas, et quoique je fasse $_POST est vide ....

Ok, j'i été un peu bête de ne pas penser à regarder dans admin/cat_modify.php ...

Du coup nouvelle question ...
Si je modifie le formulaire d'entrée pour les categories, et ajoute des champs à CATEGORIES_TABLE,
je vais devoir modifier cat_modify.php, en particulier entre entre les lignes 115-120

 $data = array(
    'id' => $_GET['cat_id'],
    'name' => @$_POST['name'],
    'comment' =>
      $conf['allow_html_descriptions'] ?
        @$_POST['comment'] : strip_tags(@$_POST['comment']),
    );

En faisant cela, je me rend incompatible avec les futures évolutions de piwigo, à moins de faire à chaque upgrade de piwigo un merge entre mes fichiers et les votres. Cela n'est pas vraiment le but d'un plugin ...
Il y a t'il une autre solution ?

Une autre solution, que je souhaiterai éviter, serait d'avoir un forumlaire séparé pour ces propriétés de catégorie supplémentaires, avec une table séparée dans la base de données. Mais si je pouvais éviter cela ...

Allez, on continue. Donc pour ajouter des champs à la table, cela ne devrait pas trop poser de problèmes.
en suivant l'exemple Skeleton. Je vais peut être même les ajouter directement à partir de phpmyAdmin. Par contre je me pose des questions sur le nom de la table elle même ...

- j'ai trouvé dans le fichier piwigo-structures-mysql.sql le nom 'piwigo_categories' pour la table qui m'intéresse. Pourtant tous les accès à cette table dans les fichiers php semblent se faire par le nom de table 'CATEGORIES_TABLE'. Dans phpmyAdmin, la table s'apelle phpwebgallery_categories (du nom de l'ancien piwigo) ..... Quelque chose m’échappe là ....

- second point: je ne trouve pas où se trouve la requête pour updater cette table après avoir soumis les modifications depuis le formulaire de cat_modify.tpl

Merci encore pour vos réponses !