BuddyPress.org

Why do you want to force blogs on your users? Give them the choice. Some people,don’t want yet another blog (like me for example – I never create new blogs on each WPMU/BP site I go to)

Why do you want to force blogs on your users? Give them the choice. Some people,don’t want yet another blog (like me for example – I never create new blogs on each WPMU/BP site I go to)

Are you running WPMU? If not, you can’t provide blogs for users.

It’s built into WPMU so all you need to do is enable the option to create a blog for new users.

Are you running WPMU? If not, you can’t provide blogs for users.

It’s built into WPMU so all you need to do is enable the option to create a blog for new users.

BP shouldn’t be run with WP 3.0 yet. It hasn’t been verified.

BP shouldn’t be run with WP 3.0 yet. It hasn’t been verified.

@francescolaffi-

There should not be any issues. However, I would instruct all Site Admins using your plugin to manually deactivate, upload the new version, and then manually reactivate.

Even if there were a few members with blogs that for some reason activated the plugin on their blog (per blog plugin activation), WPMU runs a check to see if any plugins that used to be per blog activated are now site-wide plugins. This means that WPMU will deactivate the plugin in the corresponding wp_x_options table of each user blogs.

For more in-depth information, see the function check_is_wpmu_plugin_on_activate in mu.php.

I’m still on 1.1.3. In 1.1.3 xprofile only gets synchronized with wp_usermeta when the user updates his account, which means you can never count on the data being there, which makes it pointless.

Lousy synchronization between xprofile and usermeta is not a bug, it’s a conscious design feature. Why? I’ve brought this issue up many times and have never received a clear answer.

I use a custom function like this below to synchronize member data upon registration into all the different, unconnected places in the database where data is stored:

function synchro_wp_usermeta($user_id, $password, $meta) {

global $bp, $wpdb;



$uid = get_userdata($user_id);

$email = $uid->user_email;



$fullname = $meta[field_1];



... whatever you need here ....



update_usermeta( $user_id, 'nickname', $fullname );

update_usermeta( $user_id, 'first_name', $firstname );

update_usermeta( $user_id, 'last_name', $lastname );



$wpdb->query( $wpdb->prepare( "UPDATE {$wpdb->users} SET display_name = %s WHERE ID = %d", $fullname, $user_id ) );

$wpdb->query( $wpdb->prepare( "UPDATE {$wpdb->users} SET user_url = %s WHERE ID = %d", bp_core_get_user_domain( $user_id ), $user_id ) );

}

add_action( 'wpmu_activate_user', 'synchro_wp_usermeta', 10, 3);

Not sure if this still works in 1.2. I had posted my work-arounds under ‘FAQ: How To, Code Snippets and Solutions’, but they have been deleted. So I guess they solved the issues in 1.2?

To synch xprofile you’d need to create the fields in xprofile that you have in wp_usermeta and then do something backwards like the above function, if that hook etc. is still valid.

@Diesel Laws, you’re right. There is no Miscellaneous settings in WPMU because avatar uploads go to

e.g. BP in main blog_id_1

wp-content/blogs.dir/1/files/avatars/ plus folders for user 1/ 2/ 3/ etc. and

wp-content/blogs.dir/1/files/group-avatars/ plus folders for group 1/ 2/ 3/ etc.

Can you see if your avatars and group-avatars folders were created in the /files/ folder?

If they have been created, can you see the images uploaded as avatars in the 1/ 2/ 3/ etc folders inside avatars and group-avatars folders?

If not, you might want to check folder permissions in your server, if 755 does not work then try 777 at /files/ folder. If that still doesn’t work, CHMOD 777 the /1/ folder

In addition to the thread https://buddypress.org/forums/topic/avatar-upload-issues ,

you could also deactivate all plugins and change to default theme, then re-upload BuddyPress via FTP or cpanel. Then activate BuddyPress plugin and bp-default theme and see if uploading avatar works.

Slightly tangental – apologies. This discussion brings to my mind the fact that in many ways I find the description of Buddypress, Buddypress-links, BP-Events, BP-Album and others of the same ilk as far more than plugins; plugins tend to make me think of things that are fun but not essential in any way to the operation of the core application whereas Buddypress whilst not necessary to WP is not simply a plugin it changes the working nature of WP and is far more suited to being known as a module or something to set it apart.

In an ideal world I would like BP installed much as is but described differently but along with BP are installed a series of modules that can be activated or not by admin but that these are only activated from within BP so to speak always sitewide as BP is these modules representing some essential core set of features e.g Links, Events, Album etc. In some ways that would also remove any confusion as to how they were activated, but I also realise that single WP probably has to be considered somewhere in all that.

Follow-on question! On the BP install I’m currently working on, the following long list of plugins (all of which seem to be working flawlessly activated non-sitewide) do not even offer the option for Site-wide Activation.

Is there a reason (or reasons) for that? Is there any possible downside? Or are they fine the way they are?

BP Group Management, BuddyPress Album+, BuddyPress Forums Extras main plugin (but not sub-plugins), BuddyPress Like, BuddyPress Links, BuddyPress Profile Privacy, BuddyPress Rate Forum Posts, Custom Profile Filters for BuddyPress, Enhanced BuddyPress Widgets, External Group Blogs (written by Andy!), Invite Anyone, oEmbed for BuddyPress, Welcome Pack and WP-FB-AutoConnect.

I said I’d try and establish some test conditions to try and determine whether banned email domains were an issue in WP or BP, tests were not hugely conclusive sadly.

site running out of the box no modifications (WPMU / BP) – no anti spam measures in place. had been receiving ~ 10 -20 spam registrations daily (quantity of spam is governed to some extent by search engine ranking /prominence)

1/ Running WPMU 2.9.2 ALL BP plugins deactivated site open to user account registrations only.

24 hour period = no spam registrations at all – a surprising result!

2/ Conditions as above (1) but allowing blog to be registered

Start to receive spam signups – not many but only observed over a 6 hour period.

These do not match to any banned emails domains entered by me, so on the surface looks as though banned domains working BUT this is far from conclusive as they may simply not have attempted to.

3/ Activate BP 1.2.3 allow accounts and blogs to be registered.

Spam increases – not hugely though! of the 6- 8 received in a 12 hour period one is noted as having an email domain that matches to one entered in the banned domains list.

None of the above is that conclusive or useful sadly, it’s a difficult subject to run tests on. It does appear that BP probably does have some problem with the banned domain list, but then I get the impression that with each version 1.2.2.1 / 1.2.3 spam issues feel as though they are lessening but others may not be experiencing that.

Here’s how I handle it for my BuddyPress Privacy Component. I have a loader file called bp-authz-loader.php. It contains all the necessary plugin metadata at the top of the file. After the metadata, I have this as the first function:

/**

* BPAz_init()

*

* Initialize basic constants and make sure BuddyPress

* is installed and activated. If true, then allow for

* Privacy Component to finish loading.

*

* @since 0.4

*/

function BPAz_init() {



/* Define the component's parent folder name */

define( 'BP_AUTHZ_PLUGIN_NAME', 'bp-authz' );



/* Define component's directory and URL Paths */

define( 'BP_AUTHZ_PLUGIN_DIR', WP_PLUGIN_DIR . '/' . BP_AUTHZ_PLUGIN_NAME );

define( 'BP_AUTHZ_PLUGIN_URL', WP_PLUGIN_URL . '/' . BP_AUTHZ_PLUGIN_NAME );



/* Define the directory where user settings' functions reside */

define( 'BP_AUTHZ_SETTINGS', BP_AUTHZ_PLUGIN_DIR . '/' . 'settings' );



/* BuddyPress is installed and activated, finish initialization and go! */

require_once( BP_AUTHZ_PLUGIN_DIR . '/bp-authz-core.php' );

}

add_action( 'bp_init', 'BPAz_init' );

I have two more functions in this file, one to register the plugin upon activation, the other to register it upon deactivation. But that is all. Just these three functions.

If BuddyPress is installed and activated, BPAz_init() will fire, resulting in the rest of my component being activated when bp-authz-core.php is loaded. I’ve tested it and it works as expected without causing BP to crash. In other words, if BP is not activated but my plugin is activated, nothing happens. This is what you want.

After the 2nd atempt installing the plugin, it will activate ok.

now i still have this error when trying to send something to facebook:

Fatal error: Uncaught exception 'FacebookRestClientException' with message 'Updating status requires the extended permission status_update' in /home/************/domains/************.com/public_html/wp-content/plugins/facestream/facebook/facebookapi_php5_restlib.php:3374 Stack trace: #0 /home/************/domains/************.com/public_html/wp-content/plugins/facestream/facebook/facebookapi_php5_restlib.php(1819): FacebookRestClient->call_method('facebook.users....', Array) #1 /home/************/domains/************.com/public_html/wp-content/plugins/facestream/facestream-functions.php(348): FacebookRestClient->users_setStatus('Estamos a testa...', '1.00000551739E+...') #2 /home/************/domains/************.com/public_html/wp-content/plugins/facestream/facestream-functions.php(309): facestream_facebookIt('Estamos a testa...') #3 /home/************/domains/************.com/public_html/wp-includes/plugin.php(166): facestream_activityToFacebook('Estamos a testa...') #4 /home/************/domains/************.com/public_html/wp-content/plugins in /home/************/domains/************.com/public_html/wp-content/plugins/facestream/facebook/facebookapi_php5_restlib.php on line 3374

@mrjarbenne

Try using this:

http://wpmudev.org/project/wpmu-plugin-manager

This will activate certain plugins on certain blogs.

Theoretically, if we’d like to disable it, is there a way we can define it in wp-config or bp-custom?

We’ve got a workaround, but it involves changing a core file, bp-core-signup.php. We changed this line:

$wpdb->query( $wpdb->prepare( "UPDATE $wpdb->users SET user_status = 2 WHERE ID = %d", $user_id ) );

to set the user_status as 0 (activated)

$wpdb->query( $wpdb->prepare( "UPDATE $wpdb->users SET user_status = 0 WHERE ID = %d", $user_id ) );

Next, we changed a line in register.php, in a child theme, where we changed the conditional

<?php if ( bp_registration_needs_activation() ) : ?>

to

<?php if ( !bp_registration_needs_activation() ) : ?>

This solves the problem, but it involves modifying a core file. Any workaround for that?

Is that not okay?? Basically that’s how I’ve fixed 99% of the bugs in the plugin – when someone activates it, it tells me about it, so I can checkout their site and make sure everything’s working properly. Often I’ll find something that doesn’t work right, so I fix it and release an update, and let that user know directly. I’ve found that users almost never bother to report bugs, but are extremely happy when I contact them to let them know that i’ve fixed something just for them

@etiviti you rock. Thanks for your speedy replies.

I’ve had your forum extras installed for a couple days and things were fine. I just tried to install a TinyMCE plugin – https://wordpress.org/extend/plugins/bp-tinymce/ – which works great as well.

Unfortunately with BP-TinyMCE activated the Quote function no longer loads any text in the comment box. It just changes to “quoted” but that’s all that seems to happen.

Do you know what’s causing the conflict? Is it something you can change or is it a problem with BP-TinyMCE? I *need* a way for my users to format their topics so if it comes down to it I’ll just leave Quote deactivated…but it would be cool to have both. Perhaps if you get it working you can include BP-TinyMCE in forum extras?

WP 2.9.2 BP 1.2.2.1

@etiviti – the new version of the plugin appeared on my dashboard – thanks for this!

I clicked on the upgrade plugin for the umbrella plugin of te Forum Extras and got this:

QUOTE

Downloading update from https://downloads.wordpress.org/plugin/buddypress-group-forum-extras.0.1.5.zip.

Unpacking the update.

Installing the latest version.

Deactivating the plugin.

Warning: Cannot modify header information – headers already sent by (output started at /home1/fromvict/public_html/comunidade/wp-admin/admin-header.php:18) in /home1/fromvict/public_html/comunidade/wp-includes/pluggable.php on line 868

Removing the old version of the plugin.

Plugin upgraded successfully.

Attempting reactivation of the plugin

Plugin reactivated successfully.

UNQUOTE

Do you think this can cause any problem?

The buttons are appearing on Forum discussions of Groups -thanks!

However the buttons do not appear on Group wire or when sending direct messages of one user to another.

One great improvement for the future could be adding images straight from our computer, instead of using a URL.

Cheers!