Author Pane integration problem

tsi, we need a lot more information to know what's wrong. Integration between FBS and AF should work by default. Did you read an old thread and think you had to make some kind of change for it to work?

PHP and SQL versions?

Weird. Ok, try this. In advf-author-pane.tpl.php, find this code:

      <?php if (!empty($facebook_status_status)): ?>
        <div class="author-pane-line author-facebook-status"><?php print $facebook_status_status;  ?></div>
      <?php endif; ?>

and change it to

      RIGHT BEFORE STATUS
      <?php if (!empty($facebook_status_status)): ?>
        STATUS NOT EMPTY
        <div class="author-pane-line author-facebook-status"><?php print $facebook_status_status;  ?></div>
      <?php endif; ?>

Then clear the cache, go to a forum post, and see if those two lines show up in the author pane. That will tell us 1) that it's getting to the right spot and 2) that the variable has something in it.

Michelle

Hopefully this is obvious, but do the users you're trying this with actually have statuses?

Also, do you have the User Relationships module installed? If so, have you selected a relationship type(s) to use?

If the users you're trying this with have statuses, run this code somewhere and see if you get anything.

  //Change the UID based on which user you want to test.
  $uid = 1;
  echo '<pre>facebook_status:';
  $account = user_load(array('uid' => $uid));
  $status = facebook_status_advf($account, TRUE);
  print_r($status);
  echo 'facebook_status_status:';
  $status = facebook_status_advf($account, FALSE);
  print_r($status);
  echo '</pre>';

Do you get any error messages in your log?

If the variable is empty, then it's beyond what AF can fix. Tossing it over to your queue, ICY.

One other thing to check... Didn't you add some sort of permission for viewing?

Michelle

Hmm... Very strange. Do you have the devel module installed? If so, try this in facebook_status.author-pane.inc:

function facebook_status_preprocess_author_pane(&$variables) {
dsm("In pre-process")
  $account_id = $variables['account']->uid;
  if ($account_id != 0) {
    $variables['facebook_status'] = facebook_status_advf($account_id);
    dsm("Status:");
    dsm($variables['facebook_status']);
  }

And see what you get. If you dont' have devel installed, you can try replacing the dsm()s with prints, but I'm not sure if it will work. Print doesn't always print depending on where you are in the whole sequence of page building.

Michelle

Changing title since it's in my queue... :-P

tsi, you should have gotten something like this:

facebook_status: IceCreamYou is happy.
facebook_status_status: is happy.

As far as UR, look at the attachment. You should have the setting that's surrounded by a red box set to "Ignore Relationships." (And yes, Michelle, you do need the permission "view author_pane status"... and it's remotely possible that that permission may not appear if FBS is installed before AP, although it may just require that the caches are flushed or something. tsi, if you can't get the permission to appear, decrease the weight on the facebook_status module in the system table in your database and see if it shows up.)

tsi, if you don't have devel installed, you can store your results from Michelle's code using variable_set() and then access that later; they probably won't print.

Also, try this and see what you get. Change this in advf-author-pane.tpl.php:

      <?php if (!empty($facebook_status_status)): ?>
        <div class="author-pane-line author-facebook-status"><?php print $facebook_status_status;  ?></div>
      <?php endif; ?>

to this:

        <div class="author-pane-line author-facebook-status"><?php var_dump($facebook_status_status);  ?></div>

Ah. That explains it. No need to install devel.

That permission is loaded conditionally if author_pane is installed, but apparently permissions are cached, so if you install AP after FBS the permission won't show up. It's also not a cache that you can refresh from the interface AFAIK.

The easiest solution is to remove the condition on the extra permission appearing. However, that would mean that the permission would appear even for people who don't use AP--that is, for those for whom it is entirely irrelevant, which is less than satisfactory although relatively minor. Another option would be to move AF integration into a sub-module, which is also less than ideal but probably a better option.

Michelle, do you happen to know anything about this? I asked on IRC and got no response.

tsi, in the mean time, just change the function facebook_status_perm() to this:

/**
 * Implementation of hook_perm().
 */
function facebook_status_perm() {
  return array('edit own facebook_status', 'edit all facebook_status', 'view author_pane status');
}

...and then enable the permission for appropriate users.

Would you prefer it if I moved the permission to AP? Would need renaming or it won't make sense but I'm fine with that. TBH, though, I can't remember why we have the permission. What was the reasoning for having an extra permission to view the status on the Author Pane as opposed to anywhere else it shows up?

Michelle

It wouldn't make any difference if the permission was moved--if it was moved it should appear conditionally based on whether FBS is installed; and anyway then I'd have to check if AP was installed separately, before the permission check instead of with it. And the permission exists because it's the only place the admin can't control which users can see the status; the rest of the module only shows up in blocks (or in custom code).

I've removed the AP check for now. When I get around to writing the 2.x branch I'll move AP integration to a submodule.

Hmm... If that's the case, why not just add a generic permission for "view facebook-style status"? Then it can be used by anything that displays the status and you don't have to worry about whether this or that module is installed. I'd hate to see you make a submodule for such a tiny bit of code. If this is really going to be a PITA for you, I can pull the integration into AP.

Michelle

If I called it that, users would expect that permission to govern how the status shows up everywhere. I might make it do that in 2.x, but it's impractical in the 1.x branch at the moment. It's really not that big a deal though; if I do end up adding a submodule, it quite literally requires no more work than copy-pasting the facebook_status_advf() function into a new module file and writing a one-line hook_perm(). Plus, it technically should amount to a performance improvement for anyone not using the integration. I really don't think it's worth moving the permission, either, because the same problem of checking if the other module is installed would still exist.

Really, the ideal solution would be to find a way to flush the permissions cache when AP is installed after FBS (assuming that's what causes the problem). I am decidedly unsure how to do that, however, or if I'm even right that permissions are cached that way.

I wouldn't worry too much about it.

Well, it's up to you how you want to handle it. I just didn't want you to have so much work to integrate these.

Michelle

Michelle: thanks.

tsi: presumably you set the permission for the user roles you want? Note that often User 1 is not in most roles. Also, did you change advf-author-pane.tpl.php and facebook_status.author-pane.inc back to their original state after making the changes suggested in this thread?

If facebook_status_advf() is working as expected, which it seems to be according to what you've told us, that probably means that either facebook_status.author_pane.inc is formed incorrectly, or the variable preprocessing isn't working. Clearly the variable preprocessing is working or you wouldn't see anything at all in your author pane, so my first guess is that facebook_status_preprocess_author_pane(&$variables) isn't formed the right way. (Michelle--care to take a look?) However, if that was the case, I would have expected other reports of this... so I don't really have any ideas at the moment.

Did you ever try #8? I don't really know what could be wrong, either. The integration works just fine for me.

Michelle

In regards to #8: if you don't have devel installed use this code instead:

function facebook_status_preprocess_author_pane(&$variables) {
  $x = "In pre-process; ";
  $account_id = $variables['account']->uid;
  if ($account_id != 0) {
    $x .= 'In $account_id condition; ';
    $variables['facebook_status'] = facebook_status_advf($account_id);
    $x .= "Status: ". $variables['facebook_status'];
  }
  variable_set('fbs_ap_test', $x);
}

...then run this code later and see what you get:

print check_plain(variable_get('fbs_ap_test', 'nothing saved'));

Note that this will only show you the last user's status which was processed for the page (assuming it shows you anything at all).

You might also try simply replacing dsm() with drupal_set_message().

There are only a few possible explanations for this.

• The user you're trying this with doesn't have a status.
• The user you're trying this with doesn't have permission to view the status.
• You're not using the latest versions of one or both modules.
• Your pages are cached and haven't updated to reflect changed code.
• $account_id is somehow always wrong (highly unlikely).
• You're using another module that interferes with the process (highly unlikely).
• You're cursed, and you need to travel to Siberia, retrieve a striped lizard, and sacrifice it on a gold altar. And then eat a chicken sandwich. And then laugh a little.

I know this because the only thing that appears to be not working in #23 is facebook_status_advf(), but you demonstrated in #7 that the function is working as expected. In addition, Michelle said in #21 that it works for her, and I know that there are a number of people who use both modules who have not reported this problem.

All of that indicates to me that this is not a problem with the code in either module. Certainly it's not one that anyone but you can fix with the information you've given us. I will continue to try to help you if you have some kind of discovery that provides some missing piece of information, but otherwise I'm going to mark as "won't fix" in a few days.

:D