I have a content type "Show" and a content type "Venue". Show has an entity reference field "show_venue" referencing a single Venue.

Both content types are revisioned by the Revisioning module.

I have a Show node with two revisions - one published/current, the other unpublished/pending. Each of those reference a different Venue node.

In Views, I add a relationship: Venue referenced from field show_venue.

If I add the show_venue field directly (no relationship), it correctly displays the title of the Venue node referenced from the current/published revision of the Show node.

If I add the Venue title field, using the relationship, this displays the title of the Venue node referenced from the latest unpublished/pending revision of the Show node.

Shouldn't the relationship be using the published version of the referenced entity?

CommentFileSizeAuthor
Picture 1.png123.91 KBjohnpitcairn

Comments

johnpitcairn’s picture

johnpitcairn commented
Title: Views relationship: referenced entity displays field from unpublished revision » Views relationship: referenced entity displays unpublished field content
Project: Entity reference » Revisioning

Hmm ... actually I think this might be a Revisioning issue. If I use Entity Revision Scheduler instead, I see the field content for the current/published revision as expected.

rdeboer’s picture

rdeboer
Location Melbourne
commented

Hi John,
Thanks for reporting.
Before starting up my development environment to get into this deeper some time soon, I'd say that where a node_load() is involved Revisioning will do the correct thing, as it implements hook_node_load(). However where entity_load() is involved the latest revision of the entity in question will always be loaded, as per core behaviour.
Rik

johnpitcairn’s picture

johnpitcairn commented

Thanks - I appreciate the distinction between node references and entity references, but the nodereference module is more or less deprecated for Drupal 7. The replacements are all entity reference modules.

rdeboer’s picture

rdeboer
Location Melbourne
commented

I guess you're saying you want Revisioning to become an entity-revisioning module with node-revisioning being a special case of that.....

johnpitcairn’s picture

johnpitcairn commented

Yeah - support Entity API so things work as users might reasonably expect, but limit your support to node bundles.

rdeboer’s picture

rdeboer
Location Melbourne
commented

Hi John,
I can reproduce your test case up to the point where you add a field to show the title of the Venue.
In may case no title field is available....
I presume, like me, you have the Entity Reference module enabled? I used 7.x-1.0-beta4
In VIews (7.x-3.1) UI, section Relationships I get two options for the Entity Reference. One has the word Content in it once, the other twice.
With either of them I don't get offered a field to show the Venue Title. When I choose the Venue field, nothing gets displayed apart from the Show title.

You may have more luck with the References module (7.x-2.0), which features forward and backward references and in my case the correct Venue was attached to the published revision of the Show.
Let us know how you went.

Rik

johnpitcairn’s picture

johnpitcairn commented

Unfortunately it's a little too late for me to back out of using Entity Reference on this site, there are hundreds of nodes involved and no migration path back to References. The References page makes interesting reading - it's the D7 version of Nodereference, has a lot of issues open, and appears to be deprecated in favour of Entity Reference. I think we can see which way the wind is blowing here ;-)

To reproduce, in Views:

Add a field, using the Entity Reference field "Venue" (field_show_venue in my case) from the content type "Show". Do not use a relationship. Use the formatter "Label". This should display the referenced venue title when previewed.

Now add a relationship: Entity Reference: Referenced Entity - A bridge to the Content entity that is referenced via (your_venue_field_name).

Add a simple "Content: Title" field. Use the relationship you just added. This should also display the referenced venue title.

Change the Venue title, save without publishing, and preview the View again - the second field displays the changed (unpublished) revision title, while the former displays the current published revision title. Fun.

If you feel this is a bug in Entity Reference, I'm happy to move the issue back to that queue, though the correct behaviour when using ERS instead of Revisioning suggests to me the problem may indeed be that Revisioning sets the published node revision, vs setting the entity revision.

I may have some time to help out on this, if you're willing to look at making Revisioning entity-compatible. I don't really want to move all my clients to ERS or Workbench Moderation.

rdeboer’s picture

rdeboer
Location Melbourne
commented
Assigned: Unassigned » rdeboer

Thanks for that.
So I have a reproduceable test case now.

Initial diagnosis: when the View is executed hook_entity_load() and hook_node_load() get called for the Show and for the Venue.... once.
So the Venue displayed via the relationship doesn't go through the standard hooks, thus not giving Revisioning a chance to load the right one, as it does for Show node and its first Venue (the one that does not use a relationship).

The challenge will be to delve deeply into the bowels of Views to see if some other hook can be used for implementation in Revisioning.

Could be a tough nut, this one....

Rik

johnpitcairn’s picture

johnpitcairn commented

Ack. That's not what I was expecting.

It's probably worth noting that if you remove the first Venue field, so there is only only Venue field, the one using the relationship, the problem persists. Is node_load still being called for the Venue?

johnpitcairn’s picture

johnpitcairn commented

Huh. It appears neither hook_node_load or hook_entity_load are called for entities loaded in a view through an entity_reference relationship. Might that indicate an entity_reference or views bug?

Though I'm not sure that hook_node_load and hook_entity load are required to be called at all if a module (Views) is querying the database directly, as opposed to loading through node API or entity API calls?

rdeboer’s picture

rdeboer
Location Melbourne
commented

Re #10, #12
Yes, after removing the Venue-without-relationship from the Show view, leaving just the title of the Show and the Venue-WITH-relationship, hook_entity_load() and hook_node_load() don't get called at all. All information gets pulled in by the SQL query generated by Views.

Which means it loads the latest version of the Venue entity, regardless.

johnpitcairn’s picture

johnpitcairn commented

OK. Just trying to get my head around this - why is relying on hook_node_load a reasonable strategy for Views support in Revisioning, for any node/entity type? Why expect it to be called at all when all Views output is generated by SQL query?

I'll perhaps take a closer look at how ERS produces the expected result. Its codebase is fairly small, well organized and well commented at present.

johnpitcairn’s picture

johnpitcairn commented

The plot thickens:

When using ERS, on node update the database field_data_your_field_name table's revision_id for the reference field remains set to the published (node) entity revision id.

Using Revisioning, on node update the reference DB field is immediately set to the new (node) entity revision id.

Then if Revisioning is used to delete the new, unpublished node revision, the referenced DB field's revision_id remains set to a now non-existent field revision (see the DB field_revision_your_field_name table).

Interestingly, directly manipulating the DB values then flushing caches/running cron has no effect on the View display - the referenced field continues to display a supposedly non-existent value.

Hmmm. Any thoughts?

rdeboer’s picture

rdeboer
Location Melbourne
commented

Hi John,
If I remember correctly the View query for our test case does its joins on the nid and the revision_id doesn't come into it.
Rik

johnpitcairn’s picture

johnpitcairn commented

Yes, you're right. And the query is identical regardless of the revision-control module used. Workbench Moderation and ERS both manage to save the node entity so that the current revision is respected by the query, Revisioning doesn't.

ERS appears to be using its own DB table to match current revision id to entity id, running a node_save() when it publishes a revision, and cleaning up in hook_exit() using cached data. I haven't looked at Workbench Moderation yet.

Unfortunately this site is now too close to handoff for me to continue investigating, I think I'll have to give them Workbench Moderation. I will attempt to come back to this in the future as I much prefer the way Revisioning operates, and its API hooks.

johnpitcairn’s picture

johnpitcairn commented

FWIW, in Workbench Moderation's case, the situation is handled by registering a shutdown function in workbench_moderation_moderate():

// If we're moderating an unpublished revision and there is an existing
// published revision, make sure that the published revision is live.
// We do this in a shutdown function to avoid race conditions when
// running node_save() from within a node submission.

cursor’s picture

cursor commented

Is this still the case with revisioning? Should I use node reference instead of entity reference in this case?

rdeboer’s picture

rdeboer
Location Melbourne
commented

@cursor, #18
Probably, as there have been no recent changes to Revisioning in this area.

T1ckL35’s picture

T1ckL35 commented

Hi,
Has there been any progress on this?
I've recently set up revisioning but have come across the same issue as described above.
If it is still in the same state then I'll probably have to ditch revisioning (which is nice to use) and move onto workbench moderate or similar :(

rdeboer’s picture

rdeboer
Location Melbourne
commented

There has been no more progress on this.
Patches welcome!
Rik

ptmkenny’s picture

ptmkenny commented

I actually wanted the most recent version on my site, so I tried to replicate this bug (my site uses the Relation module instead of Entity Reference). However, I was unable to reproduce this bug with the Relation module; when I add a Relation relationship and then show field values, I get the values of the published node, not the values of the pending revision.

So, for those of you running into this bug, using Relation instead of Entity Reference may be one solution.

loziju’s picture

loziju commented

I noticed similar problem when I used version 7.x-1.4. I was investigating whether it was due to entityreference, entity or revisioning modules. Interestingly, updating revisioning to version 7.x-1.5 or 7.x-1.x-dev seems to fix the issue, contrary to what Rik mentioned in #21, unless of course if I misunderstood this issue entirely. :)

For my use case it's multiple value entityreference field. So continuing on John's example it's one `Show` node can reference multiple `Venue` nodes.

Here is my observation with version 1.4:

  1. Adding new `Venue` will render it straightaway in the views (unexpected)
  2. Editing old `Venue` doesn't reflect the unpublished revision in the views (expected)
  3. Reverting to `Show` old revision doesn't seem to change the views — the newly added `Venue` is always shown regardless the revision reverted to (unexpected)
  4. Diff-ing the `Show` revisions doesn't show the actual difference (unexpected)
  5. `Show` node revision view (node/xxx/revision/yyy/view) incorrectly renders the views (unexpected)

This is my observation after update to 1.5/1.x-dev:

  1. Adding new `Venue` doesn't render it straightaway in the views (expected)
  2. Editing old `Venue` doesn't render the unpublished revision in the views (expected)
  3. Reverting to `Show` old revision correctly renders changes to the views (expected)
  4. Diff-ing the `Show` revisions doesn't show the actual difference (unexpected)
  5. `Show` node revision (node/xxx/revision/yyy/view) doesn't show the correct `Venue` being referenced in that revision (unexpected)

Rik, anything changed from 1.4 to 1.5 that can explain the above difference?

rdeboer’s picture

rdeboer
Location Melbourne
commented

Hi liziju
Thank you for the time you put into this.
I'm a little confused though.

Your write " Interestingly, updating revisioning to version 7.x-1.5 or 7.x-1.x-dev seems to fix the issue"
But then you have a list of "unexpected" observations.

So do we or do we not have a problem and exactly what is it?

loziju’s picture

loziju commented

Hey Rik, sorry about the whole list being a bit confusing. If only I could add colours to comment....

Let me try to make it a bit clearer. When I said that 7.x-1.5 fixes the issue, it's mainly for items 1 and 3. These 2 items, to my understanding, are what John reported in the first place. From my little experiment, these 2 items seem to be fixed as they behave as expected in 7.x-1.5.

Items 4 and 5 are "less" important for me at this moment as these only affect admin users. They can't see any entityreference field difference in both diff (node/xxx/revisions/view/yyy/zzz) and revision view (node/xxx/revision/yyy/view). These 2 probably belong new issue threads altogether, but I just mention them here for completeness.

delacosta456’s picture

delacosta456 commented
Issue summary: View changes

hi
i was facing similar situation with entityreference field where a referenced node where not displaying if both node and referenced node are not published.. i finally solve this by usinf this Entity reference unpublished (sandbox module) which provide more formatter for entityreference field in the display tab "(Rendered Entity (all))".

i haven't tried it by creating custom view to know if the formatter is available for view. may you could try it

hope it will help.

thaks