Symphony.

Hi all,

I need to be able to send the new user email address along with a plain text version of their password when they register (for a POST event to an API). This will also check that the email address isn't already registered within the API - so it kind of needs to infiltrate the validation as well.

Where's the best place to do this in the members extension?

Is there somewhere I could slip a function that has access to these two pieces of information at the relevant time?

I need to do pretty much the same thing when a user changes their password (i.e. modify the user via the API, rather than create them). So I'll need to do the same thing there - I have an event for updating the user (at the moment a very basic event that updates the entry) - so would just need to know how to alter it to get this step somewhere in the middle of it.

Cheers

Combining members extension with member forms with the email template manager (ETM) does it for me. The ETM in on the integration branch for 2.3. Also see the wiki for members.

Cheers Glen, that looks like a very handy extension, wish I'd come across it at the beginning of the project!

Have to ask though - how does it help with the above? Feel like I'm missing something…

The member activation enforces a unique email address or user name (depending on configuration). There's also an event for handling registration with xslt form example in the forms. See the Big Picture.

Actually now that I think about it more - the API (which is external, btw) shouldn't ever need to double-validate the email address. As the only way that my API could hold an account under a certain email address is if they'd registered to the site with that address. So scrap the validation infiltration.

The important thing I need to do, which I still seem to be missing from what you're pointing at (maybe we're crossing wires?) is take the plain text password that the user input during registration and pass that along to the API. But obviously I only need to do that if the registration succeeds (else the API would receive every failed registration without knowing it didn't validate).

In essence I have a function, for arguments sake: customAPI($user_email,$user_password) that needs to be run at the exact point that the members extension deems all the fields to be valid and still has access to the plain text version of the password.

I have a page set up for receiving the validation response for registration (for ajax) - but at that point the password is hashed which is no good to me.

Does that add any clarity, or am I mostly confusing myself?

Using the members extension, I get all of the functionality you've described and I never un-hash the password. You're beyond me. Sorry!

However, a separate point that may be useful to those that use the members extension for the function you've described. Use the members.form-register.xsl form provided in the member forms. I use this form as a utility that I is referenced by a form I've created that tests for events/members-create[@result='success'] (members-create is the event I created to match the big picture event that generates an email).

The members extension only provides this functionality on-site. I need that data both on-site and in an external API - so no the members extension doesn't provide this functionality.

I really just need to know where this stuff is done so I can run an extra function as part of the process…

I'm also not looking to unhash the password (which is impossible), I need to send the raw password when it's being processed, before it's hashed and stored, at the point where the fields are being deemed valid and stored. I don't have control over this process, but the reason it needs to be not hashed is because it will be hashed in a very specific way when stored in the API's user database.

With a registration process, you would be using a regular event, and so the password will be in the POST array for that field. The hashing takes place when the field is invoked by the event.

If you need to do something after the member is saved, then you can still access the POST array after the event has run. Just customise the event, and add to the end of the trigger function.

If you have any specific API requirements, I can help you out if needed.

Ah, of course. Apologies to anyone that's read this - as you're right designermonkey, it's a standard event, not actually tied to the members extension (it's been a few months since that part of the site has been worked on so my memory wasn't very fresh).

Stumbling block: I've never messed with custom events before (only just got to grips with basic custom datasources), I've just jumped into the registration event and there isn't actually a __trigger function in there - I'm guessing there's a default trigger function in a class somewhere that's used? The load function is there, that calls the trigger function.

If you have a very basic shell of a custom event that I could borrow then I'd be very happy to take a look. What I need to do is no more complicated than sticking the function I mentioned above (customAPI($useremail,$userpassword) into the event, as the nuts and bolts are handled by a custom extension for the API. The only condition that needs to be met for it to fire is that the fields validate and the section successfully created/edited - in case that helps as to where I need to stick it within the trigger function.

I have had a good look around but the only resources relating to what I'm after are out of date, and only loosely related any way :(

I've just jumped into the registration event and there isn't actually a __trigger function in there

Not sure exactly how this relates or if this different between versions, but in a Symphony 2.2 site I have the following right at the bottom of event.members_new.php:

protected function __trigger(){
    include(TOOLKIT . '/events/event.section.php');
    return $result;
}

This is 2.3.1 to be precise.

Funnily enough I actually tried exactly what you posted above after coming across a tutorial from brendo (one of the things I found the was unfortunately out of date) and it seemed to stop the event from working.

Here's what I see (XXX replaces anything private, but not relevant): https://gist.github.com/nathanhornby/8590803d5a0289f9febd

Replace public $ROOTELEMENT = 'members-update-account'; on this line: https://gist.github.com/nathanhornby/8590803d5a0289f9febd#file-example-2-3-event-L7

with const ROOTELEMENT = 'members-update-account';

Tutorial data is defo out of date.. Jens flagged it up and the bottom of the wiki for a posting to multiple sections from an event tutorial and I spotted it needed this change. The above works for my events after this change.

Hi @moonoo2

Excellent, so I seem to be making some progress!

Only issue I'm facing now is that the function I'm trying to run in the __trigger is undefined. Which means that the extension that I've created that houses this function is obviously not being executed before the event.

I'm assuming this is a delegate thing - I'm currently using 'delegate' => 'DataSourcePreExecute', as much of the calls are from datasources that build their own XML. I could just duplicate the function in the event, but I'd rather keep things centralised for obvious reasons.

It's a little unclear what I should change/add to the delegate so that the above functionality remains, but so that the event can also access the function - any thoughts?

tl;dr: How do I call a function in an extension from my event?

I think Events fire before Datasources are rendered to the page no? which means you wouldn't have access to the DS itself...

I think this is the case, but not 100% sure.. my mind is Symphony mush today.

Ah, I wouldn't need access to the DS from the event, just the function in the extension.

My custom datasources also need access to the extension functions, which is taken care of with 'DataSourcePreExecute' - I was hoping there was something similar for events.

I've used SymQl extension to get to the data before now... there are other methods which Marco has pointed out, but SymQl was easy'ish to understand and it did what I needed.

I'll see if I can find Marco's post in a bit.

Got we're typing quick here :)

Ok a re-think on what you need then.. brb

This is a last hurdle on a project, so keen to get it out of the way :p

Ok so here's an example of a small extension which subscribes to a new delegate I placed in the XMLimport fork to trigger an email if a successful import was triggered.

And this is my fork where I've created the new delegate which gets fired if the import is successful.

So NotifyMembers to create a new delegate in your extension, and listen for it in your own function. That might send you on the right track.