Skip to:
Content
Pages
Categories
Search
Top
Bottom

new plugin: BuddyPress Rate Forum Posts

  • @dwenaus

    Participant

    hey all, I’ve put together a new plugin, it will eventually live here:

    http://wordpress.org/extend/plugins/buddypress-rate-forum-posts/

    but for now you can find it here:

    http://bluemandala.com/plugins/bp-rate-forum-posts.zip

    basically, as the name says, you can rate forum posts. Thumbs up or thumbs down. Only logged in users can rate, and they can rate only once. Site-admins can rate as much as they want. (but not group admins).

    Users get a karma score based on how their posts have been rated. In the code you can choose between a pure average, a pure total of ratings. Default is set to somewhere in-between and average and a total.

    much inspiration was taken from the elegantly designed Intense Debate. Code was inspired for the excellently programmed iLikeThis plugin.

    eventually I might add ratings to other things such as group activity feed. (but not personal feeds)

    enjoy, and give feedback.

Viewing 14 replies - 26 through 39 (of 39 total)
  • @andrew_s1

    Participant

    The collision with BP-TinyMCE is caused by that plugin, not by BuddyPress Rate Forum Posts.

    It happens because of what goes on in the function bp_tinymce_allowed_tags in bp-tinymce.php . It removes attributes ONCLICK, ID and CLASS from A tags, it removes ID and CLASS from SPAN tags, and it removes the DIV tag with its CLASS and ID. So, by adding those into the $allowedtags array inside bp_tinymce_allowed_tags, the problem goes away.

    @dwenaus

    Participant

    good to know the plugin is working well.

    @andrew_s1 thanks for the headsup

    @andrew_s1

    Participant

    What do you think about displaying the karma on the profile page too?

    Something like this:

    function rfp_show_poster_karma() {
    global $bp;
    $poster_id = $bp->displayed_user->id;
    $karma = get_usermeta( $poster_id, 'rfp_post_karma' );
    echo rfp_poster_karma($karma);
    return;
    }
    add_filter( 'bp_before_member_header_meta', 'rfp_show_poster_karma' );

    @nuprn1

    Participant

    @dwenaus

    Ok, just updated to 1.0.3 and hit another snag. Seems you have the bb_meta table hardcoded as I’m using an external forum install

    nevermind – looks like i have weird issue with an external bbpress install and various prefix values being defined (might be a buddypress bug)

    @bpisimone

    Participant

    This thing works well on my test install, very well done @Dwenaus! Right now I’m also using another plugin called comment rating. Any chance you might extend yours to comments also?

    @dwenaus

    Participant

    @andrew_s1 thanks for the code, I’ll add that soon.

    @nuprn1 – I would love to not hard code it, but I was having trouble getting those variables. Can you give me a suggestion on how I can do that. One solution could be to check a db option value, and if it exists (for example in a custom install) then use that instead of the default one. what do you think?

    @Bpisimone – I might get around to comment rating, but that is a pretty low priority because those plugins already exist. However it would be good to combine points rather that have two systems. Things like this that don’t effect the project i’m working on are lower priority. (but donations do make them higher priority. :)

    @nuprn1

    Participant

    I think my situation is somewhat unique as

    $bp->forums->bbconfig = $bp->site_options['bb-config-location']; which is loaded in bp-forums.php is different (subdomain) than the wp root bb-config.php which had a stale reference to the default bb table prefix.

    I’m not certain – but you may be able to call do_action( 'bbpress_init' );

    @bpisimone

    Participant

    @Dwenaus, haha good one! At the moment there’s no hurry for me. I just wanted to check what you think about that. But who knows maybe I will need the feature in a few weeks.

    But again, good plugin, nice implementation.

    @andrew_s1

    Participant

    At the moment, the classes are added to individual posts in a topic, by javascript. This results in extra server load, because wordpress has to do two whole startups for each such page. The trade-off is adding another apply_filter and a do_action to the theme, but as this plugin already benefits from one such proposed theme change, we can get two for the price of one.

    Proposed change to buddypress/bp-themes/bp-default/groups/single/forum/topic.php, from line 26:

    <ul id="topic-post-list" class="item-list">
    <?php while ( bp_forum_topic_posts() ) : bp_the_forum_topic_post(); ?>
    <li <?php
    $topic_post_id = bp_get_the_topic_post_id();
    echo "id='post-$topic_post_id' class='",
    apply_filters('bp_single_forum_topic_post_css',array('class'=>'', 'post_id'=>$topic_post_id)),
    "'";
    ?> >
    <div class="poster-meta">
    <a href="<?php bp_the_topic_post_poster_link() ?>">
    <?php bp_the_topic_post_poster_avatar( 'width=40&height=40' ) ?>
    </a>
    <?php echo sprintf( __( '%s said %s ago:', 'buddypress' ), bp_get_the_topic_post_poster_name(), bp_get_the_topic_post_time_since() ) ?>
    </div>

    <div class="post-content">
    <?php bp_the_topic_post_content() ?>
    </div>

    <div class="admin-links">
    <?php
    if ( bp_group_is_admin() || bp_group_is_mod() || bp_get_the_topic_post_is_mine() ) :
    bp_the_topic_post_admin_links();
    endif;
    do_action( 'bp_single_forum_topic_links' , $topic_post_id );
    ?>
    <a href="#post-<?php echo $topic_post_id; ?>" title="<?php _e( 'Permanent link to this post', 'buddypress' ) ?>">#</a>
    </div>
    </li>
    <?php endwhile; ?>
    </ul>

    Proposed change to buddypress-rate-forum-posts/bp-rate-forum-posts.php, insert:

    // modifies the css class for topics to highlight popular posts, and hide very unpopular ones
    function rfp_css_class_for_post($args) {
    global $rfp;
    $class = $args['class'];
    $post_rating = rfp_get_post_rating( $args['post_id'] );
    $rfpclass = '';
    error_log('rfp='.print_r($rfp,true));
    if ( $post_rating == NULL )
    $rfpclass = '';
    else if ( $post_rating >= $rfp->superboost )
    $rfpclass = 'rfp-superboost';
    elseif ( $post_rating >= $rfp->boost )
    $rfpclass = 'rfp-boost';
    elseif ( $post_rating <= $rfp->hide )
    $rfpclass = 'rfp-hide';
    elseif ( $post_rating <= $rfp->diminish )
    $rfpclass = 'rfp-diminish';
    //error_log("in rfp_css_class_for_post rating '$post_rating' adding class '$rfpclass' to '$class' with args ".print_r($args,true));
    return $class.($class?' ':'').$rfpclass;
    }
    add_filter( 'bp_single_forum_topic_post_css', 'rfp_css_class_for_post', 3);

    function rfp_echo_hidden_post_link($post_id) {
    global $rfp;
    $post_rating = rfp_get_post_rating( $post_id );
    if ( $post_rating && $post_rating <= $rfp->hide )
    echo "<span class='rfp-show' onclick='jQuery(this).remove();jQuery("#post-$post_id").removeClass( "rfp-hide" );'>Click to show this hidden post</span>";
    }
    add_action( 'bp_single_forum_topic_links', 'rfp_echo_hidden_post_link', 3);

    And then the javascript section starting jQuery(document).ready( function() can be removed from buddypress-rate-forum-posts/js, and the corresponding section can be removed from the end of buddypress-rate-forum-posts/rate.php

    @andrew_s1

    Participant

    I’ve just attached the theme patch to the trac ticket here https://trac.buddypress.org/ticket/2063#comment:1

    @dwenaus

    Participant

    hey @andrew_s1 I totally agree that is a better implementation, and I was going to initially do it that way, however my requests for filter and action hook additions seem to take a low priority (rightly so) and I was concerned that future BP updates would break the plugin. Do you think I should wait until the hook is added before I make the change in the code, and force people to upgrade their template, or leave it as is with javascript for the meantime?

    hmmm. maybe if I learn to make diff files for trac, my suggestions are more likely to be implemented…

    @andrew_s1

    Participant

    I’d say, definitely go with how you’ve got it now, by adding classes through javascript: it works, and it seems to be gaining popularity: quite right too – it’s a great plugin.

    Yes, I’d say wait for the hook to make it into a release version of buddypress before removing the javascript way of adding classes to posts.

    re creating diff files – yes, SVN is clunky. If you’re developing in windows, tortoiseSVN isn’t too bad an interface to it.

    @dwenaus

    Participant

    Andrew, the issue you raise–not doing the highlighting with javascript–is valid, and I will be addressing it in the next version, however i’m going to take another approach than you’ve suggested. So other users don’t need to be concerned with the above code, because it will work differently quite soon.

    @dwenaus

    Participant

    I’ve started a new topic for version 1.1 of the plugin. Please post any comments here:

    https://buddypress.org/forums/topic/new-version-of-buddypress-rate-forum-posts

Viewing 14 replies - 26 through 39 (of 39 total)
  • The topic ‘new plugin: BuddyPress Rate Forum Posts’ is closed to new replies.
Skip to toolbar