Closed (fixed)
Project:
Ubercart
Version:
7.x-3.0
Component:
Orders
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
30 Dec 2011 at 03:17 UTC
Updated:
17 Mar 2012 at 04:09 UTC
Jump to comment: Most recent file
Comments
Comment #1
wodenx commentedDoes this suffice? It seems to clear up the array_flip error for me, but I am not an intimate of the entity wrapper api...
Comment #2
rhazor commentedWorks. Fixed my issues at http://drupal.org/node/1388518
Comment #3
mariagwyn commentedFYI:
I had similar error which appeared when a customer placed an order. The order would be placed the the completion page would not display, nor would any emails be sent to either admin or the customer. This was specifically on orders using a CHECK.
The patch fixed it, so put this in!!!
Thanks!
Comment #4
tr commentedResetting to the correct status.
Comment #5
longwaveAlthough this works I am not sure this is the best fix, as $order->products appears to already be fully loaded; returning array_keys() works around this by returning just the IDs again, so they can be (unnecessarily) reloaded.
Perhaps this is a bug in Entity API in that it is loading already-loaded objects, or we need to make changes to hook_entity_property_info() somewhere?
Comment #6
longwaveThe git bisect implies this is entity token related; I don't think it makes sense to generate tokens for every product in the order so perhaps we can just disable entity tokens for the products property?
Comment #7
wodenx commentedWell - my guess is that entity_api isn't caring about reloading entities because if they are properly loaded the first time they will be cached. But when we load the order products, we do it by a direct query of the db, rather than via entity_load. That's fixed in the ever-pending #1301430: Inclusive tax implementation is not flexible (attribute options), or could also be fixed more simply. As to your comment in #6 - I guess that's true, but I can imagine wanting to display information about individual products in an order - also, while the problem was entity_token related, I thought it had to do more generally with the way lists were handled - so might there not also be implications for rules and views?
Comment #8
longwaveTokens make sense on the individual product level, but not to me in the sense of generating tokens for the entire list, as you would need to know the total number of products and index number of each product to be able to do anything useful with the resulting tokens (e.g. [order:products:0:title], [order:products:1:title], etc).
That's assuming that entity tokens are the source of the issue anyway, but I think that's the case as I seem to remember tracing this back to the token_generate call in the invoice preprocess function.
Comment #9
longwaveThe 'entity token' => FALSE feature we requested and that was added to Entity in #1280266: 'entity token' flag does not work any more was removed in the exact commit that causes this issue; I discovered this when trying to use that to avoid this problem.
The patch in #1 results in the [order:products] token returning "Property 0, , , , , , , , , , , , , , , , Property 16" on a sample order with 17 products which implies there is something not right with it, but I still don't understand enough of Entity API/Tokens to figure out what the correct fix is.
Comment #10
longwaveI still think this is just masking the real problem, but it works and I think we need to bring back that "entity token" option in Entity itself before this can be fixed in an better way.
Comment #12
pixelsticks commentedOpened new issue.