Problem/Motivation
Draft page on a node_view panel's templated page will show the draft content, published content always shown.
- Panels 7.x-3.3 with node_view overwriting article pages.
- Workbench Moderation 7.x-1.x-dev (Tried 1.3 and 2.x as well)
- The
workbench_moderation_messagesdoesn't show up unlessnode_view()is called and in panels that is Enity -> "Rendered Node" or Node -> "Node Content" (with no extra's unchecked) @see screenshot in #2 - Entity -> "Rendered Node" somehow overrides the work done in
workbench_moderation_node_view_draft()to pass the page callback the correct node revision and thereforeworkbench_moderation_messagesends up thinking it's on the published node and also renders the published node due toentity_load_single()not caring about the revision id in the context. @see screenshot in #1
Proposed resolution
Not exactly sure but reading through similar issues regarding panels and moderation there may be an issue with how panel's gets the node content?
Possibly allow entity_load_single() to check if entities support revisions and pass that along as well.
Remaining tasks
@todo.
User interface changes
N/A
API changes
N/A
Comments
Comment #1
joelpittetOk went down the rabbit hole (read: ran debugger).
So the issue I am having is that I am rendering an entire entity "Rendered Node" into a panel pane. The context going in is fine but when it hits
entity_entity_view_content_type_render($entity_type, $conf, $panel_args, $context)It grabs the context's argument (nid), and calls entity_load_single(), which doesn't care at all about the revision id at all (vid) and essentially ignores the context when rendering the node.See screenshot for debugger data.
So after found that, I added "Node Content" and that shows the DRAFT content correctly but the block on the page is still not showing that it's the draft note (in Drupal blocks or Panels Misc block). See below:
If I remove the Entity "Rendered Node" from the panel page and left a "Node Content", the Moderation Information disappears...
And I guess the worst bit is that I have to duplicate the Variants between "nodedraft" page and "node_view"
Maybe I am going about this in totally the wrong direction... but my thought is that nodedraft shouldn't need to exist at all, or only if you want to get creative... maybe but it should be explicit that it's only for that.
The trick is getting Revision ID passed along to the entity loading mechanisms on ctools.
Hope someone could point me in the right direction, and if I can help I don't mind writing up a patch:)
Comment #2
joelpittetI have a work around for the issue
I needed to uncheck the "No extras" checkbox for Node content.

Comment #3
joelpittetOk so what I did in #2 helped pretty much everything.
The problem boils down to:
workbench_moderation_messagesdon't show up unless node_view() is called and in panels that is Enity -> "Rendered Node" or Node -> "Node Content" (with no extra's unchecked)workbench_moderation_messagesends up thinking it's on the published node and also renders the published node due to enity_load_single() not caring about the revision id in the context.Hope that helps, sorry for the thought train.
Comment #3.0
joelpittetadded related issue
Comment #4
joelpittetThis patch is related to the entity module, so I may end up moving this issue or at least the patch over there.
Regardless, this fixes entity's rendered by
entity_entity_view_content_type_render()by using the context that was passed in.This fixes 2 (screenshots from #1). But doesn't address the messages missing when node_load/entity_load not getting called.
Comment #4.0
joelpittetUsing issue template.
Comment #6
merlinofchaos commentedI suspect that the reason there is a load there is that the process of viewing the data caches so that another view in a different view mode on the same object would no longer work.
You might attempt a clone, or see if there is a way to ensure that the load loads the correct revision.
Comment #7
joelpittet@merlinofchaos that patch does fix my case, but there may be some cases were this is undesirable. Thanks for reviewing. clone may be a good thing to do. I wonder if there is a scenario I could setup to test it doing this will negatively affect it?
Comment #8
merlinofchaos commentedCreate a panel with an entity context; add multiple versions of this pane in different view modes. They should each display correctly. Without your patch I believe they will; with your patch they might not.
Comment #9
merlinofchaos commentedWell, correctly if you're not using revisions. :)
Comment #9.0
merlinofchaos commentedUpdated issue summary.
Comment #10
wwhurley commentedThe patch takes out the $entityid variable which causes some issues since it's used later as the key in an array. Adding a new patch for that.
Comment #11
wwhurley commentedComment #12
scalp commentedPatch in #11 works. Prior to implementing my panels pages were not showing correct version on the draft tab. After implementing all tabs show correct versions.
Comment #13
bburgPatch #11 works on entity 1.3 as well.
Comment #14
joelpittetthanks @wwhurley, good catch:)
Comment #15
specky_rum commentedAny idea if this patch is going to make its way into entity API? I just downloaded the latest dev release and it's not there. Before I post an issue there is there a reason this might not be accepted? It certainly seems to fix the advertised issue which I was having myself too.
Comment #16
sylus commentedI hope this is okay but I am going to move this issue to entity api since the code changes reside in that module. Additionally might get some feedback on whether is correct approach.
Comment #17
thelmer commentedHere's a new patch where using the entity from context can be enabled/disabled
Comment #18
joelpittetThis isn't part of the entity api, it's ctools, but good idea we should move it to where the patches apply.
@thelmer that's a good idea too, let's see what approach is the best for this bug.
Comment #19
joelpittetWhoops i'm an idiot, sorry it is entity api, my bad. Haven't look at this in a while. #11 patch is simple enough, though when creating the patch use
git diff --relativeso the patch is relative to the module and not your site root.Comment #23
vflirt commentedHi,
maybe we should follow what ctools module is doing for node_content and do :
Comment #24
vflirt commentedHere is the patch
Comment #25
joelpittetThanks @vflirt it's probably a good idea to clone that object I bet:)
Couple of things.
Clone is not a function but I do like this idea. drop the parenthesis.
@see http://ca2.php.net/clone
This feels a bit overkill. Is there case where the data property is a NOT NULL but also not an object?
Comment #26
vflirt commentedWas copying from ctools without looking in smallest details so that is why the brackets were left there :)
I am not 100% sure I understand what you mean. The "data" property of $context is presumably an entity object but can't be 100% certain as it is possible to change the panel arguments so can't count on it 100%. Again as I said I have copied it from ctools module without thinking in the smallest details and putting a bit of faith in it but that might be wrong.
Comment #27
alcroito commentedPatch in #24 seems to work for me fine.
Comment #28
joseph.olstadPatch #24 working for us as well
Comment #29
joelpittetBetter context:
If $context->data property is set(NOT NULL essentially), clone it, then check if that cloned object is empty.Why not skip to the check right from the start?
Comment #30
damienmckennaSomewhat related to this, CTools v7.x-1.6 includes a patch from #1820882: Make node revisions use the node_view display that makes CTools use page_manager for node revision displays if it's configured to manage node_view.
Comment #31
netw3rker commented@damienMcKenna is right, this affects every revisionable entity. I ran into this today as well with the taxonomy_revision module (I'm adding panels support for it). I think this comes down to the idea that the pane renderer should accept the context data given to it rather than re-loading the entity since the context value should be the result of _load arguments from the menu hook.
@joelpittet, I agree with you on this, why do two checks if only one is needed. Attached is a re-roll with your logic in it. It'd be great to see this go in!
Comment #32
twodThe patch from #31 works well for me. I have a custom CTools relations plugin which grabs the latest node revision (using Revisioning module) and create a new node context from it. Without this patch I would have to re-implement the entity_view content_type plugin to have it actually render the node from this new context in a Panels pane.
This patch introduces a change in the plugin's behavior, though I don't currently know of any code which will be affected. Maybe fall back to loading the entity based on
$context-argumentinstead of rendering an empty string just in case? Could these ever get out of sync so that$context->argumentis not set but$context->datais? If so, should we not get the entity id from$context->data?Comment #33
paranojik commentedThis is related (possibly duplicate of) #2057751: revision support in ctools entity_view.
Comment #34
Gorka Guridi commentedProbably would be simpler to keep the fallback to the published version of the node instead of returning empty.
@paranojik yes, I also think the issues are duplicated, but the solution offered here looks more elegant.
Comment #35
mingsongHere is a solution from the duplicated post #2057751:
https://www.drupal.org/node/2057751#comment-11504577
Comment #36
Sneakyvv commentedWhere is this issue going?
#2057751: revision support in ctools entity_view is a duplicate, but that one has been RTBC'd, not committed though.
I agree with @Gorka Guridi that this solution seems more elegant. On the other hand, the extra code that the solution in #2057751: revision support in ctools entity_view contains, has perhaps its merits.
Either way, the patch from #31 here is working for me. My patch is keeping the fallback as @Gorka Guridi suggested. It's less intrusive since it's largely keeping the original code.
Comment #38
joseph.olstadThis is a reroll of patch 36 , patch 36 did not apply.
I'm not sure which is better, 31 or this patch (38)
apparently patch 24 also works.
see test results.
Comment #39
pcambraComment #40
pcambraRTBC'ing this one as the code is much simpler and cleaner than #2057751: revision support in ctools entity_view
Comment #41
dariogcode commentedI debugged last two days until found this was an issue in entity API :D, patch in #38 works like a charm. Ready to be integrated.
Comment #42
ludo.rI also spent a day before understanding the issue was coming from entity.
#38 works fine!
Comment #43
khoomy commented#31 works for me with panels, entity cache
Comment #44
sgdev commentedPatch #38 still applies cleanly to the latest Entity 7.x-1.10 release.
Comment #45
summit commentedHi, Where do I add patch #38 on latest Entity 7.x-1.10 release?
I do not see a ctools/content_types/entity_view.inc folder?
EDIT: I found it. It is on Entity module, not on Ctools. It works!
Could this patch please be committed?
greetings, Martijn