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)
  1. The workbench_moderation_messages doesn'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) @see screenshot in #2
  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 therefore workbench_moderation_messages ends up thinking it's on the published node and also renders the published node due to entity_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

joelpittet’s picture

Ok 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.

Screenshot_2013-06-15_11_43_PM-2.png

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:

Screenshot_2013-06-16_12_21_AM.png

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:)

joelpittet’s picture

StatusFileSize
new101.63 KB

I have a work around for the issue

If I remove the Entity "Rendered Node" from the panel page and left a "Node Content", the Moderation Information disappears...

I needed to uncheck the "No extras" checkbox for Node content.
Screenshot_2013-06-16_1_24_AM-2.png

joelpittet’s picture

Ok so what I did in #2 helped pretty much everything.

The problem boils down to:

  1. The workbench_moderation_messages don'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)
  2. Enity -> "Rendered Node" somehow overrides the work done in workbench_moderation_node_view_draft() to pass the page callback the write node revision and workbench_moderation_messages ends 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.

joelpittet’s picture

Issue summary: View changes

added related issue

joelpittet’s picture

Status: Active » Needs review
StatusFileSize
new664 bytes

This 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.

joelpittet’s picture

Issue summary: View changes

Using issue template.

Status: Needs review » Needs work

The last submitted patch, 2020325-4-entity-data-from-context.patch, failed testing.

merlinofchaos’s picture

I 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.

joelpittet’s picture

@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?

merlinofchaos’s picture

Create 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.

merlinofchaos’s picture

Well, correctly if you're not using revisions. :)

merlinofchaos’s picture

Issue summary: View changes

Updated issue summary.

wwhurley’s picture

The 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.

wwhurley’s picture

Issue summary: View changes
StatusFileSize
new794 bytes
scalp’s picture

Patch 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.

bburg’s picture

Patch #11 works on entity 1.3 as well.

joelpittet’s picture

thanks @wwhurley, good catch:)

specky_rum’s picture

Any 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.

sylus’s picture

Project: Workbench Moderation » Entity API
Component: Code » Core integration

I 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.

thelmer’s picture

StatusFileSize
new1.67 KB

Here's a new patch where using the entity from context can be enabled/disabled

joelpittet’s picture

Project: Entity API » Chaos Tool Suite (ctools)
Version: 7.x-1.3 » 7.x-1.x-dev
Component: Core integration » Code
Status: Needs work » Needs review

This 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.

joelpittet’s picture

Project: Chaos Tool Suite (ctools) » Entity API
Component: Code » Core integration
StatusFileSize
new634 bytes

Whoops 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 --relative so the patch is relative to the module and not your site root.

The last submitted patch, 11: 2020325-10-entity-data-from-context.patch, failed testing.

The last submitted patch, 17: 2020325-entity-data-from-context-17.patch, failed testing.

vflirt’s picture

Hi,

maybe we should follow what ctools module is doing for node_content and do :

  $entity = isset($context->data) ? clone($context->data) : NULL;
  if (empty($entity)) {
    $block->content = '';
  }
  else {
    $block->content = entity_view($entity_type, array($entity_id => $entity), $conf['view_mode']);
  }
vflirt’s picture

Here is the patch

joelpittet’s picture

Status: Needs review » Needs work

Thanks @vflirt it's probably a good idea to clone that object I bet:)

Couple of things.

  1. +++ b/ctools/content_types/entity_view.inc
    @@ -113,8 +113,13 @@ function entity_entity_view_content_type_render($entity_type, $conf, $panel_args
    +  $entity = isset($context->data) ? clone($context->data) : NULL;
    

    Clone is not a function but I do like this idea. drop the parenthesis.
    @see http://ca2.php.net/clone

  2. +++ b/ctools/content_types/entity_view.inc
    @@ -113,8 +113,13 @@ function entity_entity_view_content_type_render($entity_type, $conf, $panel_args
    +  if (empty($entity)) {
    +    $block->content = '';
    +  }
    +  else {
    +    $block->content = entity_view($entity_type, array($entity_id => $entity), $conf['view_mode']);
    +  }
    

    This feels a bit overkill. Is there case where the data property is a NOT NULL but also not an object?

vflirt’s picture

Was copying from ctools without looking in smallest details so that is why the brackets were left there :)

This feels a bit overkill. Is there case where the data property is a NOT NULL but also not an object?

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.

alcroito’s picture

Patch in #24 seems to work for me fine.

joseph.olstad’s picture

Patch #24 working for us as well

joelpittet’s picture

+++ b/ctools/content_types/entity_view.inc
@@ -113,8 +113,13 @@ function entity_entity_view_content_type_render($entity_type, $conf, $panel_args
+  $entity = isset($context->data) ? clone($context->data) : NULL;
+  if (empty($entity)) {
+    $block->content = '';
+  }
+  else {
+    $block->content = entity_view($entity_type, array($entity_id => $entity), $conf['view_mode']);
+  }

Better 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?

  if (!empty($context->data)) {
    $entity = clone $context->data;
    $block->content = entity_view($entity_type, array($entity_id => $entity), $conf['view_mode']);
  }
  else {
    $block->content = '';
  }
damienmckenna’s picture

Somewhat 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.

netw3rker’s picture

Status: Needs work » Needs review
StatusFileSize
new825 bytes

@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!

twod’s picture

The 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-argument instead of rendering an empty string just in case? Could these ever get out of sync so that $context->argument is not set but $context->data is? If so, should we not get the entity id from $context->data?

paranojik’s picture

Gorka Guridi’s picture

+++ b/ctools/content_types/entity_view.inc
@@ -113,8 +113,13 @@ function entity_entity_view_content_type_render($entity_type, $conf, $panel_args
-  $entity = entity_load_single($entity_type, $entity_id);
-  $block->content = entity_view($entity_type, array($entity_id => $entity), $conf['view_mode']);
+  if (!empty($context->data)) {
+    $entity = clone $context->data;
+    $block->content = entity_view($entity_type, array($entity_id => $entity), $conf['view_mode']);
+  }

Probably would be simpler to keep the fallback to the published version of the node instead of returning empty.

$entity = isset($context->data) ? clone $context->data : entity_load_single($entity_type, $entity_id);
$block->content = entity_view($entity_type, array($entity_id => $entity), $conf['view_mode']);

@paranojik yes, I also think the issues are duplicated, but the solution offered here looks more elegant.

mingsong’s picture

Here is a solution from the duplicated post #2057751:

https://www.drupal.org/node/2057751#comment-11504577

Sneakyvv’s picture

Where 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.

Status: Needs review » Needs work

The last submitted patch, 36: entity-ctools-content-type-from-context-2020325-36.patch, failed testing.

joseph.olstad’s picture

Status: Needs work » Needs review
StatusFileSize
new711 bytes

This 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.

pcambra’s picture

Title: node_view pages not showing draft node in node/%node/draft page. » Entity view CTools plugin doesn't load the correct revision
pcambra’s picture

Status: Needs review » Reviewed & tested by the community

RTBC'ing this one as the code is much simpler and cleaner than #2057751: revision support in ctools entity_view

dariogcode’s picture

I 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.

ludo.r’s picture

I also spent a day before understanding the issue was coming from entity.
#38 works fine!

khoomy’s picture

#31 works for me with panels, entity cache

sgdev’s picture

Patch #38 still applies cleanly to the latest Entity 7.x-1.10 release.

summit’s picture

Hi, 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