2017-03-31 1 views
0

J'ai créé un plug-in à cet endroit moodle/local/redirectafterlogin avec la structure suivante:observateur d'événements Moodle ne se déclenche pas dans le plugin locale

redirectafterlogin/ 
├── db 
│   ├── classes 
│   │   └── observer.php 
│   └── events 
│    └── events.php 
└── version.php 

version.php:

defined('MOODLE_INTERNAL') || die(); 

$plugin->version = 20170333; 
$plugin->requires = 2015111000; 
$plugin->component = 'local_redirectafterlogin'; 

events.php:

defined('MOODLE_INTERNAL') || die(); 

    $observers = array(
     array(
      'eventname' => 'core\event\user_loggedin', 
      'callback' => 'local_redirectafterlogin_observer::user_loggedin', 
     ), 
     array(
      'eventname' => 'core\event\user_loggedout', 
      'callback' => 'local_redirectafterlogin_observer::user_loggedin', 
     ), 
    ); 

observateur.php:

class local_redirectafterlogin_observer 
{ 
    public static function user_loggedin(core\event\base $event) 
    { 
     $event_data = $event->get_data(); 
     var_dump($event_data); 
     die(); 
    } 
} 

En cache a été effacé beaucoup de temps et le numéro de version a été heurté aussi mais le rappel n'est jamais appelé!

  1. Qu'est-ce qui ne va pas, pourquoi le rappel n'est pas déclenché?
  2. Comment puis-je déboguer des événements (existe-t-il un moyen dans Moodle de voir les événements dispatchés)?

Répondre

0

C'était une erreur de structure! J'ai mis le dossier classes contenant observer.php dans le dossier db! Après avoir déplacé le dossier classes à la racine du plugin comme suit, c'est ok, l'observateur est déclenché!

Structure qui est ok:

redirectafterlogin/ 
├── classes 
│   └── observer.php 
├── db 
│   └── events.php 
└── version.php 
0

J'ai fait l'expérience que var_dump ou sortie stdout n'est pas trigggert. Comme "debug" rapide j'utilise file_put_contents à un fichier journal temp

0

Je ne pense pas que le chargement automatique des classes sera capable de trouver votre classe d'observateur.

Essayez d'ajouter au début du fichier de classe d'observateur:

namespace local_redirectafterlogin; 

Ensuite, changez events.php à:

'callback' => 'local_redirectafterlogin\local_redirectafterlogin_observer' 

(Vous pouvez également réduire considérablement le nom de la classe, il est maintenant namespaced). Assurez-vous de remplacer le numéro de version pour recharger le fichier events.php. Vous voudrez peut-être reconsidérer le nom de votre plugin, car la redirection n'est pas autorisée depuis un gestionnaire d'événements, car cela causerait beaucoup de problèmes.

+0

Le but de ce plugin est juste de rediriger vers une page 'utilisateur/edit.php' lorsque certains champs de profil supplémentaires ne sont pas remplis. Pourquoi dites-vous que la redirection n'est pas autorisée dans le gestionnaire d'événements? À mon avis, l'événement 'core \ event \ user_loggedin' est distribué pour effectuer ce genre d'opération? N'est-ce pas? –

+0

Les événements sont souvent expédiés en cours de traitement (par exemple, vous pouvez avoir un plugin qui crée un nouvel utilisateur, puis les enrôle sur le cours) qui déclencherait un événement 'user_created' puis, plus tard, un événement 'user_enrolment_created' Sinon, un script qui crée plusieurs comptes utilisateur génère plusieurs événements). Les événements peuvent également être gérés par plusieurs gestionnaires. Si vous autorisez un gestionnaire d'événements à rediriger en partie ce traitement, le site peut être dans un état très endommagé. – davosmith