Hi,
If I have 2 views embedded in the same page and I use an ajax exposed filter, after the filtering I cannot execute any operation because of a form_id conflict.
This is the case: I have two vbo views in the same page inside a Quicktabs block (one view for each tab).
The vbo forms' id of the views are views_bulk_operations_form__1
(tab #1) and views_bulk_operations_form__2
(tab #2) (the ids are automatically generated by drupal form system).
When I go on the second tab view's form and I perform an ajax filtering using exposed filters, the vbo form is loaded again to display filtered elements. Once loaded, the form id is not views_bulk_operations_form__2
anymore, but it becomes views_bulk_operations_form__1
.
I attach a very simple view to reproduce the problem and a patch that fix it.
How to reproduce the issue step by step:
- install vbo module (I have 6.x-1.13 version)
- install quicktabs module (http://drupal.org/project/quicktabs) (6.x-3.1 version)
- import the views attached
- create a quicktabs block with 2 tabs (each tab is a different display of the same view)
- include the quicktabs block in a page you like
- go on the SECOND tab's view and filter by title using ajax
- select one or more nodes in the vbo table you obtained by filtering and press an action
- it will return "No items were processed: " message, and it will not execute any operation
Comment | File | Size | Author |
---|---|---|---|
views_bulk_operations-form_id-0.patch | 445 bytes | kongoji | |
qt_test.views_.txt | 23.19 KB | kongoji |
Comments
Comment #1
infojunkieThanks for the patch. I'll review it soon.
Comment #2
bojanz CreditAttribution: bojanz commentedSounds like a good idea.
Views Form does the same for us in D7.
EDIT: But VBO for D6 already does something like this:
So the question is why does it fail? Maybe the $form_suffix gets reused?
Comment #3
kongoji CreditAttribution: kongoji commented@bojanz
yours is a great catch, but what happens here is this:
1) page is rendered with 2 vbo views inside
2) it pass twice in
render()
function, so$form_suffix
values is "1" and then it becomes "2".3) user perform an ajax call using views exposed filters: only one of the two views is reloaded and re-rendered this time.
4) it pass only once in
render()
function, so$form_suffix
values is "1" and that remains.If this happen to the form with id
views_bulk_operations_form__1
it's ok, becauserender()
function will returnviews_bulk_operations_form__1
again.If this happen to
views_bulk_operations_form__2
,render()
function will returnviews_bulk_operations_form__1
, and this is wrong.Comment #4
bojanz CreditAttribution: bojanz commentedOkay, so we actually need to modify the code I mentioned above, kill $form_suffix, and add your / D7 variant (appending view name and display name)
Comment #5
infojunkie@bojanz, where's the code for this in D7?
Comment #6
bojanz CreditAttribution: bojanz commentedIn views itself (Views Form API).
and:
Comment #7
infojunkie@bojanz, thanks for the info. Committed similar code to D6. @kongoji, please test it and let me know.
Comment #8
kongoji CreditAttribution: kongoji commentedHi infojunkie,
I tested the new vbo dev release and it works flawless.
Thank you and bojanz for having spent time on this issue!
Comment #10
rooby CreditAttribution: rooby commentedNot sure if you have a system for flagging things as needing release notes, but this might be one of those things.
It's probably borderline but it could be considered an API change because form id changes are something that can have an effect on external code, such as CSS & form alterations.
It is probaly worth a proper notice at the top of the next release's release notes.
Comment #11
bojanz CreditAttribution: bojanz commentedWhoops, too late now, since there have been releases since this fix went in. Sorry.
Comment #11.0
bojanz CreditAttribution: bojanz commentedUpdated issue summary.