The entity API function entity_save does only take single entities, it cannot handle entity arrays. When the aggregation property is set on an action via hook_action_info we need to save the entities one by one after performing the action.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | 1345750-entity-save.patch | 3.8 KB | bojanz |
| #2 | 1345750-entity-save.patch | 3.8 KB | bojanz |
| 0001-Fix-saving-entities-for-actions-with-aggregation.patch | 2 KB | znerol |
Comments
Comment #1
bojanz commentedChanging status so that I see this the next time I go on a commit spree.
The patch is very close to what I can commit.
We need the API to be clearer on this.
I'm going to modify the execute() method and _views_bulk_operations_operation_do() to always accept $entities, and modify the processing functions to provide array($entity) in case there's only one.
That removes the need for us to change the datatype manually in the patch, we just need the foreach and we're done.
I will make these changes and commit, you don't need to do anything.
Thank you for bringing this issue to my attention, and providing a patch.
Comment #2
bojanz commentedI have this committed locally.
Won't have git access until tomorrow, pushing it then.
Comment #3
bojanz commentedWhoops, the previous patch is reverse.
Comment #4
znerol commentedThanks for the patch. I quickly tested it with my custom actions on top of todays git head, it works.
I'm not the person picking on other peples code. I for myself prefer being as specific as possible for parameter and varialbe names, therefore I suggest using
$entitiesinstead of$data.Comment #5
bojanz commentedYes, but the problem with that is that it's invalid half of the time.
Sometimes $entities contains just one entity, and sometimes an $entity contains multiple entities.
And I can't force it to be an array always because Rules complains, and going around that is then an ugly hack in the Rules integration code.
So I went with $data which I also hate :) Good enough, I guess.
Pushed the fix.