Notice: Trying to get property of non-object in ctools_node_comment_form_content_type_render()

Some context would be helpful. What were you doing, how was it configured, etc.

Have you been able to reproduce this?

I'm getting this error after creating a node-type specific panel-layout (for an article-node). The page will render normally, as if the node-panel isn't applied.

Error can been seen only in the site-log and when clicking in this panel's overview tab. No global error message.

Notice: Trying to get property of non-object i ctools_node_type_ctools_access_summary() (line 98 of /home/www/new3.medmesh.org/sites/all/modules/ctools/plugins/access/node_type.inc).

However its line 98 (not 23/26), so it might not be the same problem as initial post.

Also, Im using CTool 7.1-alpha4 and Panels 7.3-alpha 3

Export of node-panel.

Thanks

I was able to recreate with the export above, however, part of the problem appears to be that the context for the individual content panes needs to be re-saved. (Need to go into each pane and click 'save')

As a mention, I believe the comments and comment form will be included by default if you include node:content

The other problem I'm seeing seems to stem from checking 'Panel title' in the settings for the node content pane. After re-adding the node content pane, I was able to remove all errors.

Thanks for looking into it. I'll have a look myself.

Do you consider it as a bug, or because I've simply configured wrong?

It's difficult to say because I'm not 100% sure what you're trying to do. It may be a bug - but if it is, I think there's a way around it. I've also run into the problem before of needing to resave panel panes after an upgrade.

I see. Looking at the export, I see what's going on. The context id for the argument changed; anything using the old ID gets random failures. CTools is lacking graceful validation and failure when this happens.

I checked in a fix that should be MUCH smarter about this.

I'm getting this with the current release, and looking at the code the immediate cause of the error is obvious: ctools_node_comment_form_content_type_render() starts by potentially setting $node to NULL, and then proceeds to unconditionally ask for $node->nid three lines later.

The same bug also exists in ctools_node_comments_content_type_render().

This is Panels Modules error. This is not related to CTools.

Basically you r not added properly context in your panel. if you want to display node comment in your panel.

goto add context option.

add node as context.

use appropriate node id for comment.

update and save the panel.

now every thing is working fine.

lalit774: Well it's "related to ctools" in so far as there is a bug in the ctools code, because in certain circumstances it is effectively doing this:

  $node = NULL;
  $foo = $node->nid;

Jweown: yes its only warning error with ctools. basically i go through this all stuff.

<?php
function ctools_node_comments_content_type_render($subtype, $conf, $panel_args, $context) {
  $node = isset($context->data) ? drupal_clone($context->data) : NULL;
?>

in above function context perm must be a object. if its not a object so it display the warning error.

in Ctool module if $context perm is not a object then display appropriate error message.

I am getting my comments in a menu tag on an every article and the front end is working, but I get the error when I try to preview in page manager. I tried the suggestion in #14, but it did not make the error go away.

I have tried adding comment context, node context (which is already there as Argument 1). I have tried adding a relationship of Comment from node. I don't know what to try next.

I know lalit774 said it was only a warning, but it is bugging me just the same.

In another custom page, I edited the default node/%node to display just the content section of the article type. It is also working fine, but the preview there is blank, but does not have an error.

Adding my export file. Oh, an I am using 7.x-1.0-rc1

Just realized I only exported the variant, and not the page. Here it is. I wish we could add files in the edit of these posts...

Here's a patch to prevent NULL->nid being asked for.

I don't know what $block->delta should actually be in this case. I've set it to NULL, but maybe the property simply shouldn't be set?

Thanks for the patch, which took are of the node_comment_form.inc file error. Got one for the node_comments.inc file that is generating the second error?

Ah, yes, that's essentially the same problem.

Similar enough that I'm wondering whether the if ($node->comment) in ctools_node_comments_content_type_render() should in fact match the line in ctools_node_comment_form_content_type_render() which is if ($node->comment == COMMENT_NODE_OPEN) ?

Here's a patch for both functions. I still have no idea whether my $block->delta = NULL is correct for the empty node case, but I expect the functionality would match the current code (just without the warnings being thrown).

Do you understand what #14 was trying to say? That I am missing some step and that is why these errors pop up? I don't see any way to get the node ID in a custom page that has as its only purpose to place a tab in the menu tag area for the node comments.

No, I don't know that #14 is relevant.

It sounded like they were looking into a reason why $context->data might not be set in the first place, but it seems highly unlikely that it would be the only possible reason.

The code I'm patching clearly expects that $context->data might be empty, so I'm just fixing an obvious bug in the code when that circumstance arises. I'm afraid I can't offer any insight into whether or not it was correct for that property to be empty at the time.

The patch in #22 seems to be changing an awful lot of lines -- reorganizing the logic -- unnecessarily. It's difficult to review but it looks like all it's really doing is making sure to not set a delta if $node doesn't exist? So why all the other changes around it?

I suspect the "Comment form goes here" text really shouldn't be there.

If $node does not exist, we should jsut return no block and not render anything.

It's clearer if you see the end result side-by-side with the original, but I was simply making more of the code depend on the empty($context->data) test than was previously the case, which seemed like a safer structure.

I was assuming that the code needed to return a block object in all circumstances, but if we can actually return NULL when $context->data is empty, then that certainly makes it even simpler.

I think you are right Mr Merlin.

I'm using panels & panels everywhere along with adaptivetheme & at_panels_everywhere. It's when comments are not enabled but are shown as an ouput as part of the at_panels_everywhere theme in the main content area, this error appears

Trying to get property of non-object in ctools_node_comments_content_type_render() (line 26 of sites\all\modules\ctools\plugins\content_types\node_context\node_comments.inc

Perhaps you're wondering why add a pane with the comments then - when comments are disabled (for article content type). The at_panels_everywhere theme came with this pane being placed in the main content region by default.

I am having the same issue as the OP on 7.x-1.2. Notice only appears in the "preview" of panel.

I found an issue in Panel that might be related, if this helps: http://drupal.org/node/1452022

It looks like the warning appears because there is no $context (or $node) variable available, if this makes sense.

This is strange because it happens when I try to render the comments for the node being viewed!
(plugin Node -> Node comments, "node being viewed").

In the actual panels, the comments show up, but the formatting is lost (zebra colors for example).

Can anyone point me in the right direction, so I can fiddle around a bit with the code and maybe find a workaround until a proper solution is found?

inno81: #22 is a perfectly serviceable solution, but it can be simplified even further as per #26 & #27

This fell off my radar, but if you'd like to roll the revised patch yourself, that would be handy.

Hi jweowu,

Thanks for the reply. I am not sure that #22 solves my issue:

The "notice" disappears, and in the preview I get "Node comments go here."
In the panel, the comments appear but they are not rendered in the same way as the "normal" rendered node, but lose the layout completely.
Is this a completely different issue?
I am new to Drupal so it's hard for me to see where source of errors are...

Yes, that would be a different issue. This one is purely about fixing the bug which causes that PHP notice.

I am still encountering this error. The attached patch is a bit simpler than #22. I added an if block to test for a NULL value in $node and then return a NULL value in $block if $node is NULL. Otherwise, the function does exactly what it did before my suggested patch.

Please don't credit your patch in the code; In Drupal, we apply credit with commit comments, not code comments.

Thank you for the guidance. I didn't mean to give myself "credit". I have included my initials in comments for changes I make to other's code for a long time just for my own benefit, but I will not do so when I submit code to any Drupal project. Sorry for any inconvenience.

Yeah, different projects are different. As an old and very well established project, we can be...very strict. :)

Reroll, changing comment and updating ctools_node_comment_form_content_type_render also to move mention of $node->nid

#40: 1098758-ctools-node-null-40.patch queued for re-testing.

Here's a patch that implements Merlin's suggestions (see #26 and #27). i.e.:

I suspect the "Comment form goes here" text really shouldn't be there.

If $node does not exist, we should just return no block and not render anything.

(This is the same as #43; I'm just correcting the patch filename for clarity's sake.)

Patch is almost there. I added a few other checks. This needs to be tested first by those who are seeing the issue.

I see I managed to miss a rather important line. Thanks for fixing!

You didn't need to split empty($context->data->nid) into empty($context->data) && empty($context->data->nid) though -- that single test encapsulates both cases; empty() won't complain if the parent doesn't exist.

Updated the patch as per #46.

(I wouldn't usually hide other people's patches, but we ended up with three different approaches, and I'm working on the assumption that the current approach is the most desirable, and therefore the older files are now just a distraction.)

The commit in #10 caused a side effect of the wrong context being chosen if the wanted one is missing and there is another one that works. Because the 43 comments after that are all trying to fix a bug, I didn't want to muddy the waters by starting a new conversation here so I put it in #2751165: Assuming ID has changed leads to wrong context selected.

Patch required reroll.

Patch seems reasonable: propose for RTBC?

I see the original code clone($context->data) has in the interim been changed to clone $context->data, so we should presumably be adhering to that format in the patch.

jweowu, agree - sorry. Updated patch attached.

Patch seems reasonable: propose for RTBC?

I can't see any reason not to call this RTBC now. I was happy with #47 at the time I posted it, and other than the revised clone formatting this is a straight re-roll of that, and the patch is implementing an approach merlinofchaos had suggested in #26, so I think it's sensible for the maintainers to take another look.

Fixed! (Apparently my browser crashed when I typed this last week). Commited patch #57