BuddyPress.org

I don’t mean to side-track the nature of this conversation (maybe I’m not), but as a developer in Higher-Ed arena I see a lot of potential for BP. There are a lot of buzz-words kicking around for the concepts of “open learning”: personal learning environments (PLE), communities of practice (COP), and these can be niche and community driven. I’m definitely in support of any ePortfolio endeavors as well. I would see these as being a series of plugins that rely on BP API, so that: Gradebook, Courses, DropBox could integrate with a user’s Activity Stream. Of course, granular levels of object permissions is ideal for users and admins. Great conversation!

This website (the theme) was designed by Andy Peatling, who works for Automattic – http://automattic.com. This website runs on a platform of WordPress, bbPress and BuddyPress softwares which are led by Automattic but are opensource.

I am going to close this topic as it is off-topic and looks to be commercial.

I think that if the low level core API of BuddyPress is strong and extensible, then ‘what BuddyPress is’ will mean different things to different people, depending on why they use it.

In a land before time, BuddyPress was actually intended to be several separate plugins, but having different components with different version numbers and dealing with the dependencies would have been a nightmare.

Now though, watching plugins merge and adapt, it doesn’t seem that unlikely.

Imagine if when you DL BuddyPress, you’re just DLing BuddyPress core, and the install routine lets you pick which additional components you might want for your social network, and it puts them in the BuddyPress directory. Not everyone needs friends, but maybe they want to follow each other. Different plugins for almost the same thing. Users should be walked through the component picking process to be able to shape their social network in a matter of minutes.

I believe the component API should be built for rapid deployment of new components. It should take care of the things we currently spend hours trying to dance around. I.E. component registration, template inclusion, URL rewriting, GET/POSTing, and it needs to give each new component its own API at the same time, so that we can easily communicate between these components and make them talk to each other in a universal way.

Then BuddyPress will become less of a “friends/activity/groups/profiles/pm” plugin, and more of a “sum of its parts” plugin.

So, the API would need to be fairly self aware, and include setters/getters/checkers for just about every routine there is for them to possibly do.

We had a ticket open about 4 months ago with a transitional API that I started for a general BP_Component class. It wasn’t much, but maybe a start?

Devs, you certainly know that Google will use next site speed for web search ranking ?.

http://googlewebmastercentral.blogspot.com/2010/04/using-site-speed-in-web-search-ranking.html

Probably not the best news for wp

https://buddypress.org/forums/topic/forum-install-some-helping-hints-2

Can someone give solution that users that wish to sign up dont use buddypress signup page, instead they use regular wordpress signup which is much much safer.

Then all you need to do is install SABRE and spammers are gone. This is urgent request because i dont wish to have spoammers on my sites, same goes for everyone else, i m getting hit by 20 spammers per hour.

BTW nothing mentioned in this topic works!!!!

@MrMaz

I saw the announcement that you are joining the BP team…

Where does that leave the Links Developments? Im still keen on the “Post to Digg” type feature….

that still coming?

Pro still coming?

I tryed a ticket but its cloesd now (https://trac.buddypress.org/ticket/2246) Any solution for this problem. Looks like i´m not allone with this bug. If i deactivate the buddypress-default theme, it works fine, registration is possible. But not with the buddypress-theme.

Any solutions out there?

Thanks a lot!

M

Oh, and although every developer I’ve ever known has hated doing it, one of the single most important things for the whole project would be a comprehensive documentation project, well organized, with code samples and snippets.

Not going to hold my breath on that one, in part because I suppose it might feel like wasted effort to some extent until BP is fully mature (it’s getting close, though, I think).

Everything seems to work perfectly so far.

Not sure why when I Share –> Share this link in My Profile, it returns an error div with ‘Sharing a link with yourself is not allowed.’

Am I misunderstanding what that Share link is for in that context? (Makes perfect sense to me in adding it to a Group, though.)

In your new role as API guru, is there any way to coordinate the efforts of plugin developers and core developers, in terms of letting plugin developers know what’s worth pursuing? How do you determine what goes in the core and what is plugin territory?

For example, I just read that “Inappropriate content flagging” is a “Potential Future BuddyPress Feature” for 1.4+ (https://buddypress.org/about/roadmap/) and now I’m wondering how that jibes with Report/Ignore plugin that may be developed as part of GSoC.

The need for an “advanced” BP search gets discussed frequently in the forums, so would that be a core function or should it be up to plugin developers?

I’ve made two contributions of code that extends BP Forums – a “posts since last visit” tracker and now a “BP Forum Move Topic” function that I will expand to Forum Topic Split and Topic Merge – but before I start extending that, or start another project, how do I know if I am duplicating effort that eventually will be part of the BP core?

This is now officially a “Potential Future BuddyPress Feature” for BP 1.4+ (ie, after BP 1.3, which looks to be essentially the WP 3.0 compatibility release). Here is the short list:

A quick blog post form via the theme. (try plugin: BuddyPress QuickPress)

Privacy controls (try plugin: bp-authz)

Global content tagging

Inappropriate content flagging

Bulk accept/reject friendship requests

Grouping of similar activity stream items

Ability to block all communication from a user

Option to receive forum post notifications via email

Message file attachments

Structured profile fields (templates for address / phone number)

Profile field specific searching (try plugin: BP Member Filter)

AJAX live updating of site wide activity stream

I’ve got the same problems with waterwaywatch.org and I’ve see many people reporting similar problems under various post subject headings. Has anyone logged this as a bug?

In my case as I am hosted on a Windows server running IIS 6.0 I have seen the numerous suggestions that have been made but none have worked.

My .htaccess contains the following line – can anyone tell me why that is there?

RewriteRule . /index.php [L]

I’m really desperate for a solution to this; I’ve spent well over a week trying to solve it and can’t can’t go live with my site until it is fixed.

“Social networking” means community to me.

Yeah, like I said, I may be making a distinction without a difference for many people. I reckon there is one, though.

To me BudyPress is more about being able to build a niche community.

You can take an existing blog/site where people comment on posts and turn it into a site where people can converse and share.

Basic functionality that is solid is a huge must. Well documented APIs to extend the basic functionality is a high priority.

I have to agree with @Peterverkooijen that BuddyPress doesn’t need to be everything. In fact, I sort of wish BuddyPress didn’t advertise itself as “social networking in a box” because it attracts a lot of people looking for the quick and easy way to make their “millions” a la-Facebook.

@stwc: “social networking” is a buzzword but like all buzzwords, they have a fundamental definition. “Social networking” means community to me.