Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
This is requested for the redesign.
I am not sure what the requirements exactly are, though.
Sharing user pics seems obvious.
Comment | File | Size | Author |
---|---|---|---|
#43 | bakery-556666-hooks-43-d6.patch | 4.01 KB | coltrane |
#43 | bakery-556666-hooks-43.patch | 3.95 KB | coltrane |
#39 | 556666-sync-hooks.patch | 2.39 KB | solotandem |
#37 | bakery-D6_add_sync_hooks-556666-37.patch | 2.51 KB | rjacobs |
#35 | 556666.diff | 2.25 KB | drumm |
Comments
Comment #1
killes@www.drop.org CreditAttribution: killes@www.drop.org commentedI've added support for shared images. This makes a few assumptions, ie that http://domain.com/files/... is the same as http://sub.domain.com/files...
Tweaking could be done in the preprocess function.
Comment #2
killes@www.drop.org CreditAttribution: killes@www.drop.org commentedJust a word of clarification:
the image path of the master site does /not/ have to be the same as on the slaves (if it was, image sharing would work out of the box). However, the master site's image path must be accessible under the slave site's doc root.
Currently, users can also upload different images on slave sites. These get clobbered once you update the image on the master, though. Not sure this is bug or feature.
Comment #3
killes@www.drop.org CreditAttribution: killes@www.drop.org commentedCurrently the following fields can be shared:
mail, name: mandatory
optional: language, picture, signature, timezone. The slave sites have the option to ignore data sent by the master. Everything admin-configurable.
We need to discuss how profile data will be stored in the future.
Comment #4
killes@www.drop.org CreditAttribution: killes@www.drop.org commenteduser status is a field that will be available for sharing soon.
Comment #5
BenMirkhah CreditAttribution: BenMirkhah commentedAny news on this? Current version provides checkboxes for user-defined profile fields however values don't cross over.
Comment #6
BenMirkhah CreditAttribution: BenMirkhah commentedProblem is in the following segment:
To fix it removed of the conditional and loaded the user/profile information...
Comment #7
skizzo CreditAttribution: skizzo commented- applied patch #6 (currently at line 102)
- as user 1, entered user account edit on master node
- changed the user picture, on save:
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
Comment #8
coltraneIf 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?
Comment #9
coltraneProposal, 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 object2) 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 signing4) slave receives POST and in
bakery_eat_stroopwafel_cookie()
invokes 'bakery_receive_fields' passing it the array of fields5) 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)
Comment #10
coltraneHere'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.
Comment #11
coltraneUpdated patch sends $edit and $category to transmit hooks.
Also for D6.
Comment #12
coltraneThere is some test code in http://drupal.org/node/547524#comment-2913504 for sharing roles that you can see how the hooks work.
Comment #13
coltraneBakery 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?
Comment #14
coltraneTo 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?
Comment #15
coltraneHere'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
Comment #16
drummtag
Comment #17
coltraneNote, 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?
Comment #18
coltraneWe're going with POST. The patch here will need to be updated for the new gingerbread cookie #821436: Request account information from master
Comment #19
m_tahir CreditAttribution: m_tahir commentedhi what is the hooks of data function,
2ndly how i call a function of class no1 into class no2,using php
Comment #20
darrenmothersele CreditAttribution: darrenmothersele commentedI'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.
Comment #21
darrenmothersele CreditAttribution: darrenmothersele commentedSorry, 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.
Comment #22
drummI was hoping Drupal.org could standardize sharing using public JSON APIs, like https://association.drupal.org/api, but I've changed my mind.
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.
Comment #23
drummI 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.
Comment #24
coltrane#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.
Comment #25
akoepke CreditAttribution: akoepke commentedHi 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.
Comment #26
akoepke CreditAttribution: akoepke commentedHi 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.
Comment #27
akoepke CreditAttribution: akoepke commentedComment #28
drummI 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 andunset($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.)Comment #29
akoepke CreditAttribution: akoepke commentedYep, 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.
Comment #30
drummIs there a reason why one calling uses
['data']
and the other looks like it adds things to the top level of the data structure?Comment #31
drumm(for transmit)
Comment #32
akoepke CreditAttribution: akoepke commentedNo 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.
Comment #33
drummHere 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.
Comment #34
drummHere is an updated patch. It rebased cleanly, only line numbers changed.
Comment #35
drummReroll attached
Comment #36
drummAn 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.
Comment #37
rjacobs CreditAttribution: rjacobs commentedFor 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.
Comment #38
coltranehttp://drupal.org/node/1926532 contains a custom module to share fields using curl
Comment #39
solotandem CreditAttribution: solotandem commentedRe-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.
Comment #40
fuzzy76 CreditAttribution: fuzzy76 commentedAny chance of getting this committed?
Comment #41
fuzzy76 CreditAttribution: fuzzy76 commentedFWIW, #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.
Comment #42
drummComment #43
coltraneVery 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.
Comment #44
coltraneCommitted!! 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
Comment #45
temaruk CreditAttribution: temaruk commentedThanks 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?