BuddyPress.org

Works on 1.1. Although there are a few bugs. It doesn’t appear to be in active development at the moment however and breaks when used with the new default theme in 1.2-rare (development version of BP). We’re all hoping it will be kept up-to-date since it’s a great and much needed plugin.

I’m pretty much good with all of this.

Back to what Mike was saying in response to my woolgathering: I do tend to think that there is a good intersection between traditional forum/thread/comment structure and the kind of social-networky way of (not) organizing things, and that Buddypress is heading in that direction, particularly with the new activity/threadedness stuff.

But traditional forum-like structure, to some degree, is still what most un- or semi-sophisticated users who haven’t grown up with social networking kind of expect, I think. That doesn’t in any way mean that it’s the best way of doing things, though, as you say.

The optimum path, as you suggest, I think is to continue to rethink things a bit (as Andy and everyone else who’s contributed to Buddypress has been doing) so that we can leverage the best of both worlds — the structured, heirarchical, predictable (if hard to search) architecture of the traditional forum along with the interconnected, non-heirarchical, loose-coupled, folksonomical, social, person- and activity-focussed interconnected peopleweb New Way.

Hit that point just right in terms of architecture and UI design, and we’re not just reinventing Facebook or PHPBB or mashing them up, we’re doing something that’s made of awesome and sauce.

I have tried it now with city, state combination and it seems like it is working better.

one thing to note though is that since the indexing is done using lon and lan the distance that you are actually getting is an aerial distance between two points (not driving distance etc.)

Thanks,

Shai

Thanks. That clears things up. The only other problem I’ve encountered is after I deactivate the BuddyPress plugin and re-activate it, I’ll get the follow db errors:

WordPress database error: [Duplicate key name ‘useritem’]

ALTER TABLE wp_bp_notifications ADD KEY useritem (user_id, is_new)

WordPress database error: [Table ‘wp_bp_activity’ already exists]

RENAME TABLE wp_bp_activity_user_activity_cached TO wp_bp_activity

WordPress database error: [Duplicate entry ‘1’ for key 1]

INSERT INTO wp_bp_xprofile_groups VALUES ( 1, ‘Base’, ”, 0 );

WordPress database error: [Duplicate entry ‘1’ for key 1]

INSERT INTO wp_bp_xprofile_fields ( id, group_id, parent_id, type, name, is_required, can_delete ) VALUES ( 1, 1, 0, ‘textbox’, ‘Name’, 1, 0 );

The Supporter plugin only protects access to themes and plugins once you’re a registered user. I think what we’re all after is a means to turn BuddyPress into a PAID platform – where you have to pay to create a profile or see anyone elses.

Anyone have any luck with this so far?

Hi Again,

Removing the / seems to help though I am still having issues:

1) in my test system I have 5 users and only 4 were indexed.

2) for some reason out of the 5 users it seems that 2 users got indexes twice so that the contenct of wp_bp_user_geo is:

1 1 37.3052272 -121.9871217

2 1 37.3052272 -121.9871217

3 3 19.8819564 41.6909381

4 3 19.8819564 41.6909381

you can see that rows 1 and 2 and rows 3 and 4 are identical (second column is userid) so what happens when you run the search is you get the same result showing twice (while some users are not indexed at all).

Anyone ran into something similar and can help here?

Thanks,

Shai

Looks great, will try building this in my own theme theme as well.

Thanks!

I’m not the author of that plugin, but I’ve rewritten the code for it, it’s available here:

https://buddypress.org/forums/topic/buddypress-analytics-kills-dashboard#post-31962

Okay, I got sidetracked by a couple of client phone calls. Just sat down to take a look at the file. A forward slash appears to be the culprit. Deleting it seemed to work for me:

var someUrl = “/?bp_geo_index=” + num + “&bp_geo_last_loc=” + lastLoc + “&bp_geo_last_lat=” + lastLat + “&bp_geo_last_lon=” + lastLon + “&bp_geo_last_user=” + lastUser + “&_ajax_nonce=” + bpGeoNonce;

Becomes:

var someUrl = “?bp_geo_index=” + num + “&bp_geo_last_loc=” + lastLoc + “&bp_geo_last_lat=” + lastLat + “&bp_geo_last_lon=” + lastLon + “&bp_geo_last_user=” + lastUser + “&_ajax_nonce=” + bpGeoNonce;

EDIT:Again, this is inside of the buddyPressGeoRebuild function, in Geo.js.

Also: Searching by zip appears to function just the same as by city. Hope that helps you guys out. I’m going to go test to see how new users sync up. I’ll post back to see what I find.

Thanks for further explaining yourself JJJ, and I like the general concept behind a lot.. But the idea that speaks to me the most is making BuddyPress in general more flexible and not “hook” into the group API but make a new one based on that which can not only be used for groups but also for users (and thus friends options).

The idea to make a general API which can be hooked in by the Core components and 3rd Party plugins seems to me the best solution. If you take the group API for example and use it’s functions for individual users:

– Add extra signup pages/fields

– Add new pages

– Add new navigational items etc

All these things are possible with the Group API but take lots of work with a regular profile. Like MrMaz said you could break these functions into smaller parts which can be called upon and extended upon for Groups, Users, Friends and the Activity stream.

The amount of possibilities for new plugins would be endless Once again I’m no programmer and this is coming from as a site admin/BP enthousiast/”Copy and Paste and pray to god I don’t get a white screen of death” kinda guy..

edit: I would also like to say that Mike perfectly summorized my exact ideas of what a group should be and what a group of friends means. Well spoken. I’m getting a Deja Vu here lol

Erwin Gerrits of bp-events fame http://www.erwingerrits.com/?page_id=799 had, at one point, used the Google maps api to add map functionality to the plugin.

What we should really do is build a plugin that grabs ever field you specify, in the order you state mashes them together into the form of an address and then plots them on Google maps.

@jjj You confuse Group with “grouping of friends” I get your point but you wouldn’t create a group on TestBP.org just to group your friends. That’s not what a group even means. It is an aggregation around a concept or a topic that people self associate/ask to be a part of or are invited to associate with. It’s like a little contextual club within the site. What you are speaking of in your example is a grouping of friends which the BP Api should allow for and hopefully will. The you’ll be able to filter by friends or groupings of friends. That becomes personal. On the group side, you can join Groups and then say “keep me up on all that happens in said Group” or better yet, show me activity in Group X by my friends only.

Friending someone does have meaning. it means you care about that person’s activity. At this point people who try to shoehorn the traditional definition of “friend” into the social media-sphere will end up pulling their hair out. It was a co-opted term from the start. We have to live with that.

All said, John, I am your friends wether we click a button or not

Last post from me on this thread, just for the record and to summarize, I support John James Jacoby’s vision 100%.

Restructering friending around groups and microblogging/activity stream is a next step in where social web is going. Groups would become extremely useful for all kinds of use cases. It would really set Buddypress apart.

Buddypress can’t be all things to all people imho. Development should focus on a conceptually coherent core, with APIs that make it easy to plug in other more linear functionality, like classic friending and forums.

Do we need to re-invent the wheel ?

Buddypress shouldn’t just copy Facebook – apart from perhaps the registration process… BP has the opportunity to do things different, better, move things forward.

hmm…I am not a FaceBook user, but it seems 300 million people are.

How are “all of the above mentioned” things being done at FaceBook ?

Do we need to re-invent the wheel ?

Although it’s irritating, but can’t we just get all of the developers here who are interested in creating a chat plugin and build it from scratch, together?

I’d be happy to work on the UI and co-ordinate developers?

TLDR version: Introduce types of groups. e.g. “User group” type – it has no forum, no “Home” page, just members listing and activity stream. This group added to Activity Stream filters where relevant.

Would have to filter out custom group type “User group” out of the /groups/directory page & member profile group page.

These custom group types could be set so they are publicly visible/private to those members involved/or hidden (visible to the creator only). As per current Group privacy settings.

Could add e.g. “Friends”, “Colleagues” and “Fans” as default, empty groups for each user on user registration. Obviously revise theme to make the “Friends” page (“Connections”, maybe) look like the Friends page rather than a regular Group.

Different users might create “User group” types with the same name but with different meaning (“Fans” could be interpreted several ways for example). This is no problem as such categorisation is defined — and belongs to — the user who does it. Might need some semantic group kind/type identifier in the code to allow FOAF/SIOC RDF profiles to be able to assigned to these “User groups”.

@jjj

Just a little clarification, not meaning to nitpick. In my post I said that friendship is a one to many relationship, since each person can have one or more friends, but yes, each relationship in and of itself is a one to one mapping.

I think I have a pretty good idea of what you want to accomplish, but I still think you need to re-think how to get there.

Based on everything you have said, what is needed is to make friendship more abstract so that it can be extended. For instance so there can be more than one type of friendship. You could even have layers of friendship types without making things complicated as far as data storage goes. Once you have some abstraction then powerful filtering becomes possible.

And instead of using groups to accomplish the grouping of friends so that you can use the group component’s features, it would make a lot more sense to refactor those features out of the group component so they can be re-used elsewhere. So if there is a particular feature of groups that you want to use for something else, ask yourself how to move that functionality vertically into the core API instead of merging components horizontally to share features.

In case all of that is unclear, basically what I am trying to say is instead of moving functionality around, break it up into smaller generic bits that can be re-used. You get rid of lots of code duplication and increase the depth of the API, while not losing any features.

It does indeed work with WordPress 2.9, however none of my registered members are showing up. The only account that shows up in the member listing is the admin account.

The default members page filter is “active members”. If they haven’t logged in and been active since BuddyPress was activated they will not show. If you change the filter to “Alphabetical” or something else, they will show.

Have any of your registered members logged in since you activated BuddyPress? (i.e. log out + log in, to remake the cookie)

I had e-mailed one of the developers, and he stated that it’s designed to run on a city/state field (eg: cleveland, oh), and was unsure if a zip would work correctly. However, check out the URL when you input a zip for the search “near location”: It turns the zip into the proper lat & long values. So, assuming your users are indexed, it looks promising that a zip can be used. (For the time being, I input values for my users into the DB table myself. However, it doesn’t seem they’re properly indexed this way, as they don’t appear through searching near their location. In addition, and most importantly, this isn’t automatic as it should be.)

@shaisimchi: The developer I spoke with also said to check the JS error console when you click the “here” link. I did that, and there were no errors. However, by doing some rudimentary JS debugging, it appears the error is coming during the call to the buddyPressGeoRebuild function in Geo.js, (at least for me). In particular, it’s the jQuery.get that seems to be causing the issue. I’m just sitting back down to play around with it, so I’ll let you know if I find the issue and, hopefully, a solution. If you get the chance to look at it and happen to figure it out, please let me know as well.

We all have to remember that BuddyPress sites can use any or all of the components; what is right for one site is wrong for another (and vice-versa).