BuddyPress.org

We discussed it here: https://buddypress.org/support/topic/dont-hide-fields-when-user-views-his-own-profile/, but I got stuck. Maybe I’ll revisit.

When i say the site beces slow it is especially for thz buddypress part. I Can’t publish easily a picture or even like. It takes tremendous time.

I’m using kleo theme. When i uninstall all plugins, i have my site running at it full speed. Very fast.but once i activate buddypress, the request or the site becomes slow just for logged in users. I dont understand.

Trying to take a look at the template file. Found it at: /wp-content/plugins/buddypress/bp-templates/bp-legacy/buddypress/assets/_attachments/cover-images/index.php

In that file, I see the code:

<script id="tmpl-bp-cover-image-delete" type="text/html">
	<# if ( 'user' === data.object ) { #>
		<p><?php _e( "If you'd like to delete your current cover image but not upload a new one, please use the delete Cover Image button.", 'buddypress' ); ?></p>
		<p><a class="button edit" id="bp-delete-cover-image" href="#"><?php esc_html_e( 'Delete My Cover Image', 'buddypress' ); ?></a></p>
	<# } else if ( 'group' === data.object ) { #>
		<p><?php _e( "If you'd like to remove the existing group cover image but not upload a new one, please use the delete group cover image button.", 'buddypress' ); ?></p>
		<p><a class="button edit" id="bp-delete-cover-image" href="#"><?php esc_html_e( 'Delete Group Cover Image', 'buddypress' ); ?></a></p>
	<# } else { #>
		<?php do_action( 'bp_attachments_cover_image_delete_template' ); ?>
	<# } #>
</script>

However, on my site itself, the source comes out missing the script tag, and the angle brackets are in the form of lt; gt; etc.

Any ideas? Could use some help on this.

I understand.Why my buddypress don’t have file: \buddypress\bp-templates\bp-legacy\buddypress\activity\post-form.php?Please tell me your opinion.

Thanks Shane! I’ll give this a shot when I get back to home this evening and let you guys know how it works out. I’m afraid the little profile I made doesn’t do any sorts of compares, it just lets me know if it is loaded before or after certain other hooks like init, the_content and such.. I’ll have to reopen that and add bp_load and get a better idea of where it loads to buddypress though.

My I make a request, though, developer to developer 😛 This seems to have broken a lot of plugins and I like to say I follow the methods of WordPress to the letter without getting hacky :P. If changes like this are made, can we still preserve a method of backward compatibility? The profile info, for instance shouldn’t matter much when it loads, so long as the BP class is loaded, which means, I guess what I’m saying is I’m drawing a blank to what it would be that would require the xprofile fields to be dropped to such a low load order that it doesn’t initialize with the plugin class init.

Nope. The hook does work, because profiler says the function is called later now, but the function still doesn’t seem to exist and throws the undefined function exception.

Also, other plugins do as well including gears which is used by theme authors such as myself for allowing users to easily add elements to a website from buddypress.

Hi Slava,

I tested that code and got no visible effect, but I think we’re in the right territory here.
I explored both of these functions:

bp_group_is_member()
groups_is_user_member()

It helped me realize that the two specific problems I wanted to solve were as follows:
– Users can’t create topics in a BuddyPress group’s forum unless they join the group
– Users can’t reply to topic in a BuddyPress group’s forum unless they join the group

So I started on the page template itself (form-topic.php).
Before displaying the “Create a topic” form, the template does a check to see if the user is allowed to create topics:
if ( bbp_current_user_can_access_create_topic_form() ) : ?
This was coming back as false, so I checked through each possible path through the function.

Here’s the whole function for quick reference:

function bbp_current_user_can_access_create_topic_form() {

	// Users need to earn access
	$retval = false;

	// Always allow keymasters
	if ( bbp_is_user_keymaster() ) {
		$retval = true;

	// Looking at a single forum & forum is open
	} elseif ( ( bbp_is_single_forum() || is_page() || is_single() ) && bbp_is_forum_open() ) {
		$retval = bbp_current_user_can_publish_topics();

	// User can edit this topic
	} elseif ( bbp_is_topic_edit() ) {
		$retval = current_user_can( 'edit_topic', bbp_get_topic_id() );
	}

	// Allow access to be filtered
	return (bool) apply_filters( 'bbp_current_user_can_access_create_topic_form', (bool) $retval );
}

Every single path through that function was returning true.
If I removed the filter and replaced it with a hard-coded true as follows…
return (bool) true;
…then the user would have access to the group’s forum without joining the group.

That told me that something in BuddyPress was filtering the result of this function. It was checking whether the user was a member of the group, and if not, was forcing bbp_current_user_can_access_create_topic_form() to return 0.

I couldn’t find the portion of BuddyPress that was filtering the result, unfortunately.

I have a working solution now, but it’s not elegant. I created a plugin with two filters (one for creating topics, one for replying to topics). The content of those filters is identical to the original bbPress functions. Since the plugin is loaded last, it basically overrides whatever BuddyPress says and goes with the original functions instead.

Here it is:

/**************************************************
Part 1: Allow users to create topics
Allow anyone to create a topic in any forum, even if that forum is inside a group the user hasn't joined.
If the group is hidden (e.g. "Management"), they still won't have access because that check is done first.
***************************************************/
// define the bbp_current_user_can_access_create_topic_form callback
function filter_bbp_current_user_can_access_create_topic_form( $retval ) {
	// Users need to earn access
	$retval = false;

	// Always allow keymasters
	if ( bbp_is_user_keymaster() ) {
		$retval = true;

	// Looking at a single forum & forum is open
	} elseif ( ( bbp_is_single_forum() || is_page() || is_single() ) && bbp_is_forum_open() ) {
		$retval = bbp_current_user_can_publish_topics();

	// User can edit this topic
	} elseif ( bbp_is_topic_edit() ) {
		$retval = current_user_can( 'edit_topic', bbp_get_topic_id() );
	}
return (bool) $retval;
};

// add the filter
add_filter( 'bbp_current_user_can_access_create_topic_form', 'filter_bbp_current_user_can_access_create_topic_form', 999, 1 );

/**************************************************
Part 2: Reply to comments
Allow anyone to reply to a comment in any forum, even if that forum is inside a group the user hasn't joined.
If the group is hidden (e.g. "Management"), they still won't have access because that check is done first.
***************************************************/
function filter_bbp_current_user_can_access_create_reply_form( $retval ) {

	// Users need to earn access
	$retval = false;

	// Always allow keymasters
	if ( bbp_is_user_keymaster() ) {
		$retval = true;

	// Looking at a single topic, topic is open, and forum is open
	} elseif ( ( bbp_is_single_topic() || is_page() || is_single() ) && bbp_is_topic_open() && bbp_is_forum_open() ) {
		$retval = bbp_current_user_can_publish_replies();

	// User can edit this topic
	} elseif ( bbp_is_reply_edit() ) {
		$retval = current_user_can( 'edit_reply', bbp_get_reply_id() );
	}

return (bool) $retval;
};
// add the filter
add_filter( 'bbp_current_user_can_access_create_reply_form', 'filter_bbp_current_user_can_access_create_reply_form', 999, 1 );

If I can find where BuddyPress filters bbp_current_user_can_access_create_topic_form() and bbp_current_user_can_access_create_reply_form(), I’ll write a more elegant plugin.

Could this be the same thing?

https://buddypress.trac.wordpress.org/ticket/7307

Hi @danbp,

Thank you! I’ve applied the fix and still experiencing the same problem.

I’ve only had a few minutes this morning, but is it possible the deprecated 2.1.php file is not loading?

– Placing a die(); statement in the 2.1.php file does nothing.
– In class-buddypress.php if move the
require( $this->plugin_dir . 'bp-core/deprecated/2.1.php' );
outside of the
if ( ! bp_get_option( '_bp_ignore_deprecated_code', ! $this->load_deprecated ) ) { statement the die() works, and removing die() the create site functionality returns

– Also, if I place the called bp_blogs_get_subdomain_base() function into class-buddypress.php it works