Closed (fixed)
Project:
Views Bulk Operations (VBO)
Version:
6.x-1.x-dev
Component:
Core
Priority:
Major
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
1 Mar 2011 at 13:55 UTC
Updated:
15 Dec 2011 at 05:39 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
infojunkieThe selection mechanism is new in the latest dev.
If you want to help debug it, please do the following:
* Enable devel.module
* Insert the following line
after line 375 in views_bulk_operations.module, which should say:
Now select a few rows and click an action: what debug output gets printed?
Comment #2
teliseo commentedI was just ready to file a new issue, and then saw this one. Here’s my environment, which may differ from the OP’s:
I see the same symptom as the OP: I select rows, select and execute any operation, and then get 0 rows on the confirmation page.
Here’s what’s happening: Because the Date field is present, the
render()method in date/date/date_handler_field_multiple.inc is storing adate_infoobject in thevaluesobject. When the view form is generated, the selection checkboxes are associated with MD5 hashes of objects that have had thisdate_infoobject added. However,_views_bulk_operations_adjust_selection()(a processing function that leads to the confirmation page) calculates its MD5 hashes using non-fully-rendered objects (they lackdate_info) and gets different results. It therefore finds no selection matches, and shows 0 rows selected.My solution (attached patch) is to remove embedded objects and arrays from
valuesobjects for hash calculation, since normal rendered values should only be strings. This feels like a hack, but may resolve issues other than with the Date module. I think I understand the motivation for hashing the objects, as VBO cannot, in general, find another unique ID. However I think there might be fewer such problems if known unique IDs were used as selection values for a few common object types (e.g., nid for nodes and uid for users).A more elegant solution would be to get the pre-rendered value objects when generating the view form, but I don’t understand the code well enough to know how to do that (or even if this is possible).
Another answer might be to blame the Date module for storing random stuff in the
valuesobject, but I haven’t seen any prohibition against this, and its implementation might be much more difficult or inefficient otherwise.Comment #3
infojunkieThanks teliseo for the analysis and patch. The nid and other unique entity keys cannot be used because views might return different rows with the same entity key - e.g. when joining with one-to-many tables. That's what prompted this modification in the first place. I need to better understand this rendering issue - I'd love to rewrite the
_views_bulk_operations_adjust_selection()function for other reasons too including saving some memory space.ikeigenwijs, please apply this patch and let us know if this solves it for you - we'll have more confidence if it does. Otherwise, please post your view export to help me reproduce the problem on my side.
Comment #4
infojunkieI was able to reproduce teliseo's scenario, working on it.
Comment #5
ikeigenwijs commentedI will test this tomorrow.
Comment #6
eafarris commentedI was having a similar issue with VBO telling me I didn't select any rows. The patch in #2 did fix the issue for me.
Comment #7
ikeigenwijs commentedThe patch did not work for me: No rows were processed:
I dont use clean URL'
view has exposed filters
drupal 6.20
date2.7 not 2.x
everything up to date
Comment #8
ikeigenwijs commenteddev output:
#
Krumo version 0.2a
| http://krumo.sourceforge.net
Called from /www/_shares/_revaki/WWW/sites/all/modules/views_bulk_operations/views_bulk_operations.module, line 376
I copied the whole html to be complete:
,
line
376Comment #9
Encarte commentedsubscribing
Comment #10
ikeigenwijs commentedis the view correct?
Comment #11
infojunkie@ikeigenwijs, I can't rebuild the view because there are custom CCK fields. It would be more useful to create a simple view with just core fields. Thanks!
Can you turn clean URLs on and check if there's a difference?
Comment #12
ikeigenwijs commentedNo i cant turn clean url's on, its not supported on this server, i ll make a view with only core fields.
Comment #13
jjwhitney commentedI'm running into this problem, too. The patch in #2 helps, but having any Views Custom Fields in the view also causes the same issue. This is caused by the fact that the extra fields show up in views_node_selector_process(), but not in _views_bulk_operations_adjust_selection(). Maybe it's just too dangerous to rely on hashes of the field results?
Comment #14
infojunkieThanks all for your feedback. Good point about the hash being unreliable. I guess it would be a matter of catching the result set at the same state in all cases, in order to ensure consistency.
The main problem is that I can't rely on the node nid (if we're talking about a node view) because there might be multiple records with the same nid. So I'm looking for a reliable way to uniquely identify a record.
Another approach would be to store the selected records in form storage as it goes through the multiple steps. Maybe I should investigate in this direction.
Comment #15
jjwhitney commentedThanks, infojunkie, for your thoughts on this issue. If/When you take another shot at a fix, it'd be fantastic if you also look at selecting items in "Merge single action's form with node selection view" mode, which also seems to be broken. (I'm pretty sure it's a separate issue though.) In this mode, using the pager clears out any checkboxes for selected items. (Note that the items are still selected "behind the scenes", but the checkboxes do not reflect this.)
Comment #16
infojunkiePlease try the latest dev (12 hours from now). I've added a call to the pre_render functions in
_views_bulk_operations_adjust_selectionto get the same results as during the rendering process. Does this make a difference?Comment #17
jjwhitney commentedIt's better (no more issues with Views Custom Field), but the problem with date fields as described in comment #2 hasn't gone away. For the time being, I'm just using the patch there to get around the problem.
Comment #18
infojunkieThanks jjwhitney for your reply. I've actually completely changed the selection mechanism, I'll be checking in the new code soon.
Comment #19
digi24 commentedThanks infojunkie, the latest dev code works for me too.
I still hope, that VBO might reintroduce the possibility to (optionally) base the selection on the entity-ids on submit. I have some views with frequently changing results that (correctly) do not execute, when the result hash has changed in the meantime, but where the selection at submit would still be desired. This becomes mainly visible when using VBO with apachesolr.
Comment #20
gnindl commentedConfirm comment #17. I also noticed that the new selection mechanism is slower.
Comment #21
infojunkieThe new selection code that I will push next week only stores the results once - no need to requery the view at all. I am hoping this solves the problem permanently. Thanks for everyone's patience.
Comment #22
infojunkiePlease test the latest dev as the selection code was completely changed. The initial view results are cached to avoid re-executing the view. This change should resolve the current issue.
Comment #23
digi24 commentedWas http://drupalcode.org/project/views_bulk_operations.git/commit/8e046e4 the relevant commit?
I have been using this and I am still having some issues either from the Batch processing or from some exposed filters. But they may be specific to my installation, so I am trying to hunt it down myself.
Comment #24
infojunkie@digi24: yes, that's the one. Please post scenarios where selection fails - using only core Drupal data if possible. Thanks!
Comment #25
naero commentedI'm having the same issue, but with a Term view. Also, I can't apply the patch from #2 to the latest dev version (as of today).
Comment #26
infojunkie@naero: no need to apply patch #2, the code is now different but the issue should be fixed. Please include a scenario to reproduce your problem, ideally only using core Drupal data.
Comment #27
digi24 commentedRegarding my feedback in #23, I have isolated my issue not to be related directly to this fix. The selection works for me using drupal core data.
Comment #28
infojunkieThe problem still persisted even after the new selection code. Even though the results are now cached by VBO, the Date CCK field still preprocesses its information *after* the VBO style plugin, leading to the same issue. I committed the patch in #2.
Comment #29
Anonymous (not verified) commentedI've tryed to update views_bulk_operations-6.x-1.x-dev.tar today version, during the process I got following error
warning: array_merge() [function.array-merge]: Argument #2 is not an array in /update.php on line 173.
warning: Invalid argument supplied for foreach() in update.php on line 337.
Than I also got following error while I was browsing a views_bulk_operations page:
warning: implode() [function.implode]: Invalid arguments passed in /includes/form.inc on line 838.
There are no cck date field in that view.
[referenced to http://drupal.org/node/1183522#comment-4586720]
Comment #30
infojunkie@giorez: I fixed the update problem - thanks.
Regarding the VBO page warning: Does it prevent the selection from working correctly?
Comment #31
Anonymous (not verified) commentedthe selection works properly, but the error is printed for each row
Comment #32
infojunkieWhat you're witnessing is not necessarily related to the selection issue at all. I'm marking this issue as fixed and feel free to open a new one for the warnings. But I will ask you for a detailed description on how to reproduce them, because I haven't seen those warnings with the default content admin VBO.
Comment #33
Anonymous (not verified) commentedsorry for reopening but I double checked also with git version. The update proccess from 6.x-1.10 to 6.x-1.x-dev has been fixed, but I still got following errors:
No row selected. Please select one or more rows.
warning: implode() [function.implode]: Invalid arguments passed in /includes/form.inc on line 838.
I hope this help
Comment #34
infojunkie@giorez, I need more information about the view you're using:
* Dump the view
* Module versions: Views, any CCK fields, etc.
Comment #35
Anonymous (not verified) commentedViews 6.x-3.x-dev (2011-Jun-10)
Content Construction Kit (CCK) 6.x-2.9
Views Bonus Pack 6.x-1.1
Views Custom Field 6.x-1.x-dev (2011-Feb-25)
Content Profile 6.x-1.0
Comment #36
infojunkieThanks, I reproduced it. Working on it now.
Comment #37
infojunkieViews Custom Field has been superseded by Views PHP, which contains more mature code and supports the latest Views + VBO versions. Migrating to Views PHP should be as easy as replacing the fields and copying the code. I encourage you to migrate, because Views Custom Field will be marked as obsolete very soon. Please let me know how it goes.
Comment #38
Anonymous (not verified) commentedI replaced Views Custom Field with Views PHP, and the issue has gone away in the views attached at #35
On the views I'm attaching right now, I still have two errors:
-No row selected. Please select one or more rows.
-warning: implode() [function.implode]: Invalid arguments passed in /includes/form.inc on line 838.
Thanks a lot for your support!
PS When I send bulk sms I still have an issue as explained at http://drupal.org/node/1150180
Comment #39
Anonymous (not verified) commentedComment #40
infojunkie@giorez, I can't figure out which field is causing the problem. Can you please remove them one by one, starting with the non-core fields, and see which one is causing it?
Comment #41
Anonymous (not verified) commentedit seems to be related to the field
Node: New comments
The number of new comments on the node.
I hope this helps.
Comment #42
infojunkieI've submitted a patch that applies to all versions of Views and that solves these problems: #1186272: Reorder pre_render calls. Until that patch is committed or rejected, I am postponing this issue. I encourage concerned parties to vote for that patch.
Comment #43
Anonymous (not verified) commentedsince views 6.x-3.x-dev2011Jul21 the issue is disappeared
Comment #44
lunk rat commentedI am using views 6.x-2.16 and VBO 6.x-1.12 and I spotted this issue ONLY when I have an exposed filter on an integer field with "Is between" operator.
My view is simple as can be: just title field and a few exposed filters.
When the exposed operator is anything other than "Is between" the issue does not appear.
Comment #45
infojunkieClosing this old issue - please follow #1370806: Enabling Persist selection yields 0 rows selected or open a new one if your scenario is different.