Posted by Junro on August 17, 2009 at 1:11am
Jump to:
| Project: | Node Comments |
| Version: | 6.x-3.x-dev |
| Component: | User interface |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (won't fix) |
Issue Summary
Hello,
I can't find how to change the display of my comments.
I'm using the default view, nodecomments, when I edit the view from a node comment, I go to the Nodecomments display, and change the dafault style to Table.
But the view display in the node are style the same. Full node in think.
I didn't change anything of the Default view before... maybe I have to change something I don't know...
node-comment.tpl.php is in my thme directory but I didn't change anything on it too.
Did I miss something?
Thanks :)
Comments
#1
Nobody?
Whathever the fields I change in the view, nothing happen.
Do I have to change something into node-comment.tpl.php ?
#2
In the node comments project page, it said:
"Use node_comments if you want a flat presentation and node_comments_threaded if you want threaded presentation."
I'm using nodecomments view, but I don't have choise, this is the only view I have. Where is the node_comments_threaded ?
#3
Hey Junro, I've been heavily hacking at this module for the past week.
The proper way to setup a new display SHOULD be:
1. Create a new node view.
2. Set it up to your liking.
3. Add a new "display" to the view available in the dropdown as "Nodecomments". This makes it available in the content-type settings where you see "Comment view:" drop-down selection.
That's found by going to the page to edit your content type and expanding the Comments Settings.
Now the problem is, that no matter how you setup your new view, it always displays it as the same typical nodecomments view. This is a bug.
It is however possible to force your custom view into the node by making a node-your_content_type.tpl.php and putting something like this wherever you want your comment view output:
<?php print views_embed_view('your_view_name', 'your_views_display_name', ARGUMENTS OR NOTHING HERE); ?>Then you have your custom comment view working on the node type you did this for. However it still leaves you with the old style output coming from the nodecomment module, resulting in duplicate displays of your comments. You can handle this however you feel necessary...
The easiest way I found to get rid of the old style view without getting your hands too dirty, hacking the nodecomments module, inc files, or poor methods like css'ing it out, is to create another node-your_comment_content_type.tpl.php and run a little check to clear out the old display if we are not on an actual nodecomment page. Open that tpl.php file and put this at the top before anything:
<?php if(!$variables['view']->args[0]) { ?>
//Then all your typical node stuff is here like...
<div id="node-<?php print $node->nid; ?>" class="<?php print $classes; ?>"><div class="node-inner">
<?php print $picture; ?>
<?php if (!$page): ?>
<h2 class="title">
<span><a href="<?php print $node_url; ?>" title="<?php print $title ?>"><?php print $title; ?></a></span>
</h2>
<?php endif; ?>
//blah blah blah
//after all that is finished, at the very bottom after all the closing </divs> and such, put this:
<?php } else { } ?>
Basically just printing nothing if it's not the comment's node page.
This is an unobtrusive method to make the old view print out nothing but still display our full node / comments on their own page. I don't know if this is the best way, but it is a better option than some other methods...
I really hope they address this issue because it would be nice to be able to just setup a new view and assign it in the content type's settings like it's supposed to. I would be willing to help (Ehhem attention maintainer!) because I've recently come across this module and it is fantastic otherwise! But I don't want to hack their module for a fix if it's not going to get submitted.
Hope this helped...
#4
Hi, thanks for this, I'm going to follow all step and see if I can make it work.
So, actually, the display of comments with view are not working I suppose.
I'm going to report it as a bug :)
#5
Yeah the bug is that selecting your new view from the "Comment view" drop down in the content type settings never changes the look of anything. I tried field & node 'row' styles as well as plenty of other settings and they all just look the same as the original nodecomments view.
The only reason I wonder about my method is this line:
<?php if(!$variables['view']->args[0]) { ?>It's probably fine, I've just never used that particular variable before. I found it using:
<?php print_r(get_defined_vars()); ?>In testing, it was present on any parent node where the comments are attached, (where view is inserted), but not present on the actual comment node. Without spending too much time on it, this was the only variable I could find to easily reference if we were on the parent or comment node.
Another way would be to parse the current URL and do a comparison. If the $variables method above doesn't work just check against the URL.
I'm sure there is a variable somewhere other than the ones I dabbled with like $node->comment_target_nid and someone may wind up posting it here, but the important factor in my method was this check had to be run in the node-COMMENT_NODE_TYPE.tpl.php, since we are battling against the core output of the nodecomment module at this point. Which puts a spin on things and brought me to my solution.
#6
Thanks, it worked for me and saved me time.
I added the line at the top of node-comment.tpl.php.
#7
AFAIK this is not a bug. Nodecomments is simply hardcoded to always use same display of the view. This was intended behaviour. Making it use arbitrary display would be feature request.
#8
More info: you can switch display style only when your comments are configured as flat. In threaded mode, Node Comments forces usage of own display style, which totally makes sense. How would you display threads in a table for example ?
HTH
#9
Postponing this. We have lots of critical bugs atm so I think most new features won't be implemented in 2.x branch.
#10
#8 should go onto the module pages under notes, as it is not a bug, but by design; however the average user won't be able to get this design limitation at first, and is likely to become frustrated trying to change the display. So we should warn him.
#11
Re-opening this since nothing is blocking it in theory.
#12
#13
Hello,
I tested it again, and this bug seems to be fix! Thanks
#14
This is documented in README. Unless someone comes up with a patch, this is a "won't fix" from me.