on_event Yes, after_event No ?
Permalink
Hi Friends
I know how to fire an event on_user_add , on_user_update etc, every events is called before the actual action RIGHT? The main disadvantage is we don't get the updated info from the passing variable ie $ui.
But I need to know How can I write a function after that action
ie
after_user_add, after_user_update etc..
* I have a little knowledge in OOP.
--Purpose--
If so I can write code without touching the core files and communicate with Campaign Monitor
Thanks in advance.
Manup
http://www.pixelmargin.com/
Did more than 1000 C5 CMS sites
I know how to fire an event on_user_add , on_user_update etc, every events is called before the actual action RIGHT? The main disadvantage is we don't get the updated info from the passing variable ie $ui.
But I need to know How can I write a function after that action
ie
after_user_add, after_user_update etc..
* I have a little knowledge in OOP.
--Purpose--
If so I can write code without touching the core files and communicate with Campaign Monitor
Thanks in advance.
Manup
http://www.pixelmargin.com/
Did more than 1000 C5 CMS sites
Both of those user-events (on_user_add, on_user_edit) are run after the database records have been inserted/updated so the $ui object passed to those events is already the "new one".
Hi Mainio
There are two Cases Frontend(Customer Profile) and Backend(Dashboard)
In Frondend
During Signup - I couldn't get the Custom User attribute values in passing $ui, but getting default Attribs(uName, Email and Password).
During Profile Update - When print_r the $ui , I can see the last updated/previous values not the Currently Updated value.
In Backend
During Add a User - Same Issue as Frontend
During Update a User - Working fine because we usually updating the user Attrib values as Ajax , then hit Update User Button
Hopes this is a good explanation.
Thank You
Manup
There are two Cases Frontend(Customer Profile) and Backend(Dashboard)
In Frondend
During Signup - I couldn't get the Custom User attribute values in passing $ui, but getting default Attribs(uName, Email and Password).
During Profile Update - When print_r the $ui , I can see the last updated/previous values not the Currently Updated value.
In Backend
During Add a User - Same Issue as Frontend
During Update a User - Working fine because we usually updating the user Attrib values as Ajax , then hit Update User Button
Hopes this is a good explanation.
Thank You
Manup
Ok, yes this is good explanation.
Looking at the code, yes I can see that actually the attributes are updated/added after the user object is inserted/updated, so you're 100% correct on that one.
Also, I'm not able to find any events that are run after those attributes are added/updated so you might need to fork the core code.
One possible solution would be to launch "on_attribute_save" event at the AttributeKey class (/concrete/models/attribute/key.php) during the call to saveAttribute() method. However, this might get performance-heavy if this event is abused and not treated with respect.
Other possibility would be to add the event after each case where you need to get user object after the attributes are updated. This would need a bit more digging into code to find all the spots but in the long run this might be better option for performance reasons.
Looking at the code, yes I can see that actually the attributes are updated/added after the user object is inserted/updated, so you're 100% correct on that one.
Also, I'm not able to find any events that are run after those attributes are added/updated so you might need to fork the core code.
One possible solution would be to launch "on_attribute_save" event at the AttributeKey class (/concrete/models/attribute/key.php) during the call to saveAttribute() method. However, this might get performance-heavy if this event is abused and not treated with respect.
Other possibility would be to add the event after each case where you need to get user object after the attributes are updated. This would need a bit more digging into code to find all the spots but in the long run this might be better option for performance reasons.
Thank you.
Thats a Good Idea...
But we still need the after event listener , right?
Hopes in the next version of Concrete5 will include the facility..
Again, Thank you so much for replying
Manup
http://www.pixelmargin.com
manup.rav@gmail.com
Thats a Good Idea...
But we still need the after event listener , right?
Hopes in the next version of Concrete5 will include the facility..
Again, Thank you so much for replying
Manup
http://www.pixelmargin.com
manup.rav@gmail.com
"But we still need the after event listener , right?"
Depends on your situation. Could you explain a bit what you're aiming to do so that I could see your need a bit more clearly?
Now all I see is what you've tried to accomplish with the user object but I don't see what were the needs for this behind than to "communicate with Campaign Monitor".
I can see you need to pass something to Campaign Monitor, probably the whole user with updated attributes. If there was an event for attribute update, you could replicate this behavior e.g. by defining an attribute where the "communication" would happen, let's say hidden attribute on the very bottom of your attributes list "campaign_monitor_integrate". Then when you would notice in the attribute update event that this attribute is updated, you would be sure that by that moment all the others are also updated.
But as said, depends on your needs what you need to do. I'm just trying to think about an option here with minimal core changes. :)
Depends on your situation. Could you explain a bit what you're aiming to do so that I could see your need a bit more clearly?
Now all I see is what you've tried to accomplish with the user object but I don't see what were the needs for this behind than to "communicate with Campaign Monitor".
I can see you need to pass something to Campaign Monitor, probably the whole user with updated attributes. If there was an event for attribute update, you could replicate this behavior e.g. by defining an attribute where the "communication" would happen, let's say hidden attribute on the very bottom of your attributes list "campaign_monitor_integrate". Then when you would notice in the attribute update event that this attribute is updated, you would be sure that by that moment all the others are also updated.
But as said, depends on your needs what you need to do. I'm just trying to think about an option here with minimal core changes. :)
After a customer signup with a Subscribe checkbox (User Attribute - is_subscribed), in our Event function the method $ui->getAttribute('is_subscribed') returns null, that means its not setting the value as TRUE.
when customer Update his Profile with unchecking the 'is_subscribed' the event handler still have 'is_subscribed' TRUE
when customer Update his Profile with unchecking the 'is_subscribed' the event handler still have 'is_subscribed' TRUE
Ok, so you want to handle subscriptions of the people to Campaign monitor, now I understand!
Yes, this could be done 100% as I described.
Why you're experiencing what you are (the function returning null) is how the process works in c5:
1. Add/updated user
2. Launch event on_user_add / on_user_edit
3. You're grabbing into the event function (no attributes set / updated at this point)
4. Update all user attributes (all attributes set / updated at this moment)
If you just do the change I suggested, you can pretty easily follow the changes for attribute "is_subscribed" because every time that is updated/added, your event function will trigger.
Only addition that I would make to my initial suggestion would be also to add another event (e.g. "on_attribute_delete") to the AttributeValue object's delete() function because that is called if the attribute is cleared which I believe might happen for checkbox-attributes.
Yes, this could be done 100% as I described.
Why you're experiencing what you are (the function returning null) is how the process works in c5:
1. Add/updated user
2. Launch event on_user_add / on_user_edit
3. You're grabbing into the event function (no attributes set / updated at this point)
4. Update all user attributes (all attributes set / updated at this moment)
If you just do the change I suggested, you can pretty easily follow the changes for attribute "is_subscribed" because every time that is updated/added, your event function will trigger.
Only addition that I would make to my initial suggestion would be also to add another event (e.g. "on_attribute_delete") to the AttributeValue object's delete() function because that is called if the attribute is cleared which I believe might happen for checkbox-attributes.
Again thank you.
I already did it when an attribute changed....
I already did it when an attribute changed....
I am having similar issues as on_user_update as well as on_user_attributes_saved do not include the new data when triggered... This seems an error?
Did anyone ever find a workaround?
Did anyone ever find a workaround?
