In views_panels_handler_relationship_panelizer_entity class, the relationship is created by matching the panelizer entity_id to the entity base - such as the NID of a node. If the entity has multiple revisions, the views query ends up creating multiple results. As far as I can tell, we can't display a link to the revision or anything that would distinguish one of the listings from another. There's nothing in the defined relationships that gives access to a revision ID other than the current one. There'd have to be a relationship to the node_revision table.

One way to fix this would be to instead match the panelizer entity revision_id to the entity revision ID, or vid, which is saved in the base table. I think this is safe to do now, because the panelizer integration currently only supports nodes, not other entity types.

For the future, taxonomy terms and fieldable panels panes have a vid column on the base table, but users and managed files do not. You'd have to fall back on the base field if a revision field is not present.

CommentFileSizeAuthor
#5 views_panels-duplicate-rows-2896562-5.patch1.68 KBdsnopek
#5 interdiff.txt1.88 KBdsnopek
#2 views_panels-duplicate-rows-2896562-2.patch1.26 KBcboyden

Comments

cboyden created an issue. See original summary.

cboyden’s picture

cboyden commented
Assigned: cboyden » Unassigned
Status: Active » Needs review
StatusFileSize
new views_panels-duplicate-rows-2896562-2.patch1.26 KB

Here's a patch that uses the revision ID to create the relationship. With this patch, there is only one result per pane per page, which points to the current revision.

cboyden’s picture

cboyden commented

Another wrinkle would be if workbench_moderation or something similar were in use. In that case, you might want to see pane usage on pending as well as current revisions. Which would require a relationship to node_revision and a means to specify in the view whether you wanted to look at just the current revision or not.

dsnopek’s picture

dsnopek
he/him
Primary language English
Location USA
commented
Assigned: Unassigned » dsnopek
Status: Needs review » Needs work

Thanks!

+++ b/includes/views_panels_handler_relationship_panelizer_entity.inc
@@ -47,14 +47,15 @@ class views_panels_handler_relationship_panelizer_entity extends views_handler_r
-      'field' => $base_field,
+      'field' => 'vid',

Hard-coding 'vid' isn't quite right, though - some entity types call this field something else (like 'revision_id'). We should look it up off the entity info. My goal with this handler is to allow us to use it for all the Panelizer entity types (even though it isn't currently)

Another wrinkle would be if workbench_moderation or something similar were in use. In that case, you might want to see pane usage on pending as well as current revisions. Which would require a relationship to node_revision and a means to specify in the view whether you wanted to look at just the current revision or not.

Yeah... I'm thinking maybe we should have configuration for whether you want to limit it to the current revision or not. Joining to the revision table itself (like node_revision) would be a different relationship, but maybe we could use the same handler class? Having a relationship to the revision table should probably be another issue, but here lets handle the configuration part.

I'm gonna take a shot at improving this patch

dsnopek’s picture

dsnopek
he/him
Primary language English
Location USA
commented
Status: Needs work » Needs review
StatusFileSize
new interdiff.txt1.88 KB
new views_panels-duplicate-rows-2896562-5.patch1.68 KB

Ok, here's an updated patch that I hope makes the handler generic enough to work with any entity type, and configurable enough that we could use the same handler class for a relationship with the revision table (like we'd need to do for workbench_moderation support). But I haven't actually tested it with a non-revisionable entity or workbench_moderation, so who knows :-)

cboyden’s picture

cboyden commented
Status: Needs review » Reviewed & tested by the community

Tested this patch locally and it looks good. The logic makes sense.

  • dsnopek committed 0a6ab77 on 7.x-1.x authored by cboyden 
    Issue #2896562 by dsnopek, cboyden: Duplicate rows returned when...
dsnopek’s picture

dsnopek
he/him
Primary language English
Location USA
commented
Status: Reviewed & tested by the community » Fixed

Thanks, committed!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.