Registering participant/member to external site. Recommended approach?

[mhawksey]

We have a Drupal/Civi configuration. As part of this when members signup for an event we'd like to register them on an external WordPress multisite site. We have full control of the WP site so creating custom hooks/code isn't a problem. The thing I'm trying to get my head around is the best way to expose or hook the data from civi. We plan to implement SAML using our existing Drupal/Civi install as an IdP. The three ways I've thought this could be done are:

• When someone log in from the WordPress site we could hook into the authentication to call the civi contacts API. My concern with this approach is if logging in from Drupal we'd miss the hook.
• If there was a hook in civi we could use to push something to the wordpress site (I've made custom APIs in Wordpress before).
• A cron job that queries event/group contacts and refreshes the WP relationship table

   
Any thought from the community on the best approach and/or anything similar has been tried?
Thanks
Martin

[JonGold]

I haven't worked with SAML - but if I understand this correctly, I'd take approach #2, writing a Civi extension that made use of the civicrm_post hook.  Something like:

Code: [Select]

function myextension_civicrm_post($op, $objectName, $objectId, $objectRef) {
  if $objectName == 'Participant' && $op == 'create') {
    //another if statement here to filter only to appropriate events
    //call the Wordpress API here, using the $objectRef properties to populate your query
  }
}
Also, I don't know if this is even vaguely relevant to your use case, but there's also this: https://github.com/TechToThePeople/ldapcivi

[totten]

I would encourage you describe the desired architecture in general terms. One might loosely use the terms:

• "Shared data-store" - All the data lives in one data-store, and all applications must read data from that system. LDAP is generally intended for use as shared data-store (where different apps can read/write the username/password/email/full-name using a standard interface). However, this only works if all the apps know how to integrate with the shared data-store (e.g. LDAP). ldapcivi is a pretty neat way to integrate Civi with LDAP.
• "One-off data integration" - When the user signs up, copy fields from Drupal/Civi to WP -- and then treat these as entirely separate systems.
• "Single-master data-synchronization" - The change always originates in one system and propagates to the other. e.g. Any change to "first name" must originate in Drupal/Civi and then propagate to WP.
• "Multi-master data-synchronization" - Changes may originate in either system. e.g. The user may update his "first name" using either Drupal/Civi or WP.

The architectures above are loosely sorted from simplest (fewest moving parts, fewest proprietary parts) to most complex/difficult (more moving parts, more custom code).

When you know which architecture you need, it's easier to decide how to implement the various bits.