Recently attempted to upgrade to VBO 3.4. After doing so on the staging site, discovered that we can neither print nor delete multiple orders. After selecting multiple orders then an operation, the error 'Please select at least one order' is rendered in the drupal message bar. After encountering this error, we disabled the 'Delete orders using VBO' module in Ubercart and tested to see if we could print multiple orders. Same error occurs. Reverted to VBO 3.3 and all operations works as before. I have raised this issue on the VBO thread (2856944) and Joel is looking into it. But I don't think he has an ubercart reference to help him debug so best if this could be resolved among the maintainers of both Ubercart and VBO.
Comments
Comment #2
TR CreditAttribution: TR commentedComment #3
alh CreditAttribution: alh commentedComment from @andrewbelcher in VBO issue 2856944:
So the problem here is that neither Better Watchdog UI or Ubercart specifiy the entity type in their views data definition for the base table. If you look at how views defines the table for an entity (in this case user):
You see it specified $data[BASE_TABLE]['table']['entity type'] = ENTITY TYPE;, which is the key piece of information missing. Without that views_plugin_query_default::get_result_entities is unable to load the required information. In the case of Better Watchdog UI, adding the entity type as follows resolves the issue:
Comment #4
DanZ CreditAttribution: DanZ commentedSee #2856944: 'Please select at least one item' - after upgrading to 7.x-3.4.
This is a bug caused by the incompatibility of the new Views Bulk Operations 7.x-3.4 code and the Ubercart code that doesn't specify the entity type. I.e., the VBO update broke it.
The question is whether the issue should be solved by updating Ubercart or by putting code in VBO to work around the problem in old modules (like Ubercart).
Comment #5
TR CreditAttribution: TR commentedI have no objection to changing something in Ubercart, but I'd sure like to know why our Views definitions are suddenly considered wrong after so many years of working fine. Specifically, was there a change in Views at some point, if so what was the change? Does anyone have a link to the documentation that explains that entity type key and why Views needs it? And what specifically changed in VBO that caused this to fail in the current version yet still work in the old version - is there some assumption made in VBO that doesn't apply in the case of orders? If we don't know why it broke then we won't be able to avoid similar problems in our other Views definitions. And if we don't know why it broke then we don't know this is the right fix.
Comment #6
DanZ CreditAttribution: DanZ commentedI haven't researched all that stuff, but I did find a comment at #2856944-27: 'Please select at least one item' - after upgrading to 7.x-3.4 that explains how it was fixed for the "Better Watchdog UI", and that the exact same fix should work for Ubercart (it explicitly mentions Ubercart).
Maybe that will help.
Comment #7
TR CreditAttribution: TR commentedYes I read that, but that amounts to black magic. The 'entity type' key is undocumented (please, point me to the documentation if it exists - I can't find it in any of the official Views documentation), so how are we supposed to know when and where it is 'required' and what else needs to be 'fixed'. The uc_order entity definition in hook_entity_info() contains the information about the entity's base table, so this data is already available to Views. Duplicating that information in the Views hook shouldn't be necessary and is a point of failure if the information is inconsistent between the two hooks. The fact that it has always worked until now is evidence that this information isn't really needed in the Views hook, except for some extremely specialized purpose (the Search API is cited in one of those threads).
Also, is this a Views 3 thing or a Views 2 thing or both? Since It's not documented it's hard to tell... But uc_order specifies that we are using Views 2 API, so if this is something that was introduced in Views 2 then VBO should *absolutely* be checking the API version before requiring an 'entity type' key.
Sorry for being crotchety, but I can't consider this a bug if the 'requirement' isn't documented anywhere.
Comment #8
joelpittet@TR, you're right it's not documented in views, that looks like it may be an oversight in views. Views didn't have a 3 API in 7.x branch I was just looking, maybe it's a BC layer from 6.x, though I don't think 6.x had entity types to speak of, so that's probably why it didn't exist in Views 2 API.
The only mention I spotted in the API docs was this note when upgrading which doesn't amount to much:
http://cgit.drupalcode.org/views/tree/help/api-upgrading.html#n194
Feature request is fine for a category since it did work before.
The only reason it worked in VBO 3.3 is because before was under the assumption that the
base table
orrevision table
was the entity_type.The key is expected here:
http://cgit.drupalcode.org/views/tree/handlers/views_handler_field_entit...
and used here:
http://cgit.drupalcode.org/views/tree/includes/cache.inc#n108
And added manually here:
http://cgit.drupalcode.org/views/tree/modules/node.views.inc#n31
http://cgit.drupalcode.org/views/tree/modules/user.views.inc#n27
The original issue(s) that this got added in was here:
https://www.drupal.org/node/1270982
https://www.drupal.org/node/1270890
Reviewing all that, I think there may be other benefits to adding this key, though it would be nice if I could think of a
hook_views_data_alter()
that could do this in a generic way. (still pondering this).Comment #9
DanZ CreditAttribution: DanZ commentedUntil this gets fixed/updated, Ubercart can be fixed by downgrading VBO to 3.3. Without using drush, etc.:
The 7.x-3.4 upgrade didn't have any database updates, so this should be safe. It worked for me. I can't guarantee it will work for you.
Comment #10
DanZ CreditAttribution: DanZ commentedLet's make the title a little more explicit.
Comment #11
alh CreditAttribution: alh commentedTo close the circle, VBO 3.4 with the patch found here
www.drupal.org/node/2856944#comment-12050285
resolves the issue with Ubercart bulk order print/delete.
Comment #12
raveendrab CreditAttribution: raveendrab commentedI am not sure whether the referred patch in #11 is solution to the problem.
The Bulk Operation option is not available after upgrade to VBO 3.4 and above.
I need to use VBO 3.3 to perform bulk operations.
Comment #13
joelpittetThe referred patch in #11 has been committed to the -dev release. If you could try the dev release of VBO with this module and report back that would help me to release a 3.6 release.
Comment #14
raveendrab CreditAttribution: raveendrab commentedThe referred patch in #11 seems to be working. This is working "VBO actions for Ubercart" module disabled. I have tested with VBO 3.x dev (3.5+2-dev).
Comment #15
TR CreditAttribution: TR commented@raveendrab: I don't quite understand what you're trying to say in #14.
Do bulk operations work for you with Ubercart and VBO 7.x-3.x-dev ?
Comment #16
raveendrab CreditAttribution: raveendrab commentedYes, bulk operations work with Ubercart and VBO 7.x-3.x-dev.