News:

SMF 2.1.4 has been released! Take it for a spin! Read more.

Main Menu

Integration Hooks for CMS bridge

Started by lat9, February 07, 2013, 11:37:24 AM

Previous topic - Next topic

lat9

The current integration hooks (integrate_change_member_data and integrate_register) that support user registration synchronization between SMF and other entities make the assumption that the information provided by the user is acceptable by the other entity.  For example, in the account registration, the assumption is made that the email address and username selected that are OK for SMF are also OK for the other entity.  It might be, for example, that the email address is already defined in the "other" database so that the registration or change is not acceptable.  The same is true for the change_member_data hook; the assumption is made that if the data is OK for SMF that it's OK for everyone.

My request is to either make a modification to the current integration hooks or to define new integration hooks to allow the "integration" to identify to the SMF core code that there is an issue with the data specified, allowing a message to be issued to the user so that the data will be acceptable by both databases

Suki

Welcome.

It depends on who is handling the registration, the hook sends the data to your app, over there you can validate the data against your own DB and fire an error if the mail already exists on your own DB.

Thats why the hook is for really, to validate the provided data before adding the user to the SMF DB.
Disclaimer: unless otherwise stated, all my posts are personal and does not represent any views or opinions held by Simple Machines.

Kindred

As Suki said, you should be able to pass the data, using the integration function and then perform your own checks on it before sending back a "success" or "failed"

also, if your outside app is to be the primary application, then you would use the SMF API instead of the integration functions (which assume that SMF is the primary and is just passing the data to the other application)
Слaва
Украинi

Please do not PM, IM or Email me with support questions.  You will get better and faster responses in the support boards.  Thank you.

"Loki is not evil, although he is certainly not a force for good. Loki is... complicated."

lat9

As you can see from my number of posts, I'm an SMF newbie so I appreciate your patience.

What call(s) can I use in an SMF integration_hook to cause the page's processing to return to the data-gathering phase?  For example, if I hook 'integrate_register' I want to be able to perform some additional data checks and cause the processing to return (with appropriate message) to the data-gathering phase of the registration process without an SMF user record having been created.

Arantor

There should be a validation hook for registration too.

It's hard to give you any specifics without having specifics about what you're trying to do. I'm not convinced that the way you're approaching it is ideal anyway...

lat9

I'm trying to create an SMF-to-Zen Cart bridge.  I've already created (and released) a Zen Cart-to-SMF bridge and I'm trying to 'complete the loop'.  The functionality I'm aiming for is enabling a store-owner to have an SMF installation associated with their Zen Cart shop.  Note that a store-owner might have an existing customer-set (with existing email addresses) at the point in time that they choose to add the SMF bridge.

Using my ZC->SMF bridge, when an account is created in the ZC side an account is created in the SMF side using the same credentials.  When the ZC customer changes their email address, that email address is checked in both the ZC and SMF databases to make sure there's not a duplicate.  When the ZC customer changes their password, the password is also changed in the SMF side.

In the SMF->ZC bridge, when an account is created in SMF I want to be able to check and see that the email address doesn't already exist in the ZC side before I create the ZC account.  When a user changes their email address in SMF, I want to be sure that the email address doesn't already exist in the ZC store before making the update. 

In both of those cases, I'd like to use the SMF 'integration hook' method to provide this functionality.  For the account registration, the registerMember function has the following code fragment:
// Call an optional function to validate the users' input.
call_integration_hook('integrate_register', array(&$regOptions, &$theme_vars));

// Right, now let's prepare for insertion.
$knownInts = array(
'date_registered', 'posts', 'id_group', 'last_login', 'instant_messages', 'unread_messages',
'new_pm', 'pm_prefs', 'gender', 'hide_email', 'show_online', 'pm_email_notify', 'karma_good', 'karma_bad',
'notify_announcements', 'notify_send_body', 'notify_regularity', 'notify_types',
'id_theme', 'is_activated', 'id_msg_last_visit', 'id_post_group', 'total_time_logged_in', 'warning',
);

That is, upon return from the integration hook call, the function proceeds to complete the database update with the user's information ... no return value is checked.  Are there SMF functions that I can use to issue a message to the customer if the email address already exists in the ZC database (and also cause the processing to return to the template/data gathering phase for the account registration)?

Arantor

Ah.

There isn't a hook for validation of registration details with a third party system prior to actually performing the registration, at least not in 2.0. It was proposed for 2.1 and I believe it's been accepted when it was provided as a patch. (This is the part I get confused with, since I have three related code bases in my head >_< Two of them have this hook, the third does not.)

Changing email details... change_member_data is probably the hook you want to look at.

lat9

Thanks for the response, Arantor.  I found that integration hook (change_member_data), but it's got the same issue for me (i.e. there is no way for my code to 'stop' the change process).

Arantor

Well, there is one way... you force it with a fatal error.

But it's not really designed for your use case, because you and everyone else like you wants to go through this farcical process of *syncing* things. (It's nothing personal, honestly. I'm just fed up of trying to deal with people who are trying so hard to make it more complex than it needs to be.)

Simplify the process. Don't sync it. Call it from the other code. There is absolutely no need to sync this stuff, ever. All the bridge needs to do is pick one of the two as a master and always defer to it.

lat9

Thanks for the insight, Arantor; I agree with your assessment as I do have a bad habit of over complicating things.

Advertisement: