BuddyPress.org

Just looked at your site.
All page url include ‘index.php’.

I don’t know why, but suggest you do a search or ask on the WP forums.

You’re not the first to have this problem:
https://wordpress.org/search/remove+index.php+from+urls

The problem is the ‘index.php’ in your url.

On this screen: /wp-admin/options-permalink.php
Is ‘Post name’ selected?

On this screen: wp-admin/options-general.php
what does WordPress Address (URL) say?
And Site Address (URL) say?

Go to Pages > Groups and click edit.
If you see ‘index.php’ in the permalink, remove it.

Most of wordpress plugins mentions above work like

Attacker > HTTP server > PHP > WordPress > PLUGINS

We all need to have something before WordPress that’s why I recommend

NinjaFirewall (I do not have any relation with the plugin creator)

https://wordpress.org/plugins/ninjafirewall/

Block the attacker before the WordPress

Attacker > HTTP server > PHP > NinjaFirewall > WordPress > PLUGINS

As always in installing any plugins that possibly can block your admin access you have to read the Installation note and have access to the FTP.

NinjaFirewall will work as another layer to protect your site.

In addition if you have not done it:

1. Change your “Admin” username to something dificult and at least 10 characters (+) but easily to remember (+ for you – for security) or you have to read a note (-) safely secured in your safe locker (+)
2. Make your password at least 25 COMBINATION of characters (+) but easily to remember (+ for you – for security) or you have to read a note (-) safely secured in your safe locker (+)

NinjaFirewall:

• Web Application Firewall
• Full standalone web application firewall
• Multi-site support
• Compatible with shared hosting accounts
• Protects against RFI, LFI, XSS, code execution, SQL injections, brute
• force scanners, shell scripts, backdoors and many other threats
• Scans and/or sanitises GET / POST requests, HTTP / HTTPS traffic, cookies, server variables (HTTP_USER_AGENT, HTTP_REFERER, PHP_SELF, PATH_TRANSLATED, PATH_INFO)
• Sanitises variables names and values
• Advanced filtering options (ASCII control characters, NULL byte, PHP built
• in wrappers, base64 decoder)
• Blocks username enumeration scanning attempts through the author archives and the login page
• Blocks/allows uploads, sanitises uploaded file names
• Blocks suspicious bots and scanners
• Hides PHP error and notice messages
• Blocks direct access to PHP scripts located inside specific directories
• Whitelist option for WordPress administrator(s), localhost and private IP address spaces
• Configurable HTTP return code and message
• Rules editor to enable/disable built-in security rules
• Activity log and statistics
• Debugging mode

Two more methods that help. I recently had a crazy spam attack – probably 300 fake signups per day. I implemented these two methods and it dropped to near 0.

1. Change the /register/ slug to something unique. An example would be /create-your-account/, or something of that nature. It just needs to be unique and also make sense in a URL for your user. Spammers targeting BuddyPress look for /register/ as the signup page. It’s all automated so you want to filter them out at the first step.

2. Add this to your functions.php file in your theme or child theme.

It presents a dummy field that humans don’t see. Spambots will fill it out, and if the field captures a value it will reject the signup.

// BuddyPress Honeypot
function add_honeypot() {
    echo '';
}
add_action('bp_after_signup_profile_fields','add_honeypot');
function check_honeypot() {
    if (!empty($_POST['system55'])) {
        global $bp;
        wp_redirect(home_url());
        exit;
    }
}
add_filter('bp_core_validate_user_signup','check_honeypot');

Credits for #2 go to:
http://mattts.net/development-stuff/web-development-stuff/wordpress/buddypress/anti-spam-techniques/registration-honeypot/

I edited it slightly to remove the required redirect. Add that back from his tutorial if you want to. It requires that you make an extra page to send the spammer to, and I personally think that’s not necessary. I actually want them to have no indication their signup failed.

Hi @transmission,

this is not the solution, but an example for your inspiration.
The below shows how the notification counter can be moved/implemented on the toolbar.

/* moving the notification counter from right to left */
remove_action( 'admin_bar_menu', 'bp_members_admin_bar_notifications_menu', 90 );
function bpfr_notification_ontheleft() {
	global $wp_admin_bar;
	
	if ( !is_user_logged_in() )
	return false;
	
	$notifications = bp_core_get_notifications_for_user( bp_loggedin_user_id(), 'object' );
	$count         = !empty( $notifications ) ? count( $notifications ) : 0;
	$alert_class   = (int) $count > 0 ? 'pending-count alert' : 'count no-alert';
	$menu_title    = '<span id="ab-pending-notifications" class="' . $alert_class . '">' . $count . '</span>';
	
	// Add the top-level Notifications button
	$wp_admin_bar->add_menu( array(
 /*'parent'    => 'top-secondary',*/  // this is the original position
	'id'        => 'bp-notifications',
	'title'     => $menu_title,
	'href'      => bp_loggedin_user_domain(),
	) );
	
	if ( !empty( $notifications ) ) {
		foreach ( (array) $notifications as $notification ) {
			$wp_admin_bar->add_menu( array(
			'parent' => 'bp-notifications',
			'id'     => 'notification-' . $notification->id,
			'title'  => $notification->content,
			'href'   => $notification->href
			) );
		}
	} else {
		$wp_admin_bar->add_menu( array(
		'parent' => 'bp-notifications',
		'id'     => 'no-notifications',
		'title'  => __( 'No new notifications', 'buddypress' ),
		'href'   => bp_loggedin_user_domain()
		) );
	}
	
	return;
}
add_action( 'admin_bar_menu', 'bpfr_notification_ontheleft',30);
/* other position # are 10, 20, 40, 50, 60, 70, 80, 90 */

In your case, you also have to check this Codex page. And possibly do some research here.

Hi @zippykid – Thanks for the post and for the gist of the EXPLAIN.

We’ve made some massive improvements for 2.0 in the activity query, but we haven’t really changed the way that this COUNT query works. In any case, forcing an index on a COUNT that doesn’t need sorting doesn’t really make much sense anyway, so we should probably remove it. If you get a chance, please open an enhancement ticket at https://buddypress.trac.wordpress.org with the suggestion. If not, I’ll try to get to it later.

The link to your gist:
https://gist.github.com/vidluther/9370018

You’ll probably get a better response by opening a ticket at:
https://buddypress.trac.wordpress.org/

I’d be interested in finding out more about this too. 🙂 Maybe WordPress Network is necessary?

@astarina there’s a premium plugin http://themekraft.com/store/woocommerce-buddypress-integration-wordpress-plugin/

@backpackersunion, you are welcome.

As per the ticket status. It was already fixed in trunk.

https://buddypress.trac.wordpress.org/changeset/7740

Thanks community.