BuddyPress.org

@Dan https://wordpress.org/extend/plugins/buddypress-real-names/installation/ but I have no idea if it does anything special with BP->WP profile syncing. If you’ve got a repeatable case of BP changes not syncing to the WP profile, please create a bug ticket on https://trac.buddypress.org/.

Hey Brajesh,

I just checked out the auto-activate plugin and I can confirm what Pierre said that it does send an activation email even though the user account is already activated.

Also, I just checked out buddydev.com since you have the plugin running on your site and I’ve noticed a lot of spam registrations there!

Perhaps you need to add some anti-spam prevention of some kind to your BP install.

And also, as a courtesy, on the plugin release page, you should add a warning to enable some type of anti-spam solution on the user’s BP install (particularly in production environments).

JJJ-

I agree with your argument about the dangers of paywalls to OS projects. But I just wanted to correct one issue. The GPL does not say anything about free as in cost. It is about freedoms of the end user.

http://www.gnu.org/philosophy/selling.html

Most people in vibrant OS communities like the WordPress ecosystem, are moving beyond the spirit of the GPL, to a more utopian, share and share alike vision. There’s nothing wrong with that if it happens. But the GPL has never been about free as in cost.

I know this is a little back from the dead, but I would go about this in a totally different way myself.

I would use good old WordPress usermeta, and have three different registration screens. Giving users the ability to choose something will more often than not confuse them. If you give them a dedicated registration with only the options they need, that will yield better results.

I have a post around here somewhere on how to assign usermeta values directly from registration. Then rather than trying to group users together, rather than wasting a profile field that you eventually have to hide or prevent users from changing, and rather than creating custom user role types, you can just check the meta and go. And if they upgrade their account, you just update the usermeta value.

Custom user roles is a good idea too, but it comes with a little more work to make things cooperate the way you want to use them.

a lot of sentences used inside the system are from WordPress MU… did you look at this language file?

There have been at least two nights of discussion in the WordPress and WordPress MU IRC dev channels about this. Tonight will be a third night of discussion, I’m sure, in the WordPress meeting.

As the naming of WordPress features isn’t something that is to do with BuddyPress directly, I kindly suggest you visit the WP or WPMU forums — or IRC — and contribute to existing threads so that your comments will be seen by more people.

Nice, Brajesh!

Have you updated your auto-activate plugin lately?

In your comments, you mention you were going to update the plugin in November, but the last update was in October.

Also, has using this plugin affected spam registrations for you, Brajesh?

@jjj

My view is quiet different on this issue. I have already seen the chat log where it all was proposed and ms- prefix was associated.

My point is calling Blogs in wp 3.0 as site, is completely incorrect(unless someone convinces me here).

Let us concentrate on what WordPress Mu blogs offer out of the box, It is nothing more than the blog functionality(at the moment).

Obviously you can customize the blogs and wordpress plugins/themes(and wordpress itself) has the capability that a blog can be converted as a Site.

But again, Calling it as Multisite out of the box is a strong no no for me because of the obvious reasons.

Let us consider the usage, How many sites out there are using wpmu as a Multi Site software. 2%-5%(that is my personal experience+expectation,actual data may be different).

Yes, wordpress mu is mainly used for network of blogs(checkout the wpmu showcase) and one or 2 blogs on the network(most of the time, the main domain) act as the Site(or full featured site).

So calling every blog out there as a site will be completely unjustifiable.

The thing that exites me the most about the merge is all the experienced WordPress developers being introduced to a whole new platform to work on and develop for. I can’t wait to stop having to ask the same question over and over again; Is is WPMU compatible? Never no more!

@Peter: *deep sigh*

Saw the thread about the “baptismal name” for the 3.0 version. My two cents for the branding of the new WP 3.0 – WordPress NW (for network and looks like new too but that’s up to the top honchos so I’m not going to sweat it. But we have to bear in mind that WPMU was not only used for multiple blogs and multiple sites using Donncha’s Domain Mapping plugin only.

I’ve also used WPMU as CMS for associations/organizations and the subblogs are used for mangement of either Departments or Sections areas including “Job sections” or “Prayer sections” – where each Admin/Editor is accountable for maintaining such, among other great things you can do with WPMU.

Looking at some of the changes in the merge specially with deprecating WPMU functions I see that it would be easier to upgrade single WP installs to WP 3.0 (as should be the case) than it would be upgrading WPMU installs to WP 3.0. – specially the WPMU installs with many customizations in frontend and backend including plugins hooking in wpmu_ (ouch!), tell me it ain’t so

It’s funny because when I first found out about WPMU is was indeed wildy confused about what it meant exactly. Already familiar with single WordPress I installed WPMU because I wanted to use BuddyPress and thought it was some kind of special version of WordPress (not realizing the Network of blogs/sites kinda thing).

After I got BuddyPress up and running and started a blog I got launched into another admin panel which suddently missed all kinds of menu options and had a different name.. “WTF is going on here” was my initial response..

Until I realised that WPMU actually allowed me to setup multiple blogs from one panel and would allow me to create a network of sites!

This name change is a good thing and much easier to grasp. It does make me think; should I call new blogs on my network “sites” or “blogs”.

The same way you stop WordPress MU from requiring email activation.

@anointed, if you wanted to just make it so you’re grabbing the user list of a blog instead of the members list, that’s very possible to do. But you will still probably want your root blog to be the center of all members.

Like andrea_r said, I imagine that MU is in a feature freeze at the moment until 3.0. All the devs are going to have their hands full rearranging the code to make it fit into normal WordPress so it’s a smooth transition for everyone.

Where the actual work happens, in trac. Yesterday, merge work started, so I’m not sure where to put a suggestion like this right now.

If you stick it in https://trac.mu.wordpress.org/report I know it will get read by Donncha.

Also, user management is changing, so you may want to play around with wpmu 2.9.1 rc-1 a bit before filing any tickets.

Thanks. That clears things up. The only other problem I’ve encountered is after I deactivate the BuddyPress plugin and re-activate it, I’ll get the follow db errors:

WordPress database error: [Duplicate key name ‘useritem’]

ALTER TABLE wp_bp_notifications ADD KEY useritem (user_id, is_new)

WordPress database error: [Table ‘wp_bp_activity’ already exists]

RENAME TABLE wp_bp_activity_user_activity_cached TO wp_bp_activity

WordPress database error: [Duplicate entry ‘1’ for key 1]

INSERT INTO wp_bp_xprofile_groups VALUES ( 1, ‘Base’, ”, 0 );

WordPress database error: [Duplicate entry ‘1’ for key 1]

INSERT INTO wp_bp_xprofile_fields ( id, group_id, parent_id, type, name, is_required, can_delete ) VALUES ( 1, 1, 0, ‘textbox’, ‘Name’, 1, 0 );

It does indeed work with WordPress 2.9, however none of my registered members are showing up. The only account that shows up in the member listing is the admin account.

The default members page filter is “active members”. If they haven’t logged in and been active since BuddyPress was activated they will not show. If you change the filter to “Alphabetical” or something else, they will show.

It does indeed work with WordPress 2.9, however none of my registered members are showing up. The only account that shows up in the member listing is the admin account.

@idotter: https://wordpress.org/extend/plugins/bpcontents/https://wordpress.org/extend/plugins/bpcontents/

That’s how BP works. There is almost no security, privacy and member management built into BP. The focus is on expanding features.

There are various efforts underway to bolt better management on via plugins etc. This plugin for example offers new member moderation.

Jeff Sayre is working on a privacy component, but apparently has decided he needs to be compensated – and rightly so!

Is the BuddyPress theme required for BuddyPress to work on an existing WordPress install… or can we pick and choose pieces from the official BP theme and incorporate as needed? I’m assuming the latter, but wanted to be sure before I start to hack away.

bp-custom.php loads up before any BuddyPress components do, and functions.php loads after all plugins and WordPress core code does.

So it isn’t a matter of “if,” it’s a matter of “why.”

Basically…

Use bp-custom.php to override core BuddyPress settings like slugs or constant values, or to load specific code BEFORE BuddyPress loads for whatever reason you might need to.

Use functions.php if you need to add actions or filters to BuddyPress things. It’s good practice to make sure that actions and filters exist before attaching code to them. If you add a filter to a function that doesn’t exist yet, or you add it before/after the code is loaded/executed, then you’re ahead/behind the action/filter curve, so to speak.

Different files for different purposes.