Attached CSS and JS files are not loaded

Here is a patch.

After doing the latest security update we also ran into this problem.
I've updated the patch and moved the comment for the changed code.

The patch #5 is working for me :)

Works for me too. Committed!

I thinks this commit needs to be reverted.

Moving node_page_view() at the end only prevents that function to be called when page manager is active for node_view, how that can solve the issue?

Has this resolution been arrived by accident? or is there any explanation?

Some modules add js and css files to the content array theme $node->content['#attached']. It is proccesed on drupal_render (https://api.drupal.org/api/drupal/includes%21common.inc/function/drupal_...), so we just need to call this function. There is not a problem if it's called again, because it does a check on the #printed element to prevent more than one call.

I reversed this commit (git revert e18e4acc63bae99ffc2ecc7ace13cdace8936084) and applied the patch attached an it solves the display suite issue and others issues related with JS files (statistics ajax).

Thanks for opening this issue!

+++ b/page_manager/plugins/tasks/node_view.inc
@@ -80,7 +80,7 @@ function page_manager_node_view_menu_alter(&$items, $task) {
-  $default_output = node_page_view($node);
+  $default_output = drupal_render(node_page_view($node));

drupal_render() expects a reference. You need to separate the two function calls for this to work.

Thanks @joelpittet, attached is the new patch.

Thanks that should work, not sure if the solution is correct but let people mull over your explanation in #10

Can someone please test if this is fixed by #2422123: should entity view hooks be triggered unconditionally in node_view, term_view and user_view pages??

In response to #15, it looks like the commit in this issue (#8) introduces a regression that re-opens #1760384: Update node_view.inc to execute the normal Drupal hooks. That is tangled with #2422123: should entity view hooks be triggered unconditionally in node_view, term_view and user_view pages? as #2422123 is basically a follow-up to #1760384.

It's actually quite possible that this issue is a dup of #2422123: should entity view hooks be triggered unconditionally in node_view, term_view and user_view pages?, and that the problems described are related to the fact that node build/rendering (including view hook invocation) can happen redundantly in certain situations. I can't be 100% sure of that though. Issue #2422123 is trying to fix all that while still preserving the functionality introduced in #1760384.

I'm marking as "needs work" due to this, but the right status may actually be "postponed" until #2422123: should entity view hooks be triggered unconditionally in node_view, term_view and user_view pages? gets resolved (and someone can verify if this even still applies then).

I think this issue might needs to be looked at again as it caused my following behat test to fail but as soon as I went one commit before it started to work again.

    Given I am logged in as a user with the "administrator" role
    When I visit "/node/add/page"
    And I fill in the following:
      | Title  | Published title |
      | Editor | plain_text      |
      | Body   | Published body  |
    And I select "Published" from "workbench_moderation_state_new"
    When I press "edit-submit"
    Then the "h1" element should contain "Published title"
    When I click "New draft" in the "Tabs" region
    And I fill in the following:
      | Title  | Draft title |
      | Editor | plain_text  |
      | Body   | Draft body  |
    When I press "edit-submit"
    Then the "h1" element should contain "Draft title"
      The string "Draft title" was not found in the HTML of the element matching css "h1".

Here is a patch for drush make purposes to roll back this commit on top of 1.9.

The code committed to 7.x-1.9, sha e18e4acc introduces a regression for me. I'm using a custom content pane with substitution like %node:field_image. This works when the image has a value other than the default, but the default value doesn't show up when the original patch is applied. Suggest reverting this patch in the next stable version of ctools.

The change related to this issue (commit e18e4a) introduces a regression for me, too. I have a site that uses Panelizer and Mini Panels to configure node layouts. The node titles are rendered in the node body (rather than at the page level) so I use the "Node" Title pane in the panelizer panel configurations. When I updated CTools from 7.x-1.7 to 7.x-1.9, I found that the "Node" Title panes (which should have contained the node title) were empty.

Here's a simple patch that reverts the change.

Here's a patch which reverts the change like #21 and apply the fix explained in #10

It applies on 7.x-1.9 and last dev.

Thanks!

Patch #22 works fine - displays defaulted image field and doesn't break Google map in other field.

Only problems with caсhing..

You may want to be careful with the extra drupal_render though (as in #22) - I'm using a node template override to render forums, and this causes the Advanced Forum comment preprocess to get called twice, which messes up comment counts.
That said, I'm not using Display Suite, just came here looking for a way to hook into node links - which works perfectly well by moving the node_page_view to the top, as it's done in #22.

#22 fixed the issue for us

I think there's a problem with this patch. I think the node hooks are being double invoked which causes some weird behavior (most notably with comments). If you render a node with the comments and comment form onto a page using Page Manager with the node_view page and have more than one page of comments, the pager stops working. You can only ever view the first page of comments. If you add "page=1,1" as if two pagers had been rendered the next page of comments can be viewed. Also the comment form id is "--2" at the end implying that Drupal has rendered that HTML element with that ID already at some point.

Rendering the node through page view arbitrarily at the top of the function seems to break stuff. The solution in #2422123: should entity view hooks be triggered unconditionally in node_view, term_view and user_view pages? to have node_page_view be called as a fallback works better (we aren't double invoking the node hooks).

I haven't tested things extensively yet but I can confirm that when we remove:

 function page_manager_node_view_page($node) {
  // Prepare the node to be displayed so all of the regular hooks are triggered.
  $default_output = node_page_view($node);

the comment pager and comment form work normally again.

I'm trying to help japerry get ctools-1.11 out the door.

Something related to this issue appears to be related to: https://www.drupal.org/node/2556253

The git commit is below. The patch in 2556253 is essentially a revert of this commit. Can anyone comment on what this was trying to achieve and whether the revert is acceptable?

git log -p e18e4acc63bae99ffc2ecc7ace13cdace8936084
commit e18e4acc63bae99ffc2ecc7ace13cdace8936084
Author: stborchert <stborchert@36942.no-reply.drupal.org>
Date:   Sat May 16 12:37:09 2015 -0700

    Issue #2437773 by stBorchert, teknocat: Attached CSS files are not loaded

diff --git a/page_manager/plugins/tasks/node_view.inc b/page_manager/plugins/tasks/node_view.inc
index ad754e0..89a2912 100644
--- a/page_manager/plugins/tasks/node_view.inc
+++ b/page_manager/plugins/tasks/node_view.inc
@@ -78,10 +78,6 @@ function page_manager_node_view_menu_alter(&$items, $task) {
  * node view, which is node_page_view().
  */
 function page_manager_node_view_page($node) {
-  // Prep the node to be displayed so all of the regular hooks are triggered.
-  // Also save the output for later, in case it is needed.
-  $default_output = node_page_view($node);
-
   // Load my task plugin
   $task = page_manager_get_task('node_view');

@@ -107,6 +103,9 @@ function page_manager_node_view_page($node) {
     }
   }

+  // Prepare the node to be displayed so all of the regular hooks are triggered.
+  $default_output = node_page_view($node);
+
   // Otherwise, fall back to the default output generated by node_page_view().
   return $default_output;
 }

I think this issue needs some attention.
We all know the patch that was accepted caused a huge regression issue.
Same here: https://www.drupal.org/project/ctools/issues/2556253#comment-12510438

Is this going to be fixed at all?
@joelpittet @japerry

The patch needs a reroll, and #29 concerns with the patch should be addressed.

It may be worth adding a regression test to prevent future issues as well.

re-roll patch in #22 against latest

#36 fixes the issue again for us with regard to default image.

Default images where working with #22. However, we did encounter css/js issues creating panel pages with #22.

#36 fixes the issues that we were having with added JS not being loaded.

Drupal 7 is no longer supported, closing.