Twitter Tab shouldn't be visible if user has not given his account informations

I can confirm this problem. Uninstalled, reinstalled, tried dev version -- nothing changes.

Are you looking at the "Twitter" tab or the "Twitter accounts" sub tab under "Edit"?

The main Twitter Tab is controlled by the tweets View, and will be empty if there are no Twitter status' imported.

http://drupal.org/node/448676#comment-1587782 is the way to go.

The fact that the Twitter tab is shown even if the user has not given his Twitter account information is very irritating.
The Twitter Tab should not show up if the user has not given his account informations. Should we open another issue for that?

Woah, this was irritating and should really be fixed.

I hope no one minds that I've bumped this up to critical status. This (fantastic) module is basically useless as long as this bug remains.

I've got a company site with a global twitter account, but only employees can use it (of course). I don't want other site users (clients) looking at an empty Twitter tab on their profile pages wondering what that feature does. I assume that this is not an uncommon application of this module.

I'm still building right now, but I'm thinking of a hack at the theme layer (once I get around to it) to get rid of the tab (since I don't need it on any user's profile page, actually). I'll post it here if it works for me.

Subscribing.

Subscribing. It really surprised me when I saw this "bug". It confused me a little as I thought I set up something wrong.

#PS: Also the tab shouldn't be shown if the " Import Twitter statuses" is disabled. It doesn't make sense to disable importing the Twitter statuses and show a blank page.

I was hoping to be able to get this out at the theme layer, but instead I had to do a very minor hack to the module. In "twitter.views_default.inc" at about line 135, I replaced this:

  $handler = $view->new_display('page', 'Page', 'page');
  $handler->override_option('path', 'user/%/tweets');
  $handler->override_option('menu', array(
    'type' => 'tab',
    'title' => 'Twitter',
    'weight' => '1',
  ));

with this:

// this commented out section added a twitter tab to all user profile pages

//  $handler = $view->new_display('page', 'Page', 'page');
//  $handler->override_option('path', 'user/%/tweets');
//  $handler->override_option('menu', array(
//    'type' => 'tab',
//    'title' => 'Twitter',
//    'weight' => '1',
//  ));

This removes the twitter tab from all profile pages (it actually prevents views from defining the page) without modifying the remaining featureset of the module (at least as far as I use it).

This does the job for my purposes, but I suppose if you wanted to use a less draconian measure, you could put conditionals on the original section of code, restricting the display of the tab and/or creation of the page by uid or role. This might also be where this feature would be patched for a future version of the module (so it could be configured in the admin), but I don't know enough about drupal module programming to make this happen. Anyone care to take it on?

Put in your hack but I still see Twitter tabs... some kind of cache flush required?

Edit: yup. Had to do a total cache flush.

Subscribing

+1 for this fix.

We are not planning to dish out Twitter privileges to hundreds of users due to scalability concerns, but we want staffers to be able to use this module. Hiding the Twitter tab is important.

Subscribing, definitely would like to see this changed.

I don't even plan to allow my staffers to use the module directly. I want it to be used for news updates during live coverage events, like a local high school football game. Yes, we're a community newspaper.

With that in mind, I decided to remove the tab all together in favor of people tweeting from their phones remotely with a change to my template.php file.

function themename_preprocess_page(&$vars) {
  // Remove undesired local task tabs.
  // This first example removes the Users tab from the Search page.
  endless_news_removetab('Twitter', $vars);
}

function themename_removetab($label, &$vars) {
  $tabs = explode("\n", $vars['tabs']);
  $vars['tabs'] = '';

  foreach ($tabs as $tab) {
    if (strpos($tab, '>' . $label . '<') === FALSE) {
      $vars['tabs'] .= $tab . "\n";
    }
  }
}

Subscribing.

+1 on hiding this tab for folks who are not using twitter.

Subscribing

Simple fix: Site Building > Views > scroll to 'Tweets' > hit 'Disable'

Thought I'd better post this before the next "suggestion" involved hacking core...

Yeah you can disable the twitter view from views (which I did), but this issue is about hiding the tab only if the user hasn't entered any twitter info.

I did a similar hack for the FriendFeed module in drupal 5, but that hack doesn't work in drupal 6 (I'll work on it when I have more time): http://drupal.org/node/277826

It involved loading the user object (user_load) and checking for the existence of the setting (probably not optimal, but it worked at least). You could also just do an SQL query yourself, similar to what the user_load object does, but more lightweight: http://api.drupal.org/api/function/user_load/6

This is a common thing with other views (with tabs/menus) too, so it'd be nice as a general feature (conditional views?).
Or since menus & tabs already dynamically hide based on permissions, perhaps it could be connected to that somehow.

Attached is a small patch that will cause the tab to display only if the user has permission to add a personal twitter account. Once patched, you'll have to clear your cache for the change to take effect.

Hope I get the time to try this soon.....

Against which version is this patch?

6.x-2.6

I updated my friendfeed patch to work for drupal 6, if you want to adapt it to the twitter module. It hides the menu tab if the user has not entered any friendfeed info in their account.

The key part is the menu 'access callback'. Add that to wherever the twitter menu tab is being created (in the menu hook).

function _friendfeed_user_tab_access($account) {
  return user_access('view friendfeeds') &&
         !empty($account->friendfeed_username) &&
         !empty($account->friendfeed_key);
}

function friendfeed_menu() {
  return array(
    'user/%user/friendfeed' => array(
      'title' => 'FriendFeed',
      'description' => 'View FriendFeed status.',
      'page callback' => 'friendfeed_user_view',
      'page arguments' => array(1),
      'access callback' => '_friendfeed_user_tab_access',
      'access arguments' => array(1),
      'type' => MENU_LOCAL_TASK,
    ),
  );
}

Subscribing
I'd love to see this fix in the module and not just a patch!
Sounds like many people have the same issue with only wanting to allow a subset of users to have twitter accounts!

thank you to garethsprice, you saved me a lot of time and trouble... your solution was all i needed for my site.

Thanks "garethsprice" ..

garethsprice's solution works, but only if you don't actually want your tweets to be displayed somewhere.

Here's how I solved the problem:

1) Go to: admin/build/views/list
2) Edit the "Tweets" view
3) Select "User page"
4) Under "Page settings", change the "Menu" setting to "No menu"

Worked like a charm!

I think it is clear now that you can completely disable the views display, but that is not the issue.

And though showing the tab on a role basis is nice, I think it would be better if it only shows if it is not empty.

Any development on this? This issue is more than a year old.

Ok, with a lot of patience and help on irc chat, hefox provided me this working solution.

In the User Page argument use these settings:

- User page: Configure Argument User: Uid
- Action to take if argument is not present > Provide default argument > User ID from URL + Also look for a node and use the node author
- Validator options > PHP code:

<?php
$uid = arg(1);
if (!empty($uid)) $account = user_load($uid);
$twitter_accounts = twitter_twitter_accounts($account);
if($twitter_accounts) {
return true;
}
else {
return false;
}
?>

Hope it helps others as well.

Edit: I should write an argument validation plugin for this, but currently this is a bit above my skillset. :) Maybe later. I'd love to learn how to do this.

#26 fast and easy, thanks!!

A simpler fix, for people who want to use only the site-wide Block and are not interested in making user/UID/twitter available for ANY user accounts -

1. Edit the Tweets view @ admin/build/views/edit/tweets
2. Edit the "Page" display
3. Click "Basic Settings" => "Access"
4. Select "Twitter" => "Add Twitter Account"

This should prevent people from viewing user/UID/twitter for any user account, including their own; the tab will then vanish for your regular users.

#30 worked for me, thanks Grobot! No patch necessary.

This is still a bug in the module that needs fixing -- either with the change described in #30 as a patch to the default view, or the PHP code in #28, or the custom validator.

I'm using a "glue" module so I can use the menu_alter hook.

function mymodule_menu_alter($items)  {

  if (module_exists('twitter')) {
    $items['user/%views_arg/tweets']['access callback'] = 'mymodule_user_has_twitter';
  }

}

function mymodule_user_has_twitter() {
  return arg(0) == 'user' && count(twitter_get_user_accounts(intval(arg(1)))) > 0;
}

Beware of this bug too #951148: twitter_twitter_accounts() should pass the user_access() the $account parameter

#28 works (6.x-3.0-beta3) - hides the tab unless user has tweets.

Thanks Danny_Joris!

+1 for #28. a more permanent fix would definitely be good, but this will certainly suffice. :)

Rolled this patch for D7, looks like it applies cleanly, unsure if this is the correct way to set up a Views PHP argument validator but it seems to work.

Tested on D7 only. Please apply this to your 6.x, test and report back.

Patch works great with D7. I went ahead and hijacked this thread to 7.x since that's what the patch was for. Let's get this committed.

Applied. Now checking if the bug occurs at 6.x-3.x in order to fix it there too.

http://drupalcode.org/project/twitter.git/commitdiff/609b0873b4c45ff7ad5...

The above will be available in the next beta release next week.

Applied an updated version of the patch at #36 to suit the Drupal 6 version.

http://drupalcode.org/project/twitter.git/commitdiff/51759531b693f6ea166...

Reopening, 3712f1c91d482c756214222129289c6fb68f674a did not fix the issue on my systems.

twitter_twitter_accounts() always return an array so our view argument will always validate, we should test the array for content with something like the attached patch.

Doh, too quick there. Try this one, it also contain the fix in #951148: twitter_twitter_accounts() should pass the user_access() the $account parameter that we need to get committed.

The previous patch does not apply properly, not sure if it was rolled against 6.x.

Here's a version of it, for 7.x-3.x, but instead of modifying the default php argument for the view, we return false if the $twitter_accounts array is empty, inside twitter_twitter_accounts().

Yeah, it was rolled against 6.x, sorry forgot to mention that. Your code is much more elegant, I simply tried to make sure that the code introduced in #39 and got committed actually worked.

I could not commit the patch written by steinmb and Manuel Garcia because it changes the hook signature of hook_twitter_accounts(). This could cause serious problems on modules that implement hook_twitter_accounts and check what is the type of the returned value. Hence, it should always be an array.

I have changed the way that the view evaluates the array so it does not always return TRUE.

http://drupalcode.org/project/twitter.git/commitdiff/5b4e1214b6ceeb7d192...

Thanks to everyone for the good job.