[andrew_s1]

In terms of being scalable, isn’t a cookie less overhead than a database query?

In this case: no, no it’s not. Your cookie will grow and grow with each new forum topic read. It is doomed.

[andrew_s1]

Think about scalability too – does it make sense to store a marker for every topic, given that it will grow with every new user and every new topic?

Another way to do it would be to store a “high tide mark” for every user on each forum, recording the highest post number that a user has read. That way, when they come back to the forum, you can do an easy SELECT on topics which have a post higher than the high tide mark, and flag those as having unread posts.

[andrew_s1]

3sixty, I’d strongly recommend not doing it that way. ISTM that it’s far better if you store this info server-side, not client-side: it’s information that’s specific to the logged-in user, not to the browser they’re logged in from. I wouldn’t want to see posts marked as new, that I’d already read, just because I was using a different browser or a different machine. Big cookies harm browser-side performance, too.

Yes, I’m interested in working on extending buddypress’s forum capabilities. Here’s my work in progress: http://andrewsinlondon.wordpress.com/

[andrew_s1]

What does the link in the activation email look like? What’s the “.php” bit of the URL, specifically? (is this in WPMU?)

[andrew_s1]

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.

[andrew_s1]

As admin, go to Group > admin > Manage members > and next to the user who you want to be a moderator, select “promote to mod”

[andrew_s1]

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

[andrew_s1]

trac ticket and patch are here https://trac.buddypress.org/ticket/2063#comment:1

whoops – just collided with @Erich73

anyway, my patch would be for adding links to report posts as abusive, rather than for tackling the issue of group creation

[andrew_s1]

I’ve just proposed the adding of a new action hook that would make it easy to develop a plugin for this. The action hook is suggested for another purpose, but would work for this purpose as well.

See https://buddypress.org/forums/topic/new-plugin-buddypress-rate-forum-posts/page/2#post-39751 – the proposed action is bp_single_forum_topic_links

If that hook gets incorporated, then writing a plugin to do what you want would be very easy.

Alternatively, you could also just modify your theme directly, to add it. See the theme file groups/single/forum/topic.php</b> , in the loop:

while ( bp_forum_topic_posts() ) : bp_the_forum_topic_post();

[andrew_s1]

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]

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' );

[andrew_s1]

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.

[andrew_s1]

Thank you! It works well (wp 2.9.2, bp 1.2.1, rfp 1.0.3).

But it does collide with BP-TinyMCE – if that’s active, then the thumbs up/down don’t appear on forum posts. I’ll have a poke around and see if I can find the cause.

[andrew_s1]

Grrr, my posts to this thread aren’t appearing here. Please check my activity stream to see what I wrote earlier!

[andrew_s1]

There’s a trac ticket with a patch for bp-core.php, and a reworked version of Andy Peatling’s plugin, just here: https://trac.buddypress.org/ticket/2074

[andrew_s1]

just had this problem. Oddly, posts appear in my activity stream, but I can’t see them if I log out and view the thread I posted to. I can see them if I’m logged in. And in some threads, I get no reply box. Like here: https://buddypress.org/forums/topic/was-all-site-data-visible-to-members-and-non-members-alike – “1post, no voice”?

[andrew_s1]

There’s a trac ticket with a patch for bp-core.php, and a reworked version of Andy Peatling’s plugin, just here: https://trac.buddypress.org/ticket/2074

[andrew_s1]

Code revised to give protection even if buddypress gets deactivated: adds a second line of defence by hooking a wordpress action too. I’ve assumed that there’s no conflict here, but I don’t know if these two hooks collide. It seems to work ok.

<?php

/*

Plugin Name: BuddyPress Lockdown

Plugin URI: https://buddypress.org/

Description: Lock down your BuddyPress site if a user is not logged in.

Author: Andy Peatling & Andrew_S1

Version: 1.2

Author URI: https://buddypress.org/

Site Wide Only: true

*/



function bp_lockdown() {

global $bp;



if ( BP_REGISTER_SLUG != $bp->current_component &&

BP_LOGIN_SLUG != $bp->current_component &&

BP_LOGIN1_SLUG != $bp->current_component &&

!is_user_logged_in() ) {

bp_core_redirect( site_url( BP_LOGIN_SLUG ) );

}

}

function wp_lockdown() {

if ( !is_user_logged_in() ) {

auth_redirect( 'wp-login.php' );

}

}



add_action( 'bp_init', 'bp_lockdown');

// if no buddypress, have a backup plan

add_action( 'send_headers', 'wp_lockdown');

?>

[andrew_s1]

Note that using this method, if buddypress became deactivated, all of your site’s posts, and the comments, would become completely visible.

[andrew_s1]

I’ve submitted a ticket for the issue of wp-login not being registered as a root_component:

https://trac.buddypress.org/ticket/2074

There’s a patch attached to that ticket, to make the necessary changes to bp-core.php

And here’s my revision of the lockout plugin:

<?php

/*

Plugin Name: BuddyPress Lockdown

Plugin URI: https://buddypress.org/

Description: Lock down your BuddyPress site if a user is not logged in.

Author: Andy Peatling & Andrew_S1

Version: 1.1

Author URI: https://buddypress.org/

Site Wide Only: true

*/



function bp_lockdown() {

global $bp;



if ( BP_REGISTER_SLUG != $bp->current_component &&

BP_LOGIN_SLUG != $bp->current_component &&

BP_LOGIN1_SLUG != $bp->current_component &&

!is_user_logged_in() ) {



bp_core_redirect( site_url( BP_LOGIN_SLUG ) );

}

}

add_action( 'bp_init', 'bp_lockdown');

?>

[andrew_s1]

yes, it’s patchy with that. If the link is directly to /register/, then it works fine. But if it’s to wp-login.php?action=register, then it gets stuck in the wp-login loop.

[andrew_s1]

And $is_root_component is empty because wp-login does not appear in $bp->root_components when evaluated at line 129 of bp-core/bp-core-catchuri.php

[andrew_s1]

And $component_index=1 because VHOST==‘no’ and $is_root_component is empty at line 131 of bp-core/bp-core-catchuri.php

[andrew_s1]

Well, yes, that would prevent the loop: the loop happens on wp-login.php, but not on /register/

Enabling registration doesn’t affect the problem. The problem’s cause is that in bp-core/bp-core-catchuri.php , function bp_core_set_uri_globals , when viewing wp-login.php, $component_index = 1 , but $bp_uri =array([0] => ‘wp-login’)

[andrew_s1]

When viewing wp-login.php, then:

at line 178 of bp-core.php, both $bp->current_component and $bp->displayed_user->id are empty

at line 138 of bp-core/bp-core-catchuri.php, $bp_uri =array([0] => ‘wp-login.php’), but $component_index = 1

So there’s the problem – when viewing wp-login.php, $bp_uri has value ‘wp-login.php’ at key 0, but $component_index is 1, so $current_component is set to an empty string

[EDIT – value is ‘wp-login’ not ‘wp-login.php’ – sorry. EDIT again – bah – wp-login.php it can be – it’s whatever the user enters in the URL. wp-login.php and wp-login both worth, and each gets carried through as is]