BuddyPress.org

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?