Plugin syntax question

Earlier in the year I posted inquiring about how to do an LDAP integration for my users to log in to Manager. http://modxcms.com/forums/index.php?topic=49996.0

OpenGeek suggested a plugin attached to the events ’OnUserNotFound’ and ’OnManagerAuthentication’, and linked to a sample code snippet that used this method. https://gist.github.com/421232.

Anyway, I finally got around to doing this last week. Using the code example, I got a plugin to work with our LDAP directory. It looks up users in the directory if the OnUserNotFound event is triggered, and if they are found and their credentials successfully authenticate against LDAP, a new MODx user is created and saved.

As I worked through the process of translating the concepts from the example into something that would meet my specific needs, I ran in to a few concepts that I didn’t fully grasp. I’m hoping someone can clarify these.

1. In the OnUserNotFound case of the switch statement, there is this block of code:


First, I’m not at all sure what that first inner line ($user = & $scriptProperties[’user’];). Is that just something specific to the code example, or is it an essential step? Presumably the [’user’] info is getting passed in from somewhere...

I understand the next few lines, defining a new user object & a new profile.

Then the last two lines... it looks like the $user object is being set as the output of this event, and then the event is being manually stopped? Is that correct?

Is this so that the $user variable can be made available to the next event that uses this plugin (OnManagerAuthenticate)?? I’m not exactly clear on how that hand-off works, from OnUserNotFound to OnManagerAuthenticate.

Quote from: jrotering at Nov 29, 2010, 10:44 AM

if ($userexists) {
                    $user = & $scriptProperties['user'];
                    $user = $modx->newObject('modCrowdUser');
                    $user->set('username', $username);
                    $up = $modx->newObject('modUserProfile');
                    $user->addOne($up);
                    $modx->event->_output= $user;
                    $modx->event->stopPropagation();
                }

First, I’m not at all sure what that first inner line ($user = & $scriptProperties[’user’];). Is that just something specific to the code example, or is it an essential step? Presumably the [’user’] info is getting passed in from somewhere...

Right, the user in the scriptProperties array is a reference to the user object created and passed as a property to the event. In this case it’s not necessary any longer, as the event invocation was altered to get a user object from the event output...

Quote from: jrotering at Nov 29, 2010, 10:44 AM

Then the last two lines... it looks like the $user object is being set as the output of this event, and then the event is being manually stopped? Is that correct?

Is this so that the $user variable can be made available to the next event that uses this plugin (OnManagerAuthenticate)?? I’m not exactly clear on how that hand-off works, from OnUserNotFound to OnManagerAuthenticate.

The stopPropagation() call prevents any additional Plugins from being executed on the event, so yes, it is being manually stopped. And there is no hand-off between those events; each is an isolated invocation and the data is only common because the events are invoked from the same script, so it passes the user you created in OnUserNotFound as a property of the OnManagerAuthenticate event.

Quote from: OpenGeek at Nov 30, 2010, 08:35 AM

The stopPropagation() call prevents any additional Plugins from being executed on the event, so yes, it is being manually stopped.

Does this mean then that more than one plugin *can* be invoked against the same event? If so, is there any way to dictate which order they are executed in?

My plugin has evolved to the point where it is doing two logically separate things with OnUserNotFound - 1) checking to see if a "not found" username is actually the ’fullname’ or ’email’ of an existing user, and if so getting that user (& their proper username), 2) looking up truly new ("not found") users in LDAP, & adding them as new users if their credentials validate. It would be nice to separate this out into different plugins, but they’d need to run in the right order.

Quote from: jrotering at Nov 30, 2010, 09:47 AM

Does this mean then that more than one plugin *can* be invoked against the same event? If so, is there any way to dictate which order they are executed in?

Yes. The ’priority’ field, ascending (0 means it goes first.)

Now I see it. I wasn’t looking under System Events (although I don’t know why not, it makes total sense that that’s where it’d be).

Thanks!