Would it be possible to seperate the voting widget from $comment->comment in hook_comment?

Doing this limits the control a themer has.

Why not use something like $comment->voting or something instead to store the widget in.

Files: 
CommentFileSizeAuthor
#44 vote_up_down-791082-post.patch1.21 KBrealityloop
#41 0001-feature-791082-by-realityloop-marvil07-donquixote-Fi-v2.patch2.83 KBmarvil07
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 0001-feature-791082-by-realityloop-marvil07-donquixote-Fi-v2.patch.
[ View ]
#40 0001-feature-791082-by-realityloop-marvil07-donquixote-Fi.patch2.83 KBmarvil07
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 0001-feature-791082-by-realityloop-marvil07-donquixote-Fi.patch.
[ View ]
#38 vote_up_down-791082.patch2.48 KBrealityloop
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch vote_up_down-791082_1.patch. This may be a -p0 (old style) patch, which is no longer supported by the testbots.
[ View ]
#37 vote_up_down-791082.patch2.48 KBrealityloop
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch vote_up_down-791082_0.patch. This may be a -p0 (old style) patch, which is no longer supported by the testbots.
[ View ]
#35 vote_up_down-791082.patch2.59 KBrealityloop
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch vote_up_down-791082.patch. This may be a -p0 (old style) patch, which is no longer supported by the testbots.
[ View ]
#31 0001-Add-widget-as-a-comment-data-member.patch1.04 KBmarvil07
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 0001-Add-widget-as-a-comment-data-member.patch. This may be a -p0 (old style) patch, which is no longer supported by the testbots.
[ View ]
#14 vud_comment.patch2.54 KBdreamdust
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch vud_comment.patch. This may be a -p0 (old style) patch, which is no longer supported by the testbots.
[ View ]

Comments

marvil07’s picture

Version:6.x-2.x-dev» 6.x-3.x-dev

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

no longer here 793948’s picture

I just came across this issue in the queue - I just posted a similar concern in #852154: How to print the widget in a custom place?. Putting something in #comment->voting is also a very good option in addition to my suggestion of making whether the widget is output a user selection.

Which of the two alternatives would you prefer? I can work on a patch and submit it for your consideration, if you'd be willing to look at such a feature.

walker2238’s picture

My personal opinion is to keep it part of the comment variable... and content variable... Seems like a more organized structure for theming. Obviously using the word voting is a bit too generic so maybe using something like vud would be better.

At the same time having a UI to enable the widget makes sense. The flag module does a good job of this allowing users to enable the flag link via a checkbox or alternatively placing it manually in a template file. But again I'd prefer to have it just on the theming layer. Keep things clean and simple.

Fidelix’s picture

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.

meustrus’s picture

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:

<?php
 
// 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.

Fidelix’s picture

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

meustrus’s picture

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.

donquixote’s picture

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.

donquixote’s picture

@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-...".

meustrus’s picture

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.

donquixote’s picture

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)

Fidelix’s picture

Oh god.

Developers, please give us this feature!

meustrus’s picture

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

dreamdust’s picture

Status:Active» Needs review
StatusFileSize
new2.54 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch vud_comment.patch. This may be a -p0 (old style) patch, which is no longer supported by the testbots.
[ View ]

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

Fidelix’s picture

dreamdust, AWESOME patch man!

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

dreamdust’s picture

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

Fidelix’s picture

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.

dreamdust’s picture

Status:Needs review» Needs work

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

Fidelix’s picture

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

dreamdust’s picture

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'

Fidelix’s picture

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.

dreamdust’s picture

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

szantog’s picture

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

<?php
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:

<?php
 
if ($vud_comment) : print $vud_comment; endif;
?>
jthomasbailey’s picture

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?

Fidelix’s picture

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

szantog’s picture

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.

Fidelix’s picture

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

dreamdust’s picture

@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

Fidelix’s picture

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.

Fidelix’s picture

Title:Seperate voting from $comment->comment» Separate voting widget from $comment->comment
marvil07’s picture

Component:Code» vud_comment
Status:Needs work» Needs review
StatusFileSize
new1.04 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 0001-Add-widget-as-a-comment-data-member.patch. This may be a -p0 (old style) patch, which is no longer supported by the testbots.
[ View ]

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.

Fidelix’s picture

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

Fidelix’s picture

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

realityloop’s picture

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

realityloop’s picture

StatusFileSize
new2.59 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch vote_up_down-791082.patch. This may be a -p0 (old style) patch, which is no longer supported by the testbots.
[ View ]

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

greggles’s picture

Status:Needs review» Needs work

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.

realityloop’s picture

Status:Needs work» Needs review
StatusFileSize
new2.48 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch vote_up_down-791082_0.patch. This may be a -p0 (old style) patch, which is no longer supported by the testbots.
[ View ]

Patch Updated

realityloop’s picture

StatusFileSize
new2.48 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch vote_up_down-791082_1.patch. This may be a -p0 (old style) patch, which is no longer supported by the testbots.
[ View ]

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

Fidelix’s picture

Awesome... just awesome...

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

marvil07’s picture

Title:Separate voting widget from $comment->comment» Let separate voting widget from $comment->comment
StatusFileSize
new2.83 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 0001-feature-791082-by-realityloop-marvil07-donquixote-Fi.patch.
[ View ]

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.

marvil07’s picture

StatusFileSize
new2.83 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 0001-feature-791082-by-realityloop-marvil07-donquixote-Fi-v2.patch.
[ View ]

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

marvil07’s picture

Status:Needs review» Fixed

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

Thanks for the feedback!

Fidelix’s picture

Good work guys! Thanks!

realityloop’s picture

Status:Fixed» Needs work
StatusFileSize
new1.21 KB

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 ; ?>
marvil07’s picture

Status:Needs work» Fixed

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

meustrus’s picture

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.

realityloop’s picture

@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 ; ?>
realityloop’s picture

Status:Fixed» Closed (fixed)

closing as variable_get() is sufficient.