Have Firefox open with my admin user, Safari with my 'editor' role. After I ran cron from the admin menu, switched to the other browser and clicked on a node (lets call it node/34). Used the theme switcher on this same page to switch themes. Cool, different theme, still on node/34 (correct behavior). Now, when I go to a different node, say node/99, and switch themes, i get bounced back to node/34. Seems it gets stuck on whatever node you first go to AFTER cron is run AND switch the theme. (NOT the node you're CURRENTLY on after cron--you have to refresh the page OR click on something else then switch themes, and THAT'S the page it sticks on.)
I don't think I was able to recreate this on the browser I was logged in as my admin, user1, so it seems like it might be a non-user1 thing.
Comment | File | Size | Author |
---|---|---|---|
#6 | switchtheme-402348.patch | 1.34 KB | gilgabar |
Comments
Comment #1
sunUnfortunately, SwitchTheme has nothing to do with cron. I'm not sure what could trigger this behavior for you, but it somehow sounds like a third-party contrib module interferes.
Comment #2
gilgabar CreditAttribution: gilgabar commentedI have some more info on this bug. It does not affect user 1, as the OP says. It only occurs when block caching is enabled. It isn't related to cron directly, but I'm guessing the block cache is getting cleared when cron is run, so it appears to reset things. Using the 'Flush all caches' item in admin_menu achieves the same reset state. The bug does not occur using the built-in per user theme switching form on the user edit page.
After clearing the cache the first page that a user switches the theme on becomes the page that is redirected to any time that user or any other user switches to that theme. It is per theme, so if you switch to theme A while on page X, it will always redirect to page X when that theme is switched to. And if you then go to page Y and switch to theme B, page Y becomes the page redirected to for theme B. If it is a different user that switches to a theme than the one that first switched to a particular theme, then the user will also receive a validation error in addition to the redirect after switching the theme.
I've tested on a plain drupal install with only core modules enabled, so it does not seem like a third-party module issue. I'm switching the priority to critical as this bug makes the module unusable with block caching enabled, which basically makes it useless for high traffic sites. I'm also updating the title to reflect the nature of the bug a little better.
Comment #3
aterchin CreditAttribution: aterchin commentedblock cache cleared on cron run seems the more likely culprit, i agree. haven't tested yet though.
Comment #4
petednz CreditAttribution: petednz commentedseemed to hit the same problem - so thank you for the suggestion to turn of block caching as a temporary fix - worked for me though not ideal of course (but then it sorted another problem with blocks to so, hey, two for one)
Comment #5
gilgabar CreditAttribution: gilgabar commentedThis turned out to be a fairly simple problem. The validation error is just the form token getting cached, so subsequent attempts to submit the form fail because the token was only valid for the first user that primed the block cache.
The redirects are a result of the form action being cached. That is something like the action attribute in:
The best solution to the problem is just to turn off caching for this block. It's slightly tricky because it seems like you should be able to just add this to hook_block:
Which you should, but the block caching state is saved in the database. So if you have an existing installation of switchtheme you will also need to update that value for it to actually take effect. A patch should change it via hook_update. You could also do it manually in the db (setting the value to -1) or use something like Block Cache Alter.
If you can't live without caching that block you can get rid of the validation error by unsetting the token in the form:
But that leaves the redirect and I'm not aware of a good way to work around that.
Comment #6
gilgabar CreditAttribution: gilgabar commentedThe attached patch implements my suggestion above to disable block caching.
Comment #7
enkara CreditAttribution: enkara commentedNo progress on this?
Comment #8
sunThanks for reporting, reviewing, and testing! Committed with slight adjustments to all branches.
A new development snapshot will be available within the next 12 hours. This improvement will be available in the next official release.