Here are the steps to reproduce:
1. You have to open a site on the master example.com, for example example.com/node/1
2. Open a node for editing on a the subsite test.example.com/node/100/edit and edit some node data, for example in a new tab or browser window.
3. Now go back to the browser tab with the master site example.com, leave the subsite tab open and navigate on the master site to another node, for example example.com/node/2
4. Go back to the subsite browser tab and try to save the node.
The form submit will fail and the page is reloaded without saving the edited node data. This also works if you try to save other forms.
I can reproduce this bug on a blank Drupal 6.22 installation with Bakery 6.x-2.x-dev (Debian Lenny, PHP fcgid).
N/A
Please test on your system and confirm the bug or help building a patch for this bug.
N/A
N/A
N/A
Comments
Comment #1
crifi commentedFix typo.
Comment #2
coltraneWhat is the error message? I suspect this is not a Bakery problem because there is little-to-no Bakery involvement during node edit.
Comment #3
gregglesWe've seen this symptom on g.d.o. I think this is probably related to rebaking one (or more) of the cookies (probably unnecessarily) causing your session to get disassociated from the form cache.
Comment #4
gregglesAnd, posting that comment was an attempt to get it to trigger on g.d.o and I was unable to reproduce the behavior. My steps were:
1. Open node for editing on g.d.o
2. Visit d.o, click a few pages, post that comment
3. Go back to g.d.o and save the node
I expected the node to present back to me without the change. In fact the change was saved as a new revision.
Comment #5
crifi commentedThank you greggles. I don't have an error message or watchdog entry. The issue also concerns comment forms on my sites.
Comment #5.0
crifi commentedFixed some typos
Comment #6
larowlanI'm seeing this on 7.x
Comment #7
larowlanSteps to reproduce.
Login to master site.
Visit slave site and fetch a form as logged in user (any form) in new tab/window.
Click around on master site.
Attempt to save form on child site - silently drops form values.
Comment #8
larowlanRemoving r4032login fixed this...
Comment #9
larowlan...or maybe not
Comment #10
larowlanMore debugging.
Login on master site.
Visit child-site, see bakery_user_authenticate_finalize() fire, user logged in.
Visit parent-site, see global $user->uid == 0 in bakery_boot().
bakery_user_authenticate_finalize() fires on master site, triggering drupal_session_regenerate().
302 redirect issued to page via drupal_goto.
Visit child-site, global $user->uid == 0 in bakery_boot().
bakery_user_authenticate_finalize() fires on child site, triggering drupal_session_regenerate().
Constant 'Session opened for %name.' entries in watchdog, from bakery_user_authenticate_finalize().
Comment #11
larowlanComment #12
larowlanOk, the issue here is that our server was configured for settings.php inheritance.
So $cookie_domain was identical for the master site (example.com) and the slave site (example.com/subsite).
So we were only getting one session name/session cookie.
Removing $cookie_domain and instead setting $base_url for each site to ensure unique session names meant it worked.
Thanks for an awesome module, quite an education debugging it.
Comment #13
gregglesThere's documentation about how to set cookie_domain and base_url in settings.php to work with this module. Seems like a great idea to add your findings there.
Any chance for a patch to update that documentation?
Comment #14
melandren commentedA more step by step walk through of how to fix this would be greatly appreciated.
Comment #15
purencool commented