Bonsoir,
Je viens de m'apercevoir que l'appel au trigger login_success ne fonctionne plus avec le plugin UAM. J'utilise ce trigger pour initier des actions automatiques lors de la connexion des utilisateurs et, depuis je ne sais quand, ces actions ne sont plus effectuées.
J'ai installé le plugin Event tracer pour vérifier les appels aux triggers et voila le résultat:
login_success 0 calls
50 UAM_LoginTasks
UAM est le seul plugin actif et utilisant ce trigger qui est bien interprété mais pas appelé comme cela devrait l'être. Comme cela fonctionnait bien avant (quand ?), je me demandai s'il n'y aurait pas un problème avec ce trigger. Mais comment le déterminer ?
J'ai essayé de faire un mini-plugin qui affiche un echo sur l'appel à login_success mais, là aussi, rien ne se passe.
Une idée ?
Hors ligne
est-ce que ça peut venir du fait qu'il est éxécuté (en partie) dans méthode qui elle même est dans un trigger ? (try_log_user)
essayes de remplacer
function try_log_user($username, $password, $remember_me) { return trigger_event('try_log_user', false, $username, $password, $remember_me); } add_event_handler('try_log_user', 'pwg_login', EVENT_HANDLER_PRIORITY_NEUTRAL, 4); function pwg_login($success, $username, $password, $remember_me) {
par
function try_log_user($username, $password, $remember_me) { $success = false;
la partie 'auto_login" n'est pas impactée par ça
Hors ligne
En modifiant le code comme proposé, le trigger semble refonctionner. Mon echo de test est exécuté même si Event tracer m'indique toujours le contraire :
login_success 0 calls
50 LoginTasks
Hors ligne
bon, alors il va falloir trouver ce qui bloque
pourtant des triggers imbriqués j'en ai dans BatchDownloader et ça marche très bien (sur la page de génération tout découle de "loc_end_index")
même il y a dans quasiment tous les plugins
Hors ligne
Là je ne comprends pas. Voici le code du plugin de test que j'utilise pour tester le trigger :
<?php /* Plugin Name: login_success test Version: 1.0 Description: test Plugin URI: Author: Eric */ if (!defined('PHPWG_ROOT_PATH')) die('Hacking attempt!'); if (!defined('TEST_PATH')) define('TEST_PATH' , PHPWG_PLUGINS_PATH.basename(dirname(__FILE__)).'/'); // Test trigger call // ----------------- add_event_handler('login_success', 'LoginTasks'); function LoginTasks() { Logs('OK'); } function Logs($var1) { $fo=fopen (TEST_PATH.'log.txt','a') ; fwrite($fo,"======================\n") ; fwrite($fo,'le ' . date('D, d M Y H:i:s') . "\r\n"); fwrite($fo,$var1 ."\r\n") ; fclose($fo) ; } ?>
Tout ce qu'il y a de plus simple donc. Si je garde le code d'origine dans functions_user.inc.php, rien ne se passe. Pas de fichier log.txt créé et le trigger affiche 0 calls. Si je remplace le code avec ce que tu as proposé, le log.txt se créé bien mais le trigger affiche toujours 0 calls.
Event tracer qui ne remonte pas la bonne info ? Quoi qu'il en soit, il y a un os avec login_success.
Hors ligne
J'ai compris ce qui clochait : Finalement le trigger fonctionne correctement avec le code d'origine mais j'avais plusieurs autres plugins qui y faisaient appel simultanément (ex: prune_history et Register_FluxBB en plus de UAM).
Pourtant, j'avais positionné les priorités de manière à ce qu'il n'y ait pas de chevauchement (1 pour UAM, 2 pour Prune_History et 5 pour Register_FluxBB) lors de l'exécution et j'avais désactivé tous les plugins avant de tester "login_success test". Mais j'ai dû avoir un problème de cache et/ou de template compilé qui a mis le bazar dans mes résultats de tests.
Donc j'ai résolu le problème en positionnant un priorité 1 pour l'appel au trigger login_success par UAM, priorité 10 pour Prune_History et Priorité 20 pour Register_FluxBB. Comme cela l'appel au trigger fonctionne bien.
Pourquoi les priorités initiales ne suffisaient pas ? Mystère...
Hors ligne