Forum Replies Created
-
Have a look at this topic about changing built in vergiage. Probably would have saved you some time.
@swaymedia, sorry you feel that way, but I hope you at least come back once and see that you’ve made a mistake.
Saying that friends would be “deprecated” maybe was a bad idea.
The friends component is basically done, and doesn’t need much more development, because it’s a means to an end, and a dead one in my opinion. You add someone as a friend, they accept, now you’re friends. But that doesn’t actually mean you’re really friends, nor does it make BuddyPress function differently when viewing other users. Not to say you can’t build custom functions around the “if we’re friends do this, if not do this” way of doing things, but that involves template switches and chopping up code for 1 specific type of relationship with no depth or scope or ability to reuse or repurpose.
It will come to a point where we either build out the friends component with an API that lets “friends” tag each other, categorize each other, and plugin to it (like groups already has, think “friends calendar” functionality,) or we use what’s already here, eliminate duplicate code and functionality, and add a few extra brain cells to the groups component.
The best way to explain why I think this is a good idea (from all perspectives) is that it gives the group component more or less flexibility, by giving it a range that it can reach based on what the site admin allows, and what the user allows, from within an API that already exists.
Real world example: Go to testbp.org and create a group. A group about what? Well, BuddyPress obviously, since that’s what the website is about. What if I don’t want the people in that group to talk to each other, but I just want to group users together that I’ve met in real life? Or at WordCamps? I can’t… They’re not my friends, they’re not colleagues or really even acquaintances, but I met them and want to stay connected somehow. I make a group called “Met at WordCamp”, I check the “User Group” option, I don’t create a forum because they don’t need to talk to each other through me, I add the people I met, and I made a group of people. Now, if I want to talk to all of them at once, I use the activity stream and since they’re all in that group, they get it on their feed and they can all reply to that stream item.
It’s a way to isolate people you already know, and put them in a box for later. BuddyPress already does a wonderful job of making sure you have access to all sorts of information, from people, blogs, groups, and friends. What about when I want to start narrowing down all that information and isolating it into what I think I want to see, and who I want to talk to? That’s what this would/could/should do.
And if your site needs the friends functionality exactly the way it is, it would still be available in exactly the same way it is now, with the same database structure and code and filters and everything else. Only you would need to install it as a separate BuddyPress “add in” like what will happen with the wire component for 1.2.
Maz, I get that “friends” is a very simple 1 to 1 relationship that makes data management easy, but it’s also severely limited in the functionality that it provides. If we grow out the friends component, it would only be to include more group like functionality anyway, right?
At the end of the day my feelings won’t be hurt if the idea gets voted down, so keep pouring on the feedback and brainstorming. It’s been a really great discussion so far and I’m pumped that everyone’s this interested and passionate about the idea.
I’ll have a plugin for BuddyPress post favorites soon. It’s mostly finished but needs some cleaning up for other peoples eyes.
The database structure for the activity component changes quite a bit from 1.1.3 to 1.2/trunk.
That’s a tough lesson to learn, but we all have gone through it at least once.
If this was the direction we’d go, it would probably be something like:
1. Deprecate “Friends” component code into a separate downloadable plugin that can still be used exactly like it is now, just not part of the core anymore.
2. Merge friends functionality into private “user” groups so that developers can choose to ditch the “friends” model if they want, rename it to “homies” or “classmates” or whatever, or keep it if they’d like to. (Boone is right on this one; the skin on top of this additional group functionality would make “friends” look and work pretty much identical to how it does now.)
3. “Friends” would replaced with the core ability to “follow” peoples activity, and for your activity to be followed by others. (Andy and I have also tossed around the idea of when people follow each other, that an automatic friendship is assumed.)
Thanks again everyone for joining in on this with your opinions. Our goal is to keep each component as flexible and adaptable as possible, while avoiding code bloat and also trying to avoid duplicating similar features that could just be one flexible component.
You’re all awesome.
I’d ultimately love to see things go in that direction, and have been sifting through code the past few days thinking of how to get more red in the trac than green.
However, if this was the case, and activity had a component scope and a serialized array of return values, then you could replace private messaging with a threaded activity stream that only the users involved in that thread can view. You could send activity to multiple groups at a time, or only 1, or all of your groups, or the entire site, or any other registered components serialized set of values that mean whatever they mean.
You can almost replace the notifications class all together too, because if you take a count of the number of activities a user has directed at them and store it in usermeta, when the user returns if that number is higher, there’s your total notifications. Filter those new activities and now you can see how many of each. Actually, the code already exists within both WP and BP to do this.
In that regard, the activity stream does start to replace core communication components like forums, private messages, status updates, notifications, and the wire. At that same time, BuddyPress becomes less about separate components with their own API’s and classes and subsets of functions, but more about creating new methods for users to interact with each other in specific scopes of communication.
You could take things like twitter lists and make them work both ways, where you could send a message/comment/update/picture to only specific users instead of only viewing tweets from users. You could create an endless array of ways and names for collaborative tools to develop the platform from within the platform. It’s basically the blog post_types concept attached to people’s activity instead of re-categorizing blog posts.
The way to further develop groups would need a whole new topic, but I’ve got some ideas for that too.
@mrmaz, what you propose is the fundamentals of how I’ve approached my development before finding WP; start with small basic classes and work my up in functionality. There very easily could be a basic “bp_component” class where every new component just extends off of that, and sets the needed vars and assigns the needed functions accordingly.
