Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Block caching works per user but actually should be per session so no reason in caching at all.
Updates before 7000 is useless so removed. Update 7000 has wrong db_update() so fixed.
Info file files[] section should contain only files with class definitions.
Also added "configure" link for modules listing page.
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | 1007052-masq-block-cache-D6.patch | 883 bytes | andypost |
| #4 | 1007052-masq-block-cache.patch | 1.2 KB | andypost |
| #3 | 1007052-masq-block-info.patch | 4.72 KB | andypost |
| masq-block-info.patch | 5.12 KB | andypost |
Comments
Comment #1
deekayen commentedI don't think I agree with the BLOCK_NO_CACHE setting. That constant is intended for blocks that don't do any querying. In the case of masquerade, it does query, but doesn't change until you actually masquerade, in which case the switch back link is different from what other non-masquerading users would see.
Please elaborate on your reasoning there since I'm still thinking BLOCK_CACHE_PER_USER was the right pick.
Comment #2
andypostWhy are you thinking so? If one of user's sessions submits form from block other sessions still have last saved block... tested.
We need different blocks for the same user same time.
For example I have 2 sessions using 2 browsers: in one browser I'm masquerading in second I'm not.
So what do you think the block cache should store?
Suppose the only possible cache strategy is form cache - this actually needs work
Comment #3
andypostFixed install query.
I found that if we try a form cache so for every page we have new form_build_id so form is cached per page...
EDIT: Another reason to not cache blocks - quickswitch links should be rendered per session because of drupal_get_token() used
Comment #4
andypostI've fixed block cache, suppose #2-#3 is enough
patch commited to @master http://drupalcode.org/project/masquerade.git/commit/7193ba4
Comment #5
andypostBlock cache should be backported to 6 but not sure we need to move updates from 6.x to 7.x
Comment #6
b-prod commentedWith Drupal 6.20, the block cache per user makes the autocomplete fail. With NO_CACHE it works.
Comment #7
andypostIs this still an issue?
Comment #8
b-prod commentedEven for version 6.22 of D6, it is still an issue.
Comment #9
andypost@B-Prod please test this patch, I'm going to commit it but I needs some reviews.
And can you explain a case when you affected this issue, suppose when one user works in different browsers
EDIT: you need to run update.php after applying patch
Comment #10
b-prod commentedThis patch worked for me.
Actually the problem for 6.x branch was that the JS file was not added on certain conditions. So the autocomplete behavior failed. I am sorry but I do not remember much more, since it fixed that a long time ago on a delivered project.
Comment #11
andypostCommited