Switch to using Views to allow greater flexibility

Hi there. Good idea! Going to be thinking about this..

the problem code is in hook_block:

    case 'user':
      $uid = arg(1);
      if (arg(0) == 'user' && is_numeric($uid) && ($content = _follow_block_content($uid))) {
        return array(
          'subject' => _follow_block_subject($uid),
          'content' => $content,
        );
      }
      break;

Not sure the best way to go about this, unfortunately. Maybe this would work on both, but I'm not sure:

     case 'user':
      if ($account = menu_get_object('user')) {
        return array(
          'subject' => _follow_block_subject($account->uid),
          'content' => $content,
        );
      }
      break;

EDIT, whoops forgot the closing php

@q0rban - unfortunately, the user _load functions are a bit wonky in terms of their naming.

http://api.drupal.org/api/function/user_menu/6

'user/%user_uid_optional'
'user/%user/view'

I think the best solution for this would be to add views fields for follow links to user table views. That way you could pass the uid argument to a view no matter the path and pull all the follow links for a specific user.

Actually, the more I think about this, the more I like the idea of using views. What about having views be a dependency of this module, and converting the site and user blocks to a view with block displays. That way people could easily see how to override it for custom implementations.

Another idea would be to have the blog block display be a view block and disabled by default so that people could see how to do it.

Marked #662212: Displaying block 'User Follow' as a duplicate of this issue.

subscribing

@q0rban: First, thanks for all your hard work. Follow is a 'dead simple' (as you put it) little module that provides a TON of great functionality - much appreciated! In reviewing several feature requests with what I'd consider related functionality issues / requests, I keep wondering - in this case for instance - why wouldn't Context be an apt solution? It seems to me, this request and a few others would be amply addressed using Context. Am I just being obtuse? I can't imagine it hasn't been mentioned yet, but I didn't find anywhere it had been.

IMHO a great catchall solution would be to turn the links in to a list (menu?) allowing for fun add-on functionality from modules like Menu Block, Skinr, etc., and perhaps adding the CCK request to more easily (and flexibly) accomodate the Views suggestion you keep hinting at. This would allow, for instance, a set of Follow links broken out and located anywhere on any page, and perhaps in multi-column block format (see whitehouse-social-links, attached) like what Fusion offers through Skinr - and of course, all managed by Context. Just a thought to help keep it dead simple, letting each module do what it does best. :)

I'd be curious to hear what others think. Thanks again.

@paskainos, thanks for this great summary! Can you explain more how you think Context would be a solution? How do you pass in the user id with Context?

Marked #794162: Displaying user follow block with Content Profile module as a duplicate of this issue.

I'm certain this is not the best way to do it, but here's what I did, offered as food for thought:

      case 'user':
        $uid ='';
        $id = arg(1);
        if ( arg(0) == 'node' && is_numeric($id) ){
          $node = node_load(array('nid' => $id));
          if ($node->type == 'profile'){
            $uid = $node->uid;
          }
        }
        if ( !$uid ) { $uid = $id; }     
        if ((arg(0) == 'user' || arg(0) == 'node') && is_numeric($uid) && ($content = _follow_block_content($uid))){
          return array(
            'subject' => _follow_block_subject($uid),
            'content' => $content,
          );
        }
        break;

Why is this a bad solution? For starters, because we don't know that the nodetype's name will be 'profile'. It is on the site I'm working on, but the usefulness ends there.

I pasted it in because if there were another way to determine whether the content in question were a profile (and I'm sure there must be) that test could be put in place of the $node->type == 'profile' conditional. So this should be the beginning of a solution, but only a beginning. Tying the module to Context looks like a good way to go.

Changing the title

subscribe

Better Views integration can only be a good thing as far as I'm concerned. Would certainly allow more flexibility.

Anyone who would like Views functionality for Follow in 7.x, please test the patch in #1419474: Add Views to D7 version of Follow.

I'm closing it because the issue was created a long time ago without any further steps.

if you still need it then raise a new one.
thanks