Each time a views form is submitted (for example, after selecting items on the VBO form), a new page is loaded, and the view is re-executed in the background.
If $form_state['cache'] is not set, the form is rebuilt before validation / submission. Since the view has been re-executed, the results might have changed, which means a rebuilt form would have different form elements, leading to invalid data in $form_state['input'] that gets dropped from $form_state['values'] (or assigned to a different row).
If $form_state['cache'] is set, the form is retrieved from cache for validation and submission, which means that even if the views results changed, $form_state['values'] contains the expected data.

See #1460154: Incorrect form values selected for operations for background.

CommentFileSizeAuthor
#1 1473276-cache-views-form.patch718 bytesbojanz

Comments

bojanz’s picture

bojanz commented
Status: Active » Needs review
StatusFileSize
new 1473276-cache-views-form.patch718 bytes

Fix is simple.
Will commit this to VBO as well, so that people with older Views versions don't have problems;

tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
commented

Triggering the testbot.

tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
commented
Assigned: Unassigned » dawehner

This sounds reasonable.

tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
commented
Status: Needs review » Reviewed & tested by the community

Er, whoops.

dawehner’s picture

dawehner
Primary language German
commented

I totally see the problem here, so adding $form_state['cache'] solves that problem,
but i'm just wondering whether this might cause problems for websites which uses views forms not as a backend tool but on the frontpage or something similar. They will see that each request creates a new entry in the form_cache table, which isn't that nice.

So can you think of such contrib/custom modules?

bojanz’s picture

bojanz commented

Someone could have a VBO block on the front page.
However, this is such a deep architectural problem that even with that side effect (a row in the table per view) the solution is still tolerable.
I see no other way other than magically solving the problem of "view gets reloaded on next load" (which would require caching it in some way as well).

dawehner’s picture

dawehner
Primary language German
commented
Version: 7.x-3.x-dev » 6.x-3.x-dev
Status: Reviewed & tested by the community » Patch (to be ported)

Right. Additional if people see that's a problem they can still use some alter hook and change the value again.
Committed to 7.x-3.x

macman’s picture

macman commented

Hi

I think I am having the same problem on my site. However, I am running vbo 6.x-1.10 so the above fix does not apply. Can you please give me instructions about what to change? Thanks.

bojanz’s picture

bojanz commented

VBO 6.x doesn't use Views Form.
Update to the latest 6.x-1.x-dev, retest, if the problem still exists open an issue in the queue.

macman’s picture

macman commented

sorry running views 6.x-2.10

chris matthews’s picture

chris matthews commented
Issue summary: View changes
Status: Patch (to be ported) » Closed (outdated)

The Drupal 6 branch is no longer supported, please check with the D6LTS project if you need further support. For more information as to why this issue was closed, please see issue #3030347: Plan to clean process issue queue