Jump to:
| Project: | Views Bulk Operations (VBO) |
| Version: | 6.x-1.x-dev |
| Component: | Core |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
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
| Attachment | Size |
|---|---|
| qt_test.views_.txt | 23.19 KB |
| views_bulk_operations-form_id-0.patch | 445 bytes |
Comments
#1
Thanks for the patch. I'll review it soon.
#2
Sounds like a good idea.
Views Form does the same for us in D7.
EDIT: But VBO for D6 already does something like this:
212 // Append suffix to avoid clashing between multiple VBOs on same page.213 static $form_suffix;
214 if (isset($form_suffix)) {
215 $form_suffix++;
216 }
217 else {
218 $form_suffix = 1;
219 }
220 $this->form_id = 'views_bulk_operations_form__' . $form_suffix;
So the question is why does it fail? Maybe the $form_suffix gets reused?
#3
@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_suffixvalues 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_suffixvalues is "1" and that remains.If this happen to the form with id
views_bulk_operations_form__1it's ok, becauserender()function will returnviews_bulk_operations_form__1again.If this happen to
views_bulk_operations_form__2,render()function will returnviews_bulk_operations_form__1, and this is wrong.#4
Okay, 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)
#5
@bojanz, where's the code for this in D7?
#6
In views itself (Views Form API).
<?php
/**
* Implements hook_forms().
*
* To provide distinct form IDs for Views forms, the View name and
* specific display name are appended to the base ID,
* views_form_views_form. When such a form is built or submitted, this
* function will return the proper callback function to use for the given form.
*/
function views_forms($form_id, $args) {
if (strpos($form_id, 'views_form_') === 0) {
return array(
$form_id => array(
'callback' => 'views_form',
),
);
}
}
/**
* Returns a form ID for a Views form using the name and display of the View.
*/
function views_form_id($view) {
$parts = array(
'views_form',
$view->name,
$view->current_display,
);
return implode('_', $parts);
}
?>
and:
<?php// If form fields were found in the View, reformat the View output as a form.
if (views_view_has_form_elements($view)) {
$output = !empty($vars['rows']) ? $vars['rows'] : $vars['empty'];
$form = drupal_get_form(views_form_id($view), $view, $output);
?>
#7
@bojanz, thanks for the info. Committed similar code to D6. @kongoji, please test it and let me know.
#8
Hi infojunkie,
I tested the new vbo dev release and it works flawless.
Thank you and bojanz for having spent time on this issue!
#9
Automatically closed -- issue fixed for 2 weeks with no activity.
#10
Not 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.