BuddyPress.org

Here is what I am trying to figure out with buddypress.

1. buddypress is going to be installed in a subdomain blog. (I do not want to dedicate my root blog for buddypress, rather use it as an entry point for people to be able to register their own blogs)

2. A user goes to my root domain and registers their new blog – normal wpmu behavior

3. I have it setup now where a user can register direcly on the subdomain blog without having to leave that blog for registration. (that part of wpmu never made any sense to me – sending a user to another blog to register)

I did this because my ‘client’ blogs do NOT want their users to even know that they are using a hosted blog from my service. They are supposed to be autonomous. This really comes into play when using domain mapping.

Imagine being a visitor going to site ‘xyz’ and when you click register you are sent to site ‘abc’ for registration…. That wpmu feature makes zero sense and only serves to tick off my blog owners. So we created a custom plugin to allow wpmu to register users directly on the subdomain itself. (also gives option for subdomain to turn off blog registrations when signing up as that would also make no sense to the user, they just want to register at a site to comment)

Now the buddypress part:

wpmu allows me to automatically add new users to any chosen blog behind the scenes. So I will set it to auto add new users to the ‘buddypress’ subdomain blog.

Here is what I can’t figure out:

It ‘seems’ to me that buddypress for some seriously unknown reason to me, is using it’s own registration system. It seems to store the username/profile name etc in a totally different area than just simply relying upon the wpmu tables for users….

(someone should take the time to explain why in the world bp uses a sep reg system)

Anyhow here is what I am trying to do:

When a ‘regular’ user registers at a subdomain blog, they should automatically be added to buddypress. That way when they click their ‘wp-admin’ button (I’ll rename that later) they are taken to their buddypress profile page.

Here’s the real catch:

I do NOT want them going to the subdomain that buddypress is installed on. I want them to stay on the domain in question, only display their bp profile within the domain in question.

Kind of like giving each site it’s ‘own’ buddypress, but not really.

This would allow me to do 2 important things:

1. Each blog has it’s own ‘buddypress social networking’ display, appearing independant.

(I have to imagine that if wordpress.com is ever going to implement bp, they will have to do this, as not all blog owners would want their members sent to a separate social networking site).

2. It gives me the ability to also create a ‘site-wide’ social network using bp that encompasses all users from all blogs.

I plan on giving the blog owners the option of allowing their members to participate in the ‘primary bp’ blog.. some clients will like their members being part of a larger community, while others would never allow it.

So How do I go about this?

1. dumping the separate bp registration so if a member registers on any blog, they are already registered into bp.

2. each blog has it’s ‘own’ bp area

thanks

I just ran into an issue upgrading one of my WPMU test sites. It is a site I have not yet upgraded to the 2.8 series, so I thought I would quickly do the upgrade this afternoon. But after going about my regular upgrading process, I went to log in as Site Admin to complete the upgrade, and it would not let me. Instead it fired the installation script assuming I was installing WPMU for the first time–even though I had the proper, current version of my site’s wp-config.php file in its proper place.

After checking to make sure I did not make any mistakes in the upgrade process, I thought that there could be some issues with the version of WPMU 2.8.4 that was available via the “Download” link on the WPMU site. So as not to take any chances, I decided I would grab the tagged version directly from WPMU’s Trac ( http://trac.mu.wordpress.org/browser/tags ). Besides, my install was not functioning anymore.

Just in case there was some issue going from 2.7.1 to 2.8.4, I decided that I would first upgrade from 2.7.1 to 2.8.3. Then, I would grab the tagged version of 2.8.4a and complete the upgrade. It went without issue taking about 8 minutes to do the double-path upgrade.

I’m not sure if I would not have had any issues if I had just grabbed the tagged version of 2.8.4a and upgraded my 2.7.1 directly to that, skipping the above intermediate step. So, if you have any 2.7.1-based WPMU sites to upgrade, you may want to follow my procedure as well.

By the way, in case you’re wondering, I never use the auto-upgrade feature built into WPMU. I prefer to upgrade manually. It really is simple and quick–once you’ve done it a few times.

I get these error messages with my mailing list integration code?

[04-Sep-2009 10:12:57] PHP Warning: join() [function.join]: Invalid arguments passed in /serverpath/wp-content/mu-plugins/bp-custom.php on line 363

[04-Sep-2009 10:14:44] WordPress database error Duplicate entry ‘781’ for key 1 for query INSERT mailusers SET users_id=’781′, group_id=’1′, signup_date= UNIX_TIMESTAMP(), firstname= ‘Test’, lastname= ‘User’, email_address = ‘peter@emailaddress.net’ made by require, require_once, do_action, call_user_func_array, bp_core_do_catch_uri, load_template, require_once, custom_do_activation, wpmu_activate_signup, do_action, call_user_func_array, synchro_wp_usermeta

The problem is that I tried to use the same ID from WPMU/BP in my mailing list, but my mailing list already has many more users on it.

Is there a way to reset the members ID from now on to a higher value? Specifically, my latest member ID is 780, how can I make the next one to be 3000?

What would happen if I sign up a test user and manually change his ID in the database to 3000? Would the next one take 3001? Or would I mess up the entire system?

Or is there a cleaner, official way to do this?