Sync hooks: Enable sharing of arbitrary data

Any news on this? Current version provides checkboxes for user-defined profile fields however values don't cross over.

Problem is in the following segment:

Line 95:
    // We store email/name if they changed. We want to wait with doing
    // anything else until the changes are saved locally.
    foreach (variable_get('bakery_supported_fields', array('mail' => 'mail', 'name' => 'name')) as $type => $enabled) {
      if ($enabled && isset($array[$type]) && $account->$type != $array[$type]) {  //CONDITIONS ARE NOT MET
        $_SESSION['bakery'][$type] = $array[$type];  //AND THIS VALUE IS BLANK
      }
    }

To fix it removed of the conditional and loaded the user/profile information...

    // We store email/name if they changed. We want to wait with doing
    // anything else until the changes are saved locally.
    global $user;
    profile_load_profile($user);
    foreach (variable_get('bakery_supported_fields', array('mail' => 'mail', 'name' => 'name')) as $type => $enabled) {
        $_SESSION['bakery'][$type] = $user->$type;
    }

- applied patch #6 (currently at line 102)
- as user 1, entered user account edit on master node
- changed the user picture, on save:

fatal error: Call to undefined function profile_load_profile() in /var/www/drupal/sites/all/modules/bakery/bakery.module on line 105

that happens even if the User Picture field is not ckecked as a "supported profile field" in Bakery configuration.

_{Apache/2.2.11 (Ubuntu) PHP/5.2.6-3ubuntu4.4 with Suhosin-Patch (so far SSO seems to work)
Content Profile module
Ubuntu 9.04}

If I may, I'd like to propose a hook-based general solution to sharing data with Bakery. The master side would invoke implementation of its own hook for defining what data to share and slaves would do similar to respond to incoming data. Modules that need to sync their own data could implement these hooks. Thoughts?

Proposal, two hooks, one for transmitting data and the other for receiving and acting upon.

Update on master:
1) bakery_user_presave() invokes 'bakery_transmit_fields' hooks (or whatever, I don't care about the hook name) passing the $account object
2) A module implements the hook, returning an array of unique keys with the updated values
3) bakery_user_presave() fills $_SESSION['bakery']
3) bakery_user_update() is left the same as it is, populating the payload, mixing, and signing
4) slave receives POST and in bakery_eat_stroopwafel_cookie() invokes 'bakery_receive_fields' passing it the array of fields
5) a module on slave implementing the receive hook takes the array of keys and values and for its keys does its own update

Thoughts:
- Ideally, the transmit hooks should only pass back fields that have actually changed on the master
- This methods relies, obviously, on sharing data only through updating the user account (user_save)

Here's a patch implementing the proposal in #9. One big change is rather than just dumping $cookie['data'] into $_SESSION['stroopwafel'] at the top level I leave it within 'data' to protect against any hook implementations overriding certain elements.

I may follow up with a patch or test module implementing role sharing #[547524]

Edit: This is for Drupal 7. I'll implement in Drupal 6 later.

Updated patch sends $edit and $category to transmit hooks.

Also for D6.

There is some test code in http://drupal.org/node/547524#comment-2913504 for sharing roles that you can see how the hooks work.

Bakery could implement these hooks on behalf of the user and profile modules, which would replace the existing sync implementation.

There are two UI aspects that would need to be handled.

1) Choosing which fields are synced. Right now Bakery puts options on the admin screen. There could be a new hook that provides available sync fields. How would the transmit hook have to change if only some of the available fields were set to be synced?

2) The master sees a message from the slave regarding updating. Should receive hooks return a message and pass/fail?

To incorporate #704488: Update rollback functionality handling for sync hooks I think we need to alter the communication between slave and master. The response HTTP status is good for overall pass/fail, but what if a particular update fails? Rather than rolling back all updates if the slaves response HTTP response is 409 the body should contain pass/fails the master could parse it and record the particular fails. The slave response could be JSON.

Another, simpler idea would be to just use the existing response code (messages) and have the master just record that an update resulted in a 409 and the slave would handle rolling a particular update back. Perhaps rollback is a flag on the receive hook?

Here's new sync hooks including rollback functionality and altered reporting (using latter method mentioned in #14).

I think receive hooks should implement rolling back themselves, rather than the eat stroopwafel function invoking them again, or another hook. I'll demo this in #547524: Role sharing

tag

Note, the patch in #15 doesn't handle sync during account creation on the slave. It only handles updates.

Examiner.com needed sync during account creation and I went with a method using XMLRPC. I could provide that here but I think we need to first address what the best method of communication between master and slave is. RPC, REST, something else?

We're going with POST. The patch here will need to be updated for the new gingerbread cookie #821436: Request account information from master

hi what is the hooks of data function,
2ndly how i call a function of class no1 into class no2,using php

I've applied patch in #15 to 6.x-1.x-dev, but not quite got it working yet.

What is the purpose of the $edit var at line 103? I get a PHP notice because it's not initialized.

Sorry, I worked it out, ignore last comment. It's supposed to refer to parameter 2 of hook_user, which is usually called edit, but for some reason is called $array here.

I was hoping Drupal.org could standardize sharing using public JSON APIs, like https://association.drupal.org/api, but I've changed my mind.

• Bakery syncing is efficient, the specific user is pushed to subsites when they are saved.
• It has been working well for us and we have some knowledge around this.
• Hooks let us implement account saving in a variety of ways. D7 sites should go ahead and use fields instead of profile items.

I think the approach here is good, but will need to be updated to be in line with the current code. DrupalCon Munich is looking to use this right away.

I filed #556666: Sync hooks: Enable sharing of arbitrary data for Drupal.org's future implementation of this hook. That code could make its way into a generic bakery add-on if it does well, but I think shortcuts are likely, since Munich wants to use this a few months ago.

#23 I think you mean to link to #1597500: Implement bakery hooks to save user information for d.o implementation. There I mention my preference for a sync-less Bakery 3.x branch that provides these hooks.

Hi all,

Just been working on a current project which required this functionality and so have had to update the patch as I needed to use it :)

I have only rolled a D7 version of the patch, I have never used D6 and am not sure what differences there are or if there are any changes that will be needed to backport the patch.

I used the #547524: Role sharing example to create my own custom module which maps master roles to their matching ones on the slave site and also updates a couple of user fields which we use.

Hi all,

Attached is an updated patch, I hadn't fixed an issue with the original patch where it calls the bakery_transmit hooks but didn't pass through all of the arguments to the function.

I also noticed an issue where this extra sync data is not transmitted for new accounts. In my usage case there are only certain roles which will have access to the slave site. Everyone can access certain sections of the slave but most of it will be locked (premium content). When a new account is created the user won't have access until their account is next updated on the master site.

This patch includes a fix for this issue where the hooks are called inside bakery_eat_gingerbread_cookie() and bakery_request_account(). With the bakery_transmit hook inside bakery_eat_gingerbread_cookie() I have had to pass NULL for the $edit array and 'gingerbread' for the category. We rely on the person implementing the hook to check for this and then transmit all data for the account rather than just the updated information.

I am open to alternatives on how we can better implement this. In my opinion it makes sense as there is no $edit array and it provides a clear indicator to the module that we want all data. There is no changes required on the receiving side as it just gets the data as per normal.

I talked with Coltrane about this, and he started on Bakery 3.x, with some API for extending data sharing. That means this might not get into 2.x.

However, we still could use it for DrupalCon Munich's site. I'm thinking of removing the various empty() checks and unset($stroopwafel['data'][$type]); so hooks are always executed with all data. (I'm not a fan of user module's style of expecting data to be removed by hook implementations.)

Yep, thanks for letting me know. Look forward to Bakery 3 when it comes out :)

It is good to have a working solution for the moment if anyone needs it.

I can understand both approaches, calling all hooks with all data does increase what the code implementing the hook can do.

Is there a reason why one calling uses ['data'] and the other looks like it adds things to the top level of the data structure?

(for transmit)

No particular reason I think, one part is on the master side and the other is on the slave end.

In bakery_user_presave() the $_SESSION['bakery'] variable is just getting the data together which is then added to $payload['data'] in bakery_user_update() where $_SESSION['bakery'] is unset.

When the payload is received by the slave bakery_taste_stroopwafel_cookie() is called where it is taken and added to $_SESSION['bakery'] on the slave side.

It took me a while to get my head around what code is ran on what sides.

Here is my patch for this. It is more flexible since it operates on the whole cookie all the time. For example, it can pull out profile information attached by a 6.x site for #1597500: Implement bakery hooks to save user information.

Here is an updated patch. It rebased cleanly, only line numbers changed.

Reroll attached

An example of using this hook is http://drupalcode.org/project/association_drupalorg.git/blob/refs/heads/.... It isn't pretty due to using profile module, but it works.

For anyone testing bakery with a mixed D6/D7 cluster this issue can be especially tricky. From what I can see drumm's patch in #35 is currently the most robust approach, so I did a quick back-port of that patch for the current D6 version of bakery. I know this patch not officially considered in any way until a D7 fix is at least RTBC, but maybe it's useful while the concept is being finalized.

http://drupal.org/node/1926532 contains a custom module to share fields using curl

Re-roll to be applied to latest dev code as of this writing.

Only change is that module file now has a blank line at end.

I have reviewed the patch in #35 (this patch is identical except for blank line) and it works as intended provided you implement the hooks.

Any chance of getting this committed?

FWIW, #37 and #39 are both applied on our production environment and we have code that happily syncs stuff between user fields (on D7 master) and content profile (on D6 slave). In a couple of months we will be adding D7 slaves to the mix.

Very sorry for the delay in acknowledging the updates to this issue. I really appreciate the updated patches and testing. As you know, Bakery is complex so getting dedicated time for testing (and working test environments -- i.e. Bakery-Chef) is time consuming.

I've tested these out and am ready to commit to the 2.x branches. Here are updated patches that contain bakery.api.php files for documentation.

Committed!! http://drupalcode.org/project/bakery.git/commit/265d35b and http://drupalcode.org/project/bakery.git/commit/c5e6d07

Many thanks to @solotandem @akoepke @drumm @rjacobs and @fuzzy76 for patch writing/testing!

fwiw I'll be updating https://drupal.org/node/1062888 with plans for next alpha/beta and 3.x work

Thanks for the great work!

The sharing of arbitrary data this way is mainly meant for Drupal slave sites, right?

What could be a working solution for non-Drupal slave sites, how could the data sharing work? Should the non-Drupal make a POST request ('gingerbread' key with the CHOCOLATECHIP cookie value?) against {master_site}/bakery/create, to receive account data?