http://apiwiki.twitter.com/Twitter-Search-API-Method%3A+search

CommentFileSizeAuthor
#11 584514-twitter-add_twitter_search_to_api-r3.patch5.29 KBxurizaemon
#9 584514-twitter-add_twitter_search_to_api.patch4.07 KBxurizaemon
#5 twitter_search_support.patch4.89 KBlittleviking001

Comments

Anonymous’s picture

Anonymous (not verified) commented

I would absolutely love to see this as well. I love everything about the twitter module. Adding this feature would really complete it's feature set.

Thanks!

Flplsx’s picture

Flplsx commented

This feature would bring the module into a whole new class of awesome!

lyricnz’s picture

lyricnz commented

The (not insurmountable) problems are:
- search uses a separate URL http://search.twitter.com
- the results are not the the same format as other methods in the same API, requiring unique theming/presentation

That being said, I'm using the following code in one of my modules:

/**
 * Implement the "search" method from Twitter.
 *
 * @see http://apiwiki.twitter.com/Twitter-Search-API-Method%3A+search
 */
function mymodules_twitter_search($query, $rpp = 10) {
  module_load_include('inc', 'twitter');

  $url = 'http://search.twitter.com/search.atom?q=' . urlencode($query);
  $url .= "&rpp=$rpp";
  
  // $response = _mymodule_twitter_fetch_xml($url); // drupal_http_request() + status check + caching
  // roughly equivalent to:
  $results = drupal_http_request($url);
  $response = $results->data;

  // Process the response
  $tweets = array();
  $xml = simplexml_load_string($response);
  if ($xml) {
    // Add search metadata
    $tweets['metadata'] = array(
      'id' => (string) $xml->id,
      'title' => (string) $xml->title,
      'link' => (string) $xml->link[0]['href'],
      'updated' => (string) $xml->updated,
      'query' => $query,
    );
    // Add individual tweets
    foreach ($xml->entry as $entry) {
      $tbits = $entry->children('twitter', TRUE);
      $tweets[] = array(
        'id' => (string) $entry->id,
        'published' => (string) $entry->published,
        'link' => (string) $entry->link[0]['href'],
        'title' => (string) $entry->title,
        'content' => (string) $entry->content,
        'updated' => (string) $entry->updated,
        'image' => (string) $entry->link[1]['href'],
        'source' => (string) $tbits[0],
        'lang' => (string) $tbits[1],
        'author name' => (string) $entry->author->name,
        'author uri' => (string) $entry->author->uri,
        'xml' => $entry->asXML(),
      );
    }
  }
  else {
    drupal_set_message('Cannot load XML: '. $url, 'error');
  }

  return $tweets;
}

This probably doesn't support ALL the ways results can arrive (multiple links, images, etc), but works pretty well for me. If module maintainer is interested in adding search to twitter, this might be a useful start.

abraham’s picture

abraham commented
Version: 6.x-2.6 » 6.x-3.x-dev

Twitter is planning on unifying the data objects on their REST and Search APIs sometime this year: http://apiwiki.twitter.com/FAQ#AreyougoingtomaketheRESTAPIandtheSearchAP...

littleviking001’s picture

littleviking001 commented
StatusFileSize
new twitter_search_support.patch4.89 KB

Here's a patch that's been working well for me. It adds a field for a global search string on the admin/settings/twitter page.

---
Developed by ActiveLAMP, sponsored by Causecast

bdwelle’s picture

bdwelle commented

+1 on this feature

I installed the patch and it seems to work fine.

thx!

dragonwize’s picture

dragonwize commented

I've created a module using some of the ideas and code here with some additions and modifications of my own. It still needs a little work and more testing. Volunteers welcome: http://drupal.org/project/twitter_search

sirkitree’s picture

sirkitree commented
Status: Active » Needs review

Marking as needs review.

xurizaemon’s picture

xurizaemon
he/him
Location Ōtepoti, Aotearoa 🏝
commented
Title: Please support the "search" method » Add search support to module
StatusFileSize
new 584514-twitter-add_twitter_search_to_api.patch4.07 KB

This attached patch adds a twitter_search() function to twitter.inc, which you can pass terms into.
And it adds a twitter_fetch_search() function which stores the results locally too.

Eg,

// just look up some results, don't store locally
$term = 'drupal' ;
$search_results = twitter_search($term);

// look up some results and drop them into the local tweet storage
$term = 'drupalcontrib' ;
twitter_fetch_search($term);

// ideally it should support extended search parameters too, 
// but I'm having trouble getting those to work on Twitter's API
// even by direct reference: 
// http://search.twitter.com/search.json?q=paris&lang=fr
$params = array( 
  'q' => 'drupal', 
// 'lang' => 'fr',
) ;
twitter_fetch_search($params);
xurizaemon’s picture

xurizaemon
he/him
Location Ōtepoti, Aotearoa 🏝
commented

There are >= three separate approaches in this issue now. Thought I should explain why I was adding another rather than building on one of them.

LittleViking's patch in #5 adds a global search variable, and calls twitter_fetch_search() on cron runs using this term. It stores them using twitter_cache_status() which may be from an earlier version of this module (function doesn't exist in twitter-6.x-3.x CVS) or may be custom code at their end.

LyricNZ's code posted above re-implements the facility using drupal_http_request() and SimpleXML parser rather than adding facilities to Twitter module. It's suitable if you want to drop the code into your site without changing how Twitter module works.

DragonWize's code expands on LittleViking's (dragon, viking, are you guys in cahoots?) but I wanted this functionality available through the Twitter libs in this module.

twitter.lib.php already included stub code for TwitterSearch, it just wasn't implemented. None of the above approaches had used that (that I could see).

I feel that the most useful modules are the toolkits which allow us to build solutions on top of, rather than providing a canned solution which may or may not scratch your particular itch. So I've aimed to move this contribution in the toolkit direction, rather than towards a particular end solution.

xurizaemon’s picture

xurizaemon
he/him
Location Ōtepoti, Aotearoa 🏝
commented
StatusFileSize
new 584514-twitter-add_twitter_search_to_api-r3.patch5.29 KB

I left out a bit of code :) Also: More ramblings.

I added TwitterSearchStatus class to handle http://code.google.com/p/twitter-api/issues/detail?id=214 which is mentioned in Twitter's API docs. This class turns TwitterSearch results into TwitterStatus objects.

Because of the code to fetch users in TwitterSearchStatus's __construct() we may use more API requests than required (we do 1 or 2 additional users/show API hits per search result). Could drop that if not required. We do get the user's name, just not their twitter UID.

This code does not handle authenticated searches. (Does Twitter?)

13rac1’s picture

13rac1 commented
Version: 6.x-3.x-dev » 6.x-5.x-dev
Status: Needs review » Needs work

Patch needs updating for 6.x-5.x.

tinkerbelle’s picture

tinkerbelle commented

I would looooove to see this functionality added to this module (or find an alternative), now that Twitter has/is about to remove their RSS & Atom feeds.

juampynr’s picture

juampynr commented
Status: Needs work » Closed (won't fix)

AFAIK Twitter Pull module can do this.

tinkerbelle’s picture

tinkerbelle commented

Yep, thanks, I did end up using Twitter Pull.

For anyone interested, the dev version of that module is currently dealing with Twitter's recent/upcoming api changes by piggybacking on this module's (and thus also the OAuth module's) api -- see #1781024: Make the Twitter Pull module work when Twitter turns off the version 1 API and #1899456: Separate the API, User features and views features into their own respective modules..

lukus’s picture

lukus
he/him
commented

I'd second the request for this functionality to be added to this module.

The need to use twitter_pull on top of this module, takes away some of the original appeal of using twitter_pull in the first place (e.g. it being lightweight / simple to implement).

Almost two and a half years have passed since this issue was last looked at in terms of code. Is it worth raising a new issue?