Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.We always take the entity id:
list($entity_id) = entity_extract_ids($entity_type, $entity);
If the table is a revision table, we should take the $revision_id instead, because the rows are keyed by that.
Same thing needs to happen in views_megarow_preprocess_views_view_table().
The best way would be to implement a isRevision (or similarly named) method on the field handler, and use that to determine which id to take in both places.
Of course, page callbacks that need to load the entity will need the "is_revision" flag passed, along with the entity type.
| Comment | File | Size | Author |
|---|---|---|---|
| #15 | 1802438-15-get_result_entities_revisions.patch | 2.68 KB | andrewbelcher |
| #5 | result_entities_for_revision-1802438-5.patch | 6.94 KB | vasike |
| #3 | result_entities_for_revision-1802438-3.patch | 7.02 KB | vasike |
Comments
Comment #1
bojanz CreditAttribution: bojanz commentedChanging title, since the problem exists in the module as well.
Comment #2
peter-boeren CreditAttribution: peter-boeren commentedHey Bojanz,
I just ran in to this issue. Has there been any progress on this? Because for a project we would like to integrate Megarows with workbench. A few of the views Workbench supplies are based on revisions. If no work has been done, could you provide a few handles so we can implement the changes ourselves?
Comment #3
vasikeit seems like Views issue.
bojanz pointed to an 8.x-3.x-dev Views issue (#1758634-15: The query plugin should load entities after the query has been executed) and its solution http://drupalcode.org/project/views.git/commit/6661020ca5ba7d5c41d2ec74b...
here is a patch that aims to adapt bojanz solution for 7.x-3.x-dev.
Comment #5
vasikepatch corrected
Comment #7
peter-boeren CreditAttribution: peter-boeren commentedHi Vasike, I will test your patch soon. Thanks in advance for the effort.
Comment #8
vasikehere is a new patch. move query groupby, after getting base field for entity table.
i hope it will pass the tests.
Comment #10
vasikenew patch - get_result_entities() in execute()
Comment #12
andrewbelcher CreditAttribution: andrewbelcher commentedHopefully I'm not missing anything as my patch is significantly smaller and simpler than some of the others (it's not a direct port of the D8 stuff, more just trying to make D7 work with revisions)... But here is a simple patch.
- We add the
$data[TABLE]['table']['revision']key (node is the only core entity that supports revisions right?)- If the table we're working on is the revision table, we load via
node_revision_load()if the entity type is a node, otherwise we look for entity so we can useentity_revision_load(). If we can't get either, we trigger aWATCHDOG_NOTICEexplaining the problem.This seems a simple enhancement that isn't going to break anything core, but enables other modules to do a lot more (for example VBO can make itself work with Search API - #1334374: Re-use generic entity views table).
Comment #13
andrewbelcher CreditAttribution: andrewbelcher commentedD'oh,
node_revision_load()is D8 only, have updated the code for the somewhat hacky D7 equivalent...Comment #15
andrewbelcher CreditAttribution: andrewbelcher commentedSorry, not having a good end of the day, uploaded the wrong files... Here we go...
Comment #17
stefanotabarelli CreditAttribution: stefanotabarelli commentedWe have been using this patch for more than 10 months on our platform and it seems to work really well so I wanted to give credit to the author and update the status of this patch to RTBC.
Comment #18
DamienMcKennaComment #21
dawehnerIts good to know that we have someone actually manually using that patch. Its a bit sad what is needed to support revisions, but this is life.
Committed and pushed to 7.x-3.x