Ability to set multiple global Twitter accounts

I actually wanted it for that

Agreed. I was disappointed that twitter_nodeapi is hard-coded to only post to the current user's primary Twitter account. Makes it tricky to do group-twittering through a single account.

Here's a short nodeapi snippet that makes it possible (note: I hard-coded my username/password as defines in my custom module for lack of time to implement a more flexible solution).

/**
 * Implementation of hook_nodeapi().
 */
function drupalchix_nodeapi(&$node, $op, $a3 = NULL, $a4 = NULL) {
  switch ($op) {
    case 'insert':
      if ($node->type == 'tweet') {
        // Post message to Twitter only if it's been posted since the last
        // cron run (or, failing that, within the past hour). Otherwise, we
        // end up spamming the living crap out of Twitter when we import 20
        // messages at once per feed. :P
        if ($node->created > variable_get('cron_last', $_SERVER['REQUEST_TIME'] - 3600)) {
          $status = "RT @$node->title";
          twitter_set_status(TWITTER_USERNAME, TWITTER_PASSWORD, $status);
          drupal_set_message(t('Successfully posted to Twitter.'));
        }

      }
      break;
  }
}

Agreed this would be useful. I had a company website I was working on that only has one global twitter account and the Twitter wasn't really useful in the case.

Very good point, would need this also!

+1.

+1

+1

+2

Ok here's my implementation of a global account in the attached patch.

The patch adds a global Twitter screen name and password combo to the admin settings page along with a checkbox for enable/disable of the feature.

If enabled, the global account is added to the list of Twitter accounts that are available to the user when posting a node. So for users with zero Twitter accounts setup, then the global account would be the only account available. If the user has 1+ Twitter accounts then the global account would simply be added to that list and displayed in the node edit form in the Twitter account dropdown.

Since this is a global account and thus not tied to a single Drupal user I have not implemented any of the features in the module for a regular user's Twitter account so there is not a tweet block or tab on a user's profile page. The tweets for the global account are not downloaded from Twitter and stored on the site.

So basically this is a one-way Twitter integration from the Drupal site to Twitter.

How do you install this patch?

It would be great if it also added a tweet block for that global account.

I would love to install this if someone can tell me how. Also new tweets are not showing up on my drupal site. The only way to get it updated is to re add an account. What can I do to fix this?

I had this pictured slightly differently, where one could add from 1 to N possible Twitter accounts, any one of which could be 'global' accounts, each of which had a hook_perm() entry to specify whether roles could post content to them or not.

This would allow, for example, a group of people to manage the drupal and DrupalAssoc and drupalplanet etc. accounts from one Drupal site, with staggered permissions.

Pie-in-the-sky, maybe, but would be cool. :D

A couple of points...

1. to Malbert75 re:#12 tweets not updating. Do you have cron set up on your site, that is a prerequisite.
2. to Malbert75 re: applying patches, here are the instructions: http://drupal.org/node/60108
3. This global site accounts functionality was in the D5 very old version... I think it worked more along the lines of what jaydub is doing here as compared to webchick's idea.

Shai

The global approach wouldn't have much application in sites I've worked on. However webchick's approach in #13 would be very useful.

Hi folks interested in shared Twitter accounts.

I've written up a proposal for a new Twitter module that addresses the group thing directly while not doing a lot of other things that the Twitter module currently does. Sometimes I think breaking up modules does indeed make sense.

Check it out at: http://drupal.org/node/412118

Let me know what you think,

Shai

uber-plus, double-plus good for 5.x-dev! that's exactly what I need this module for!

jaydub, any chance of making a patch for 5.x?

@Shai: While I'm all for breaking this module up (I was thrown off by per-user Twitter accounts and "post this node to Twitter" functionality being part of the "core" when I expected this to be an API module), I'm not sure it makes sense to move the Twitter account storage part into a separate module. It seems like this functionality is required as part of the "base" in order for any other module to make use of Twitter, and would make the API functions unnecessarily complex if they did not understand where to get the username/password details.

I could also be horribly wrong. ;)

@webchick, not 100% sure if you saw what I wrote in a new issue here, http://drupal.org/node/412118. But anyway...

It seems like this functionality [storing auth info] is required as part of the "base" in order for any other module to make use of Twitter

I think the opposite is true. I think the api module should handle the Twitter API and should remain as flexible as possible as to where auth data comes from. That way it will be able to handle a wider variety of use-cases. You described what seemed to be a pretty simple vision in #13 as being "pie in the sky." I think if the usernames/pw storage functionalities were pulled out off the Twitter core api module then doing what you had envisioned would become a lot easier.

In the case of my specific proposal, the Twitter username and pw would be in the node object on the same page as the Twitter post form. Each node represents one Twitter account and the Twitter Shared Accounts module creates a form to appear on the Twitter Account's node view page. At that point calling a hook_twitter_post (that's a hook name I just made up) and having the auth information in the node object to pass seems pretty easy. I haven't looked at the code so it's possible the current Twitter module would need to be re-written or the proposed Twitter Shared Accounts module provide its own Twitter functions, though obviously using the current Twitter module as an API module would be best, if possible.

So yah, I think you are wrong, but I could be horribly wrong ;)

Yes, I read the proposal. Twitter accounts as nodes makes no sense to me though. If you wanted to add a Twitter account selection to a node form, that could easily be done by pulling the information out of the twitter_account table provided by twitter.module.

It also doesn't make sense to me to de-couple account authentication storage from the API which requires them in order to work. If you look through twitter.inc, twitter_fetch_timeline, twitter_set_status, twitter_fetch_account_info, etc. all require a screen name/password to even function. Twitter module would basically become useless if it needed to require a separate module to do this kind of basic functioning. I'm pretty sure the only thing you could do is read in twitter feeds, and well, that's what Feed API is for.

The reason I described "pie in the sky" at #13 is because the patch in #9 stores only a single account, in the variables table. I find that to be limiting from a system design perspective. As long as there are use cases for storing more than one global account's details (which I outlined at #13), then we should design this feature to take that into account.

@webchick --> "Twitter accounts as nodes makes no sense to me." I guess nodes are in the eyes of the beholder:) To me tying Twitter accounts to individual users or to a "global" setting or settings makes no sense. Why shouldn't one user be able to have more than one Twitter account? Why can't there be 50 global accounts. Why "global" -- how about let drupal's roles and access systems handle all this stuff while creating a simple 1 node -> 1 Twitter account relationship. I'm proposing a database of Twitter accounts.

"Edit, create, delete node" permissions map to the person who controls the keys to the twitter account and actually knows the password.
"View node" permission maps to anyone who can post a tweet from that account.

I actually think that the module I'm interested in shouldn't be called "Twiitter Shared Accounts" because it provides functionality as well when their is only one person with "view node" permission. The module doesn't care how many people can post, that is all set through view node permission.

Of the functions you mentioned, this module would only need twitter_set_status, not the other two. The module I'm thinking of is very light weight. It's so light weight that I don't see that relying on an API module for Twitter functions is so neccessary. And as Webchick hinted at, twitter_set_status is not written as a hook. The only hook I see is hook_twitter_status_update which I'm not interested in.

Lightbulb! I just noticed something which explains the difference in visions here and why I feel that the Twitter module doesn't address my needs. The title for the field added via twitter_form_alter to Twitter enabled nodes is: "Announce this post on Twitter." That is what twitter.module is at its core. It's about adding functionality to advertise the existance of a post on a Drupal site via Twitter. It's a great blogging utility, for example. One stop shop, write your blog, promote it on Twitter.

What I want to do is provide people an opportunity to share Twitter accounts and use Drupal's permissioning system for crowd control. I think they are two different modules.

My two cents... and I should start looking into getting CVS privileges... unless someone convinces me I shouldn't do it...

Shai

What? No. :) This is all going horribly awry! :) Let me try to explain...

The heart of Twitter module is twitter.inc. This is the API part of Twitter. It should basically be analogous to http://apiwiki.twitter.com/REST+API+Documentation (and it mostly is, except for direct message support, but there's a patch for that).

Now, in order for twitter.inc to be a *useful* API, as in self-sustaining and not requiring other sub-(and sub-sub-)modules, Twitter module also needs to provide storage for all of the stuff the API needs to function. This means the ability to store Twitter account data (whether affiliated with a user or not), status messages, direct messages, etc. This is basically covered by twitter.install. It has a table "twitter", which stores twitter messages (might need adjusting for DM support) and "twitter_account" which stores user/password information for authenticating to twitter. It also has views integration for this information, which is really handy.

What we want is a single Twitter module to store this "base" stuff that every other modules that needs to integrate with Twitter needs. For example, Twittergator will allow relaying DMs to tweets. You might make a module called "DrupalToTwitter" which adds more advanced options for sending a post to Twitter, adding permission support, or whatever.

What we do NOT want are 15 TwitterSomething modules, each of which implements part of the API it needs (set status in your module, direct message support in my module), each of which has its own way of dealing with user accounts (users enter their user information as nodes in your module, users enter their user information as a separate table in my module, users have to enter them in BOTH places to use both modules), etc. We want ONE Twitter module that implements the basic API, and any other modules that interact with Twitter to require it as a dependency, use its data structure, and call its API functions.

Now, the current Twitter module isn't perfect. For example, the twitter_user table makes no sense to me, and I would pull that into a separate module, along with the "post Drupal content to Twitter" stuff so that Twitter module were more of a pure API module. There are also bugs that need fixing, API functions that need implementing, etc. But the answer to this is not 15 competing Twitter modules, the answer to this is writing/testing/reviewing the patches in the queue to fix this module up.

So no, please do not write a competing, more lightweight Twitter module. Please instead put the APIs you require to build the module you'd like in this module, and call the relevant functions and such from yours.

@Webchick

I can be totally on board with that.

I should note that what you've mentioned in #15 would be taking a huge amount out of the current twitter.module. That would be great in my opinion. It's also a lot of work. And the module maintainers need to be on board. I don't see a whole lot of active participation from the site maintainers here.

Twitter is booming and for Drupal's module to be so broken is a real shame.

I'm happy to test and contribute to issue queue. I just filed a note about twitter.js not working. I peeked at the code, but I'm hopeless there. It will certainly be more motivating to contribute with active maintainers.

Shai

@webchick,

I guess I have more to say.

If twitter.module is truly going to be an API module that serves other modules --> then it shouldn't impose a data model on them.

This idea I have about letting Drupal's permission system provide the gatekeeping for people sharing responsibilities for posting to company or org twitter accounts is not a wild or wacky idea. If you tell me, "that idea won't work with the Drupal twitter API module" --> then something is wrong with the Twitter API module.

A true Twitter API module wouldn't have tables at all and wouldn't store username/passwords at all. Once you do that, you begin to impose a data model on the modules that depend on Drupal Twitter API.

I think the idea I have to make the JS widget take into account the tinyrurl (or different service) post submission processing (which outputs a consistent number of characters for any URL) while calculating how many characters the user has left is a huge advancement in micro-blogging submissions that should be pretty easy to implement. And that, absolutely, should go into the Twitter API module.

Even if twitter.js were working now, it only gives you an approximate count because of the module's system of using replacement variables to populate the twitter post. (Todd is saliently struggling with this in the queue here: http://drupal.org/node/369224). Because of the presumption of the current twitter.module that the Twitter post's main purpose was to direct people back to an article on the Drupal site, there seems to have been an assumption that truncating Twitter posts and not working precisely within the 140 character limit was OK. That presumption that truncating content is okay should NOT be in a Twitter API module. A Twitter API module should work precisely with the 140 character limit and help posters work within that limit. Another module that relies on the API that wants to truncate content, that would be fine. But in the API module?

So in addition for my desire to see the site maintainers more involved (#23), here I'm advocating that if the Twitter module is really going to be the API module on which others rely, it needs to provide the core and not impose its prejudices on the others.

Shai

The ability to post to a single global Twitter account was added in release 2.3, so I'm switching the title to allowing the addition of multiple global accounts instead. And also back to active, since the current patch doesn't address it.

@Shai: We should probably start another issue to discuss how to break Twitter module down to a pure API part and add-on module(s).

I want to second the desire for multiple global twitter accounts. I suppose it could be done with the current actions integration, but I think built into the UI would make it a lot more promising for integrating into basic workflows.

Is there documentation somewhere on how to display tweets in a block from the global account specified in the twitter admin options? I added the global account username in the admin area, and enabled a block but no tweets display.

Hi,

I want to post some content types to a different twitter account. Is it related to this subject? Is it possible with current version of the module?

Thanks,

Sinan

*subscribe*

+1

Subscribing...

I want to second the desire for multiple global twitter accounts. I suppose it could be done with the current actions integration, but I think built into the UI would make it a lot more promising for integrating into basic workflows.

Has anyone else started the multiple global account work yet? Thanks.

I'm pretty sure this issue has changed meaning significantly since 6.x-3.x, because there's now no place to create global twitter accounts, just a way to set a user's account as "global". I don't think that's a sensible UI, but I don't foresee it changing in the near future, as there are bigger fish to fry in this module.

@Michaek True, i realised all the previous posts mentioned a config page for entering a global account info, yet in the 6.x-3.x versions, there is absolutely nothing of the sort.

Any help please.

There's a "global" checkbox next to accounts owned by a user. Closest you'll get for now!

This is an old feature request which never got a patch towards multiple global accounts. If you're interested in resurrecting it, please file a new issue.

Won't fix for 6.x-2.x.