BuddyPress.org

Re WP 3.0 officially

From the trenches – https://wordpress.org/support/topic/345127?replies=176

From the Lead Devs/Commiters – http://wpdevel.wordpress.com/

From Trac

– https://core.trac.wordpress.org/ticket/11644

– Core Changesets

– Core Revision Logs

No sweat, huh

If no one writes an oEmbed plugin for the BP activity stream in the first few weeks after BP 1.2 is up, I’ll take a look.

MrMaz has created BP-Links which allows for easy submitting of rich media content. It’s not possible (yet) to use it in the activity stream but he said he would look into it when BP 1.2 is released.

You can find the plugin and more info here;

https://wordpress.org/extend/plugins/buddypress-links/

It does exactly what you say; Fill in a link to youtube/flickr and it detects the video or photo. The newest version of his plugin (not out yet) allows fetching images from ANY site with images on it, so that will be even more awesome!

Killer plugin which will only get better

I don’t understand your issues with member management? WordPress MU provides excellent member management tools, and BuddyPress rides on the back of this. What is it that you need so desperately?

What is your solution to the main question of this thread? I have given my hack, but it doesn’t work for Dan Butcher.

Also if the member management tools are so great, can you answer how to display basic profile information anywhere in the theme?

My main issue with member management in BP is that there is no built-in consistent way to store firstname+lastname, as I’ve explained over and over to the annoyance of many on this forum. It makes it much more difficult to integrate third party scripts that do require firstname + lastname, like mailing list ListMessenger in my case.

Commercial membership plugins apparently create their own members table to not be stuck in WP’s built-in users management. If WP had a more solid solution that would not be necessary.

WordPress provides a decent base, but over the years bits and pieces were apparently added in different tables – nickname, display name, first name, last name, … – and BP added xprofile on top of that without synchronization with wp_usermeta. But I’m repeating myself again…

Just trying to help so you’re not completely ignored.

I’m ignored anyway.

I don’t understand your issues with member management? WordPress MU provides excellent member management tools, and BuddyPress rides on the back of this. What is it that you need so desperately?

Why not do the following (as we have) …

1. username

2. 1st name

3. last name

4. display name (the bp required field)

Because it’s not necessary. The goal should be to keep the registration form as short and simple as possible and not annoy new users.

Look at the registration process on Facebook, LinkedIn, etc. Most have:

First Name:

Last Name:

Email:

Password:

I use a javascript trick generate the username from the fullname in a hidden field – I can use email as username thanks to this plugin. Since BP has a built-in fullname field I’m stuck with splitting that out in firstname and lastname.

I have considered using fullname for firstname and creating a field_2 for lastname, but that causes all kinds of other issues.

Unfortunately there is no check/validation on what’s entered in the fullname field. The input is also not cleaned up to get capitals on the first letters and small caps on the rest. So the input could be anything, often just a first name or even ladiesman269.

Which undermines any reason of having that required fullname/display field in the first place…

All you have to do is create a function that writes the xprofile field values for 1st and Last name over to the WP table, in addition to setting the “display name value accordingly.

You have to do that straight from the registration form, to make sure that the data is there where/when you need it. That is basically what my function does. If you can get it to work. Apparently it doesn’t for Dan Butcher.

Now, with the (lame) fact that WP user table is actually different (not sure why it wasn’t co-opted for BP purposes)

That had mystified me since last Spring, but here’s Andy’s reason.

Buddypress (actually wordpress entirely) works bad on Windows. For example, windows doesnt have mod_rewrite, which is a neccesity for Buddypress.

Switch back to a LAMP environment. Or find a really good coder that wants to re-program wordpress for a Windows environment.

@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.