Let separate voting widget from $comment->comment

Let's start this on 3.x if this get it soon maybe we can port back to 2.x

I agree. What we really need is the ability not to print the widget, as we already have a function to print it wherever we want.

The module currently forces the widget into the output, and thats no good for advanced theming.

I would definitely test and feedback if you roll a patch, random720. Thank you.

I had a problem with this, and my solution may or may not work for you as it moves the entire widget into the comment links (it does this on nodes as well).

In my theme's HOOK_theme function I added:

  // Redirect the Vote Up/Down widget into where 'vud_votes' displays…
  $hooks['vud_votes'] = $existing['vud_widget'];
  // ...then prevent 'vud_widget' from displaying inside body
  $existing['vud_widget']['function'] = 'theme_null';

[...]
function theme_null() {}

That works for me, along with a new widget which displays inline.

I did not understand your solution buddy. From what i understand the vud widget will still be in $content, so what has changed?

It doesn't go into the node or comment preprocess function, it goes into the HOOK_theme function. What it does is it causes the "vud_widget" (which goes in content) to instead render where "vud_votes" would (inside the links). Therefore the widget is never inserted into $content, because theme('vud_widget') now uses a function that doesn't return anything. Instead, theme('vud_votes') now displays the widget.

This isn't a solution that would be built into the module; rather, it's something of a hack that should work until the option to insert the widget or not is actually there.

That code was used in a Zen subtheme, where &$existing is the first argument and $hooks is the return value.

I would like the widget to show up in the links area, instead of the comment body area.

So, what about this as a quick solution with no side effects:

<?php
/**
 * Implementation of hook_comment().
 */
function vud_comment_comment(&$comment, $op) {
  ...
        $comment->vud_original_comment = $comment->comment;
        $comment->vud_widget = theme('vud_widget', $comment->cid, 'comment', $tag, $widget);
        $comment->comment = $comment->vud_widget . $comment->comment;
  ...
}
?>

This would allow vud-aware modules / themes to get comment body and widget as independent pieces of html, while not changing anything on existing projects.

@meustrus (#5):
I should add that your solution only works (with ajax) if the theme does define a votes template, and if the id of the widget is "votes-...", not "widget-...".

Actually, what I do makes the "widget-" item load in the "votes-" area. I had to do it this way because a lot of the widget-specific variables are only available to "widget-". And I did define my own widget, but that's mainly to make a short one that displays inline rather than as a tall floated block.

I considered suggesting that the widget variables be available to the "votes-" template, but that code is all so complicated that I think it's best not to.

@donquixote: Do what I described to get it in the links area. The only requirement is that you are using a custom theme in which you can modify template.php (and clear the cache in admin/settings/performance ) However, your suggested solution should be implemented in some form in a later version. My fix is just a hack until that happens.

Well, actually I used a module with hook_theme_registry_alter(), instead of a theme with hook_theme() ..
And it does work.
But the ajax did not work, because the ajax callback would replace the widget with the empty string returned from theme('vud_widget').

So, I had to give the widget a new id ("votes-..." instead of "widget-..."), so it can be replaced by theme('vud_votes') instead of theme('vud_widget').
This only works if the widget plugin defines a votes template, and not just a widget template. See vud_vote() in vud.theme.inc.

With these points considered, your hack works quite well.
(and the vud code is unpleasant to work with)

Oh god.

Developers, please give us this feature!

@donquixote, thanks for the extra information. I hadn't actually tested the widget to see if AJAX was working, and your additional fix works perfectly.

Attached is a patch that gives the user the option of displaying the widget in comment body or links. There's an admin settings to choose between comment body or links.

This patch is for 6.x-2.1, but if it's good I'll port it to 6.x-3.x-dev

dreamdust, AWESOME patch man!

Could you please code an option NOT to display the widget? Labeled "Custom" or "None" ?

Would it be better to separate the display of votes and widget using permissions?

dreamdust, i can think of some use cases for that, so yes, it would be a nice idea...

In my implementations, i need anonymous users to see stuff, but dont vote on 'em.

I've submitted an updated patch that allows you to separate the display of the widget and votes, as well as choose whether each one displays in node/comment content or links.

See: #544354-26: How to display voting widget by API for nodes?. If that patch is good to go I'll port to 6.x-3.x-dev

dreamdust, does this patch include the option NOT to display the widget at all?

Fidelix, you can do that with permissions now. If you only want to display votes, not the widget, go to permissions (my patch adds a permission to comment module):

vud_comment module
- Uncheck 'use vote up/down on comments'
- Check 'view votes on comments'

vud_node module
- Uncheck 'use vote up/down on nodes'
- Check 'vote up/down count on nodes'

dreamdust, i cant get what i want with permissions.

I want to HIDE the widget completely, so i can print it wherever i want.
Doing this through permissions is impossible.

I understand now. I'll update the patch to hide the widget completely.

Just use template.php comment_preprocess function, and turn off all content types on admin/settings/voteupdown/comment.

function YOURTHEME_preprocess_comment(&$vars, $hook) {

  $comment = $vars['comment'] ;

  if (module_exists('vud_comment')) {
    $type = _vud_comment_get_node_type($comment->nid);
    if (user_access('use vote up/down on comments')) {
      $tag = variable_get('vud_tag', 'vote');
      $widget = variable_get('vud_comment_widget', 'plain');
      $vars['vud_comment'] = theme('vud_widget', $comment->cid, 'comment', $tag, $widget);
    }  
  }
}

Then print it anywhere in comment.tpl.php:

if ($vud_comment) : print $vud_comment; endif;

Woo Hoo #23! Had to add another "}" at the end though.

Now how do you print $unsigned_points outside of the widget without putting it in the links?

Well... this wouldnt exactly work for node comments. But its a good start!

Ok, edited, ty. :)

A don't need to separate $unsigned_points, beacause i'm using the plain widget and custom css. This is: http://www.screencast.com/users/szantogabor/folders/Jing/media/4c0c70f4-...

You can use the comment_link api function to get the array of comment link, then you can make another $vars in comment_preprocess. In a custom module hook_link_alter you can unset the unusable links, if exist.

@dreamdust, what about your patch?

It seems the perfect remedy to this issue, since it would require little to no work in destroying array indexes.

@Fidelix: I've created an issue for the patch here: #989298: Display widget and votes in body or $links

It's for 6.x-2.2 so if that goes well I'll port to 3.x

Hello @dreamdust, isn't that issue a duplicate?

Anyhow, i will test the patch as soon as i'm able to.
Thank you for the fine work.

Thanks for all the feedback here.

I was taking a look at this, but there seems to not be any way to actually add some information to the comment to be rendered. In D6 comments are not renderable arrays, so AFAIK it is not possible to add information without adding to the plain $comment->comment.

If we provide a $comment->vud_comment_widget, it will not be shown, so the only thing we get is a new data member on the comment object, that is not going to be shown by the comment.tpl.php template. So it is not a valid solution since users may need to customize their theme comment.tpl.php template in order to use it.

In D7 all are renderable arrays, so it would be possible to do this naturally there.

In conclusion, IMHO the only thing we can do here in D6 is provide the extra $comment->vud_comment_widget and still use the same technique: concatenate to the main comment field. So the only thing we get here is make it easy to the customizers to show the widget, that is going to be in a comment object data member. But to actually let it work, a module with a softer weight than vud_comment that implements hook_comment() on $op='view' is going to be needed to save the original $comment->comment field, and then on the comment.tpl.php template the widget can be printed anywhere.

Ugly, but I think we are going to stay with this, unless someone can provide a better option that still let the final user use the vud_comment module without manually editing templates.

@marvil07, cant the module append the widget to $comment->comment ONLY if the module is configured to do so?

That way, themers may disable the widget and still print manually $comment->vud_comment_widget.

Maybe this is something http://drupal.org/project/comment_bonus_api could help?

#32 I'm working on this as it's a blocker for work I am doing for g.d.o theme update

Here is a patch including option to hide $content->content concatenated version of the vote widget so you can expose it via a comment.tpl.php instead

https://img.skitch.com/20101217-x8iyx3bpjm9qpkfeypbupfxc1s.jpg

Looks good to me in general though I didn't test it.

Can you remove the commented out line from your patch?

Also, I think variable_get('vud_comment_widget_display', 0) should have a 1 instead of a 0 since we want to keep the current behavior as the default.

Patch Updated

Rerolled: put radios in alphabetic order and so that the default option is first

Awesome... just awesome...

This is what we all needed. Lets just wait for someone else to test and we can mark this as RTBC

Ok, my recommended way on #31 is too ugly :-p, let's have a configuration option.

I have updated the patch with some minor strings changes and use constants for options.

Since this is small, I will commit it to 2.x too.

Upps, as greggles mentioned, we need to keep current behaviour.

Ok, committed to 3.x and 2.x.

Thanks for the feedback!

Good work guys! Thanks!

Not really sure what status to set this to..

Is it possible to make this small change so we can turn off output of the tpl generated widget if the variable is set as such?

the code added to comment.tpl.php can now be:

<?php if (isset($comment->vud_comment_widget)) print $comment->vud_comment_widget ; ?>

Edit: drumm said it was ok to use the following, so feel free to close this again if you like

<?php if (variable_get('vud_comment_widget_display') == 0) print $comment->vud_comment_widget ; ?>

@realityloop: not sure why you want to avoid using isset(). Maybe you want to implement hook_vud_widget_template_variables() and overwrite $comment->vud_comment_widget to empty if it is not set.

marvil07, your comment basically amounts to (as I see it) "Not sure why you don't want to add the widget directly to the comment body if it exists. That's where it goes." The whole point of this issue is to be able to build a widget WITHOUT forcing it into the comment body, so that, for example, it can be added somewhere else in the theme instead.

@marvil07 the current code sets $comment->vud_comment_widget regardless of the display setting, therefore you end up with 2 widgets when set to default if your comment.tpl.php contains the code.

My suggested change ensures that $comment->vud_comment_widget is only set if the display setting is configured to in theme meaning the only way to hide the widget is to use variable_get() as follows in your comment.tpl.php.

<?php if (variable_get('vud_comment_widget_display') == 0) print $comment->vud_comment_widget ; ?>

closing as variable_get() is sufficient.