Create the block "People you may know already"

I need this block for buddlist d5.somebody help me

Hi...it seems work like this has been done for User_Relationships, it is best explained by this comment from sprsquish:

http://drupal.org/node/239162#comment-815753

As I think about this, I wonder if the Facebook approach might be more effective.

Users are given a list of people they may know because X number of their friends know them.

Alice: Bob, Cliff, Daniel
Bob: Alice, Frank, Gabe, Cliff
Cliff: Alice, Frank, Daniel
Daniel: Harold, Alice, Frank

Alice is friends with Bob, Cliff, and Daniel and all three of them are friends with Frank so it's likely Alice also knows Frank. Bob knows Alice and Cliff who both know Daniel, but the admin has required 3 connections before considering a match so the system wont display Daniel as a possible connection to Bob.

Than a mysql query is provided by IceCreamYou in this comment:

http://drupal.org/node/239162#comment-888328

Finally here is actual block code for both mutual and possible relations provided by IceCreamYou:

http://drupal.org/node/239162#comment-968182

Could that be translated to friendlist?

Marius

Here's the thing, which I discovered after I fiddled around with the code I posted in that thread in an attempt to improve it on one of my sites. It's relatively simple to write a query that will grab users and order them by how many of the current user's friends know them. (Of course, I'd have to take a look at the DB structure to make sure.) However, to make it be really good at finding people you know, you also need to have it pay attention to profile fields (like city and workplace if they exist) and you need to be able to weight the fields (because you're more likely to know someone who works at the same place you do than you are to know someone who lives in the same country you do). And once we get into profile fields, we also need to pay attention to fields from Content Profile. And if you want to be able to weight fields, you need a UI, as well as much more complicated queries because you have to assign points for things so you can't just merge results...

The way SN sites do it that are written from scratch (Facebook, MySpace) is to keep separate tables that are chock-full of user-relationship data. Facebook's tables alone are something like hundreds of GB (!) IIRC.

So, if I have time, and if it's wanted, I'll look into writing a simple query that will just order users by second-degree relationship intensity (i.e. how many of your friends know someone else). Thoughts?

What you are explaining makes absolute sense...and man...on the SN site I am developing I use lots of core profile field data. Your theory would pay of huge for me, but I totally understand the complexity of it and would not fit for every user scenario and therefore would be too specific for this module.

From what I understand, the table structure of friendlist is fairly straight forward, however I'm no expert ;)

Your last solution might be just good enough for smaller SN sites, but could soon be not narrow enough since second-degree is most likely to happen fast with more users. However, it would be good to at least try it out and get this concept developed, since it is currently non-existent in Drupal (afaik). Who knows, it could be build on, but it has to start somewhere. I'd love it if we have something to experiment with, off course we couldn't do it without your help.

Let's see what Mercmobily thinks about this ;)

It would be great to try a query that list second-degree relationship intensity...where would we be without pioneering!

Regards,

Marius
(Co-maintainer friendlist)

PS. Thanks for chiming in IceCreamYou!

One thing I should add is that this experiment--in whatever form it ends up taking--will take a heavy performance toll as the number of users and relationships rise. This is especially true as complexity (in the form of profile/content-profile fields) is added due to cross-table lookups. So in terms of logistics, it may be better to have this as a submodule, just to keep the basics accessible to the maximum number of people.

It's "IceCreamYou" actually, as in "Ice Cream" not "I Scream"... hehehe. Many of my Real Life (TM) friends call me Ice.

Anyway: conveniently enough, I think that the code I posted here will work for FriendList as well. All that needs to be changed is {user_relationships} should be switched out with {friendlist_relations}, and AND (ur.approved = 1) should also be removed.

I think you can handle it from there. The PHP needs a little cleaning up (I still needed to learn Drupal coding standards and functions when I wrote the code) but it's pretty basic stuff. You can leave out the mysql_data_seek lines (Drupal does it for us) and remember to replace the RTID and hardcoded domain name appropriately.

If it doesn't work or something doesn't make sense I'll of course be happy to look into it; but I can't test immediately.

You may also want to look at this - it's the beginning (well... most, actually) of a module I wrote for User Relationships that takes care of adding the blocks, settings, and related pages. There's some extraneous UR stuff in there though. And it was for D5, although that's not important for the non-system functions that actually do the work.

In UR, relationships can be either mutual or one-way, and that code is designed to work for mutual relationships; so no, it doesn't change anything.

Mmmhhph... I couldn't figure out how to do that when I wrote the code, but now I know about IN()... :D try this. I haven't tested it.

global $user;
$rtid = variable_get("friendlist_blocks_0_rtid", 0);
//Limits the number of results that will show.
$limit = 10;

$results = db_query_range("
SELECT u.uid
FROM {users} AS u
LEFT JOIN {user_relationships} AS fr ON (u.uid = fr.requester_id OR u.uid = fr.requestee_id)
WHERE (u.uid = fr.requester_id OR u.uid = fr.requestee_id)
  AND (fr.requester_id IN (
    SELECT u.uid
    FROM {users} AS u
    LEFT JOIN {user_relationships} AS fr ON (u.uid = fr.requester_id OR u.uid = fr.requestee_id)
    WHERE (u.uid = fr.requester_id OR u.uid = fr.requestee_id)
      AND (fr.requester_id = %d OR fr.requestee_id = %d)
      AND (fr.rtid = %d)
    GROUP BY (u.uid)
    ORDER BY COUNT(fr.requester_id OR fr.requestee_id) DESC
  ) OR fr.requestee_id IN (
    SELECT u.uid
    FROM {users} AS u
    LEFT JOIN {user_relationships} AS fr ON (u.uid = fr.requester_id OR u.uid = fr.requestee_id)
    WHERE (u.uid = fr.requester_id OR u.uid = fr.requestee_id)
      AND (fr.requester_id = %d OR fr.requestee_id = %d)
      AND (fr.rtid = %d)
    GROUP BY (u.uid)
    ORDER BY COUNT(fr.requester_id OR fr.requestee_id) DESC
  ))
  AND (fr.rtid = %d)
  AND (u.uid NOT IN (
    SELECT u.uid
    FROM {users} AS u
    LEFT JOIN {user_relationships} AS fr ON (u.uid = fr.requester_id OR u.uid = fr.requestee_id)
    WHERE (u.uid = fr.requester_id OR u.uid = fr.requestee_id)
      AND (fr.requester_id = %d OR fr.requestee_id = %d)
      AND (fr.rtid = %d)
    GROUP BY (u.uid)
    ORDER BY COUNT(fr.requester_id OR fr.requestee_id) DESC
  ))
GROUP BY (u.uid)
ORDER BY COUNT(fr.requester_id OR fr.requestee_id) DESC
", $user->uid, $user->uid, $rtid, $user->uid, $user->uid, $rtid, $rtid, $user->uid, $user->uid, $rtid, 0, $limit);

//I recommend including the user's avatar in the list and scaling it down to 20x20, but I did not include that here.
while ($row = db_fetch_array($results)) {
    $account = user_load(array('uid' => $row['uid']));
    $list[] = theme('username', $account);
}

return theme('item_list', $list, NULL, 'ul', array('class' => 'user-might-know'));

Hmm. Well, I don't think the query will change, except that the first u.uid may need to be wrapped in DISTINCT().

Just tested by replacing {friendlist_relations} with {user_relationships} (I don't have time to set up a friendlist testbed). It works, except that I left a whole lot of ur's in the query when they should have been changed to fr. (I edited the comment and it's fixed now.)

Cheers! I love it when things work the first time.

Hi Merc...I guess I was sleeping during this discussion...aha, the joys of timezone.

I will give it a spin and report any issues if I see any...thanks for the help IceCreamYou.

As far as resizing the avatar, there are actually already modules that do that, so it might not be necessary. The easiest solution for that would be to include a tiny css file and set the picture size there? It is easily overwritten with a custom picture size by the themer.

Regard,

Marius

Hi,

Since this one is marked as fixed, after all the block _is_ created, I have opened a new issue for _problems_ ;)

Currently it is not accurately returning results: http://drupal.org/node/315189

Regards,

Marius