BuddyPress.org

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

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?

@gregfielding – you are getting closer to a vision I have of the “net” – Imagine each person has their own “buddypress” and their friends have theirs – all on separate servers – friends are “linked” across the net via BP – my own activity feeds my friends canonically on their “what are my friends up to” page – my groups can be joined by my friends, but they do not have to be members, just request membership and wha-la they are members of my group – I can send email to the group – each one is separate, I can post updates which send email – etc.

Basically, you completely do away with the behemouth server farms by enabling creation of lite BP cells that are all linked together. How do you make that happen?

@JJJ I’m not so sure the idea of a BP-core plus add-ons is the right approach. To me, the big question becomes where do you draw the line?

As for bundling plugins, please don’t do that. “Hello Dolly” still annoys me and I still have to keep deleting it. I don’t want to see a whole bunch of plugins show up in my install. A better approach is to have a much more user friendly plugin repository. I’m anxiously waiting to see what Andy churns out for that because my biggest gripe now is there is no easy way to know what is supported/recommended.

BuddyPress can be utlized in different ways for different projects … a social networking tool … an organizational tool … a management tool … and so much more. .

Thank you for BuddyPress

The only thing BP should be focusing on is server load. BP php is extremely inefficient. Currently the only way to run BP is with a dedicated server (even with a single install). If you don’t believe this you don’t have enough traffic to make BP worthwhile in the first place.

There also needs to be some sort of default caching system in place. If phpbb can do it BP should be able to as well.

I would also recommend all plugins have to go through some sort of vetting before listed in the official WP/BP directory. Don’t get me wrong everyones hard work i s very much appreciated, but there is some bad code floating around out there that needs some sort of ground rules. There is nothing wrong with releasing “beta” plugins but there should also be some sort of stamp of approval for stable releases.

2. The Senior Plugins (e.g. Media-Albums, Oembed for Activity Streams, BP SEO, Enhanced Privacy etc.)

These are plugins that almost 65% (or some other number) of sites will end up using but we’re not sure that they will.

BP officially endorses and most likely will use their paid developers to keep these plugins functional.

I’d like to comment that the only developer who gets paid to work on BuddyPress is Andy Peatling. Everyone else contributes; some are consultants or developers or people who create themes, but that’s all on their own back.

That being said, I don’t think its fair to make a blanket like “BP php is extremely inefficient” without qualifying it.

This could be an example of what dennis_h is talking about?

For me it goes back to the point that development now should focus on making the core rock solid, including security, privacy, member management, etc., before adding any more features.

@andy We have put in place most of the steps in that article and have seen some results, but thats kind of the point I was making. To really put those measures in place you need a dedicated server.

@MrMaz Maybe “BP php is extremely inefficient” was a little wide-ranging, but it was a phrase that came up over and over again in discussions with several hosting companies. For example, a senior tech at Blue Host/Host Monster told me every BP install they host (and they host over 1 million domains) is throttled (if users find their site slow this may be why).

In order for BP to be the next killer CMS I believe it should be able to be run on a shared server. To get the kind of plugin support and wide variety of quality themes BP needs to get those users that are either unwilling or unable to pay for a dedicated server.

PS

My current skill set is limited to testing and reporting back. That’s all I’m doing here, reporting what we experienced and what we where told. I’ll try to get better details.

I should also note I love BP. It’s a huge step forward and we will continue to use it and grow with it. I am only trying to offer feedback to help that growth. Thanks to everyone for their hard work that got us this far.

One more note. We have around 4000 members and are adding about 50 per day, so we would need a dedicated server regardless, but having a tighter BP would of course still be a big help.

the api eh? (a large percentage of shared hosts are poor quality, we’ll never be able to fix that) my take is that at it’s core, it’s “the missing extended user profile framework for WordPress”. It would, in my feeble opinion act primarily as a framework api for extending those profiles. Some of the issues and limitations are really presented by wordpress and mu.. not Buddypress and in much the same way that bp extended the wordpress user profiles/functions we should tackle those head on as had been done with the improvements in the BP1.2 registration. There are infinite ways to build on those relational database fields. Focus exclusively on bp_xprofile _fields, and _data. It’s not that I’m anti-activity stream and the terms social network, life stream or whatever just seem to incorporate user profiles into some sort of relational scheme, be it friends, followers, ‘like’-ing, sharing or chronological micro blogging. Extending the stability, functionality, and interactivity of each component is the goal, but I’d prefer to see no dependency among core elements with one another. It’s fairly simple to build out a “social network” in other popular content management systems by extending the user database fields and in my day to day practice, I typically use only about 20% of the Buddypress core components for a WordPress project. Even though the hype is in the activity stream and the extensions for it (more facebook or twitter like), I side with @stwc in that “It also means that the platform has to have a robust set of tools for the administrator and moderators of the community “. A community (or ‘social network’) is just a set of users and to me, key items are a small footprint on the database and tight the integration with the existing wordpress user roles, permissions, registration and management. The api should ideally be flexible enough to accommodate any possible relational data between user profiles that a plugin author may dream of. I think the core integration between user profiles and the activity/blogs/groups/forums/friends illustrate the foundation of the api and should be as unified, consistent, and simple as possible with very little dependency or overlap in functionality. This would be impetus for creating a more standardized way to interact with the xprofile and be a good foundation for a solid api. lastly, thanks @mrmaz for starting the thread, being pro-active, getting the trac and api.buddypress and generally illustrating the potential of a solid api in regards to how well your links plugin and others can interact with the core.

ps.. death to PHP4 and fsck backwards compat