Make the Twitter Pull module work when Twitter turns off the version 1 API

This is also my concern with the module. An explanation of the development roadmap for the module would be great.

Hi Guys,

I agree this is a major concern. I've been thinking about it and my current considerations are:

1. This module is intended to be super simple and just list tweets based on a search. If we implement OAuth and integration with the twitter API, are we duplicating http://drupal.org/project/twitter ?

2. The counter point here is there are a lot of people who use this module, and we wouldn't want them to have to rebuild their site's twitter implementation. We'd at the very least need to provide a simple way to transition to the twitter module.

Further thoughts and feedback would be appreciated

I wouldn't consider it an overlap seeing as to preserve existing functionality, this is essentially a required update. This can still be a minimal super simple module with the OAuth component rolled in. Right now, it's not even working for me as it is, but that's another matter.

I also decided to use the 'twitter pull' module instead of the 'twitter.module' because this module is a lot lighter weight and does one simple task very well.

This module should have Oauth authentication added to deal with #1209310: Could not retrieve data from Twitter. The error message received was: ..

Still, if you do add Oauth support a bunch of the current users will be befuddled by now having to setup Twitter API accounts.

Also, the Twitter module has already addressed this issue for D7 #1790032: Changes coming in Version 1.1 of the Twitter API and maybe everyone should dealing with this problem in the same module and issue queue.

~jake

Hi there,

I'm wondering whether there is any movement on this? May is coming closer and closer, and I'm wondering what others are doing or whether anyone in the community has started testing out the compatibility with the new API?

Alternatively, are folks looking to switch modules?

It sounds like they're performing blackout tests on March 5th and will release a detailed schedule later? In any case, should all of us understand that this module will not work and that there are no plans on updating it at this time?

I don't know enough about how it works to know the answer to this myself... Does it actually use RSS or Atom feeds to operate (the post you mentioned says that type of functionality will be affected)?

This module will not work (unless Twitter changes their plans, which I hear is a possibility), and I haven't seen any progress toward making this module work.

A few of us here have been tossing around some kind of upgrade path to using the Twitter module (and its Oauth integration) but no firm plans there yet. Will be sure to update this thread if we make any progress in that direction.

I personally feel that the overhead of adding Oauth to this module would cancel out any benefits gained from the simplicity.

I'm starting to look into it myself as well. Will update the thread too, if I manage to come up with something.

In the meantime, we ought to - at a minimum - put a message on the module's main page this issue. That's a must...

I agree and will post that message.

I also agree with mrf that adding Oauth to this module in some ways removes the benefit of the module over Twitter.

My only concern is really existing sites and providing them some path to recreate their twitter functionality without too much work.

Alright - posted front and center.

With this patch, twitter_pull will try to use the twitter module's api for the request. This means the twitter api v1.1 and Oauth.

There is a couple of things you should keep in mind.
1. You will need to have the twitter module installed, enabled and configured for this patch to do anything at all.
2. You will have to have at least one valid twitter user association for it to work.

That is how the twitter module is set up to work right now.

If you want to make sure your site users can use any of the features on the twitter module you will have to do it in the user permissions.

I've gone ahead and switched to the twitter module.

Some steps to making that happen are:

1. Go to https://dev.twitter.com/, login with the twitter username you'll want to pull tweets from and add your website as a new application! This is needed so your website is identified as an application that can communicate with your twitter account once the new authentication requirements are in full effect. Then you'll have the consumer key/secret the twitter module uses to login
   • Choose 'Read Only' for the access if you'll only be pulling tweets (versus posting tweets). I'm assuming we're only in that boat, since we chose the twitter_pull module in the first place.
2. Download and enable the oAuth and Twitter modules
3. Go to Admin --> Configuration --> Web Services --> Twitter --> Settings and paste in the consumer key & secret you got when you added your website as an application to interact with your twitter account above
4. Now go to the 'Twitter' tab of the configuration screen. I had a hard time getting this to work on localhost, since it seems that the 'Website' and 'Callback' URLs on the twitter application side have to match what's listed in the settings tab of this module. Something like 'http://YOURSITE.com/twitter/oauth'. Since I was working on localhost, it would not accept that as a URL, and I had to end up doing this all on my test site that's actually online!!!. Once you've got that part figured out though, click here to add a new user, and just make sure you're logged into the twitter account you want to add



5. Check the 'Tweet' or 'Tweet' and 'Mention' options next to the user, once you add them, depending on what you want to download



6. Now go to the 'Views' section of your website and either modify or clone-then-modify the views that come with this module, until you get them looking similarly to what your twitter_pull blocks looked like.... I had to re-do some of my custom styling, but now it looks identical. Hooray

Thank you Jaesin,

I've committed that patch into a new 7.x-2.x branch.

I've also updated the module to add multiple warnings about not using the Twitter Module api for retrieving tweets.

Finally, I've added markup and styles to conform to the Twitter display requirements.

Hopefully this gives us a path to move forward. I want to leave this issue open as I think that the instructions by ditcheva are very helpful (thank you) and that many people who are using twitter pull should move to using Twitter in the future.

A dev release for 7.x-2.x should show up soon, let me know if there are any issues.

While this approach works there is a down side...this module in and of itself has no dependencies at the moment, the above patch changes this in a major way. Obviously the dependency on the Oauth Module makes total sense but by using the twitter module there is an implicite dependency on views eventhough this module does not make usage of view in any way shape or form. Now you may say every site uses views but this is not in fact the case. I would ask you to reconsider the approach taken and with the following solution

* Make this module dependent on the Oauth module
* Have explicit keys for the user name being used by twitter pull
* Provide integration directly with the Oauth rather than via the twitter module.

If there is the potential for this solution being accepted I am more than happy to help develop said solution.

I agree with marcingy, so I've used the api from the oauth module and I've got it working with twitter_pull. I just need to better integrate the code I've written into the twitter_pull modules twitter_puller class and hopefully I'll have a patch we can test, and also, will need to store the consumer key/secret and the access token/token secret somewhere. I was thinking, a place to set these values could be part of the formatter settings for twitter pull under the manage display options.

Hi marcingy,

If you would like to work on this, I am not opposed, I think it would be in some ways nicer.

It would be great to have the twitter module restructured. I would like to see it expose it's API and drop the views and user account integration for the base module and move those features/requirements to sub-modules. The twitter module, as it is, encourages every twitter related module to take it's own approach and re-implement it's own twitter API which is somewhat less than optimal. The approach I took here is considered to be a quick fix so most folks that are using this module aren't left stranded. If anyone else is interested in a better twitter module api, you can add your ideas to this thread: http://drupal.org/node/1899456 .

So here are my patches which integrates the OAuth modules api into the twitter_pull module.
This patch twitter_pull-oauth-integration-config-form-for-module-1781024-19.patch needs to be patched against twitter_pull.module
This patch twitter_pull-oauth-integration-for-class-inc-1781024-19.patch needs to be patched against twitter_pull.class.inc
A patch I haven't created which will probably be necessary, is for the .info file to make a dependency on the OAuth module.

So to get this working;
* download and install the OAuth module,
* apply the patches,
* log into your twitter account and create a new application to generate the consumer key/secret and the access token/token secret. The patch to the .module file will have created a configuration form which can be found under the menu Configuration->Web services->Twitter pull (admin/config/services/twitter-pull-config). This configuration form is then used to fill in the consumer key/secret and the access token/token secret, which you should have from creating your twitter application.

Then hopefully it should all work. The database table cache_pulled_tweets will probably need emptying if you want to check to see if it's working right away, and you'll probably need to empty the menu cache so the config menu item mentioned above appears.

Apologies to anyone who thinks I've rushed ahead to develop this without consulting anyone, but this has become an urgent matter for the British Film Institute where I work, and we do like this module :-)

The immediate thing that worries me about the above patch is that the admin screen asks for all of the user twitter ouath tokens and secrets, by my understanding with Oauth only consumer token should need to be provided?

Update on further reading of the code in the twitter module I see that basically it does store the info after doing a retrieval so this is simply missing out that initial step. However providing all this information to a user still bothers me.

I hear what you're saying marcingy. Basically, by providing the access token you don't have to do the complete "dance".
But using this module (and I'm probably wrong on this) you're only going to be using you're own twitter account which reflects what is said on the application settings on twitter,

Use the access token string as your "oauth_token" and the access token secret as your "oauth_token_secret" to sign requests with your own Twitter account.

But I know what you mean, by twitter allowing you to have the access token you're neither doing a two-legged or three-legged oauth authentication. If we remove the need for the access token the code will need to complete a two-legged authentication dance to get an access token, I would need to have a look at how to do that with the OAuth modules api.

Actually, I think on line 124 in my patch it should be
$token = new OAuthToken($oauth_token, $oauth_token_secret);
not new OAuthConsumer

I think I need to understand the OAuth modules api better.

Just to update you where I'm at with this. The patches I've attached to this comment have gone live on our production site and all is working well. The patches are more or less the same as those in my comment #19, but use these patches instead. I've added one more patch that should be patched against the .info file to add a dependency to the oauth module.

Sorry to add even more patches to this issue, but I needed this for a Drupal 6 site so here's a patch containing the code that was already committed to Drupal 7 (straight integration with the Twitter module) ported to work with the Drupal 6 version of the module.

From the code mentioned in #14, this includes the fix itself plus the requirements check (to add warnings for sites using the old method). It does not include the markup and style changes mentioned there though.

I've installed Twitter Pull 7.x-2.x-dev, which includes Jaesin's patch above. I've also installed the Oauth and Twitter modules and authorized at least one user, etc. Everything seems to be working but how do I know if it's using Twitter's v1.1 api? I've tried turning off the Twitter Module and deauthorizing the app to see if the tweets stop flowing, but they're still there. Do I have to wait until March 20 to make sure everything works with v1.1?

I'll tried to apply the patches from #24 and they didn't work for me, they have been created from "/sites/all" so you can't not use them in your .make file, and the manually procedure (remove trailing slashes with -p option) did not work either.

The version 2.x-dev of the module seems to work fine but breaks with lists and doesn't display the authors of the tweets. The problems is that an $user variable is treated like an object when is actually an array.

I have created a patch against commit 2afde7c45 to fix this issue.

Some notes about what I've done using Twitter module, Twitter Pull module & OAuth:

I've tried a combination of suggestions here and at the Twitter module. I am able to get a stream of posts of a username and/or hashtags. However, when I first save a block I've created I get a whole slew of errors. A lot of repetitive stuff. I posted it at the end here. Looks like it is having trouble getting user info from Twitter such as user name & profile picture. This causes the links to the person who tweeted the post to be wrong.

I too am not sure which API is being used.
Twitter module ver. 7.x-5.6 was throwing some errors: Invalid Twitter OAuth request
patch on here helped - http://drupal.org/node/1924478#comment-7269744

    Notice: Trying to get property of non-object in twitter_puller->parse_items() (line 199 of /home/sandboxs/public_html/sites/all/modules/twitter_pull/twitter_pull.class.inc).
    Notice: Undefined property: stdClass::$from_user in twitter_puller->parse_items() (line 202 of /home/sandboxs/public_html/sites/all/modules/twitter_pull/twitter_pull.class.inc).
    Notice: Undefined property: stdClass::$from_user in twitter_puller->parse_items() (line 204 of /home/sandboxs/public_html/sites/all/modules/twitter_pull/twitter_pull.class.inc).
    Notice: Undefined property: stdClass::$profile_image_url in twitter_puller->parse_items() (line 207 of /home/sandboxs/public_html/sites/all/modules/twitter_pull/twitter_pull.class.inc).
    Notice: Undefined property: stdClass::$profile_image_url_https in twitter_puller->parse_items() (line 208 of /home/sandboxs/public_html/sites/all/modules/twitter_pull/twitter_pull.class.inc).
    Notice: Trying to get property of non-object in twitter_puller->parse_items() (line 199 of /home/sandboxs/public_html/sites/all/modules/twitter_pull/twitter_pull.class.inc).
    Notice: Undefined property: stdClass::$from_user in twitter_puller->parse_items() (line 202 of /home/sandboxs/public_html/sites/all/modules/twitter_pull/twitter_pull.class.inc).
    Notice: Undefined property: stdClass::$from_user in twitter_puller->parse_items() (line 204 of /home/sandboxs/public_html/sites/all/modules/twitter_pull/twitter_pull.class.inc).
    Notice: Undefined property: stdClass::$profile_image_url in twitter_puller->parse_items() (line 207 of /home/sandboxs/public_html/sites/all/modules/twitter_pull/twitter_pull.class.inc).
    Notice: Undefined property: stdClass::$profile_image_url_https in twitter_puller->parse_items() (line 208 of /home/sandboxs/public_html/sites/all/modules/twitter_pull/twitter_pull.class.inc).
    Notice: Undefined property: stdClass::$from_user in twitter_puller->parse_items() (line 202 of /home/sandboxs/public_html/sites/all/modules/twitter_pull/twitter_pull.class.inc).
    Notice: Undefined property: stdClass::$from_user in twitter_puller->parse_items() (line 204 of /home/sandboxs/public_html/sites/all/modules/twitter_pull/twitter_pull.class.inc).
    Notice: Undefined property: stdClass::$profile_image_url in twitter_puller->parse_items() (line 207 of /home/sandboxs/public_html/sites/all/modules/twitter_pull/twitter_pull.class.inc).
    Notice: Undefined property: stdClass::$profile_image_url_https in twitter_puller->parse_items() (line 208 of /home/sandboxs/public_html/sites/all/modules/twitter_pull/twitter_pull.class.inc).
    Notice: Trying to get property of non-object in twitter_puller->parse_items() (line 199 of /home/sandboxs/public_html/sites/all/modules/twitter_pull/twitter_pull.class.inc).
    Notice: Undefined property: stdClass::$from_user in twitter_puller->parse_items() (line 202 of /home/sandboxs/public_html/sites/all/modules/twitter_pull/twitter_pull.class.inc).
    Notice: Undefined property: stdClass::$from_user in twitter_puller->parse_items() (line 204 of /home/sandboxs/public_html/sites/all/modules/twitter_pull/twitter_pull.class.inc).
    Notice: Undefined property: stdClass::$profile_image_url in twitter_puller->parse_items() (line 207 of /home/sandboxs/public_html/sites/all/modules/twitter_pull/twitter_pull.class.inc).
    Notice: Undefined property: stdClass::$profile_image_url_https in twitter_puller->parse_items() (line 208 of /home/sandboxs/public_html/sites/all/modules/twitter_pull/twitter_pull.class.inc).
    Notice: Undefined property: stdClass::$from_user in twitter_puller->parse_items() (line 202 of /home/sandboxs/public_html/sites/all/modules/twitter_pull/twitter_pull.class.inc).
    Notice: Undefined property: stdClass::$from_user in twitter_puller->parse_items() (line 204 of /home/sandboxs/public_html/sites/all/modules/twitter_pull/twitter_pull.class.inc).
    Notice: Undefined property: stdClass::$profile_image_url in twitter_puller->parse_items() (line 207 of /home/sandboxs/public_html/sites/all/modules/twitter_pull/twitter_pull.class.inc).
    Notice: Undefined property: stdClass::$profile_image_url_https in twitter_puller->parse_items() (line 208 of /home/sandboxs/public_html/sites/all/modules/twitter_pull/twitter_pull.class.inc).
    Notice: Undefined property: stdClass::$from_user in twitter_puller->parse_items() (line 202 of /home/sandboxs/public_html/sites/all/modules/twitter_pull/twitter_pull.class.inc).
    Notice: Undefined property: stdClass::$from_user in twitter_puller->parse_items() (line 204 of /home/sandboxs/public_html/sites/all/modules/twitter_pull/twitter_pull.class.inc).
    Notice: Undefined property: stdClass::$profile_image_url in twitter_puller->parse_items() (line 207 of /home/sandboxs/public_html/sites/all/modules/twitter_pull/twitter_pull.class.inc).
    Notice: Undefined property: stdClass::$profile_image_url_https in twitter_puller->parse_items() (line 208 of /home/sandboxs/public_html/sites/all/modules/twitter_pull/twitter_pull.class.inc).
    Notice: Trying to get property of non-object in twitter_puller->parse_items() (line 199 of /home/sandboxs/public_html/sites/all/modules/twitter_pull/twitter_pull.class.inc).
    Notice: Undefined property: stdClass::$from_user in twitter_puller->parse_items() (line 202 of /home/sandboxs/public_html/sites/all/modules/twitter_pull/twitter_pull.class.inc).
    Notice: Undefined property: stdClass::$from_user in twitter_puller->parse_items() (line 204 of /home/sandboxs/public_html/sites/all/modules/twitter_pull/twitter_pull.class.inc).
    Notice: Undefined property: stdClass::$profile_image_url in twitter_puller->parse_items() (line 207 of /home/sandboxs/public_html/sites/all/modules/twitter_pull/twitter_pull.class.inc).
    Notice: Undefined property: stdClass::$profile_image_url_https in twitter_puller->parse_items() (line 208 of /home/sandboxs/public_html/sites/all/modules/twitter_pull/twitter_pull.class.inc).
    Notice: Undefined property: stdClass::$from_user in twitter_puller->parse_items() (line 202 of /home/sandboxs/public_html/sites/all/modules/twitter_pull/twitter_pull.class.inc).
    Notice: Undefined property: stdClass::$from_user in twitter_puller->parse_items() (line 204 of /home/sandboxs/public_html/sites/all/modules/twitter_pull/twitter_pull.class.inc).
    Notice: Undefined property: stdClass::$profile_image_url in twitter_puller->parse_items() (line 207 of /home/sandboxs/public_html/sites/all/modules/twitter_pull/twitter_pull.class.inc).
    Notice: Undefined property: stdClass::$profile_image_url_https in twitter_puller->parse_items() (line 208 of /home/sandboxs/public_html/sites/all/modules/twitter_pull/twitter_pull.class.inc).
    Notice: Undefined property: stdClass::$from_user in twitter_puller->parse_items() (line 202 of /home/sandboxs/public_html/sites/all/modules/twitter_pull/twitter_pull.class.inc).
    Notice: Undefined property: stdClass::$from_user in twitter_puller->parse_items() (line 204 of /home/sandboxs/public_html/sites/all/modules/twitter_pull/twitter_pull.class.inc).
    Notice: Undefined property: stdClass::$profile_image_url in twitter_puller->parse_items() (line 207 of /home/sandboxs/public_html/sites/all/modules/twitter_pull/twitter_pull.class.inc).
    Notice: Undefined property: stdClass::$profile_image_url_https in twitter_puller->parse_items() (line 208 of /home/sandboxs/public_html/sites/all/modules/twitter_pull/twitter_pull.class.inc).
    Notice: Undefined property: stdClass::$from_user in twitter_puller->parse_items() (line 202 of /home/sandboxs/public_html/sites/all/modules/twitter_pull/twitter_pull.class.inc).
    Notice: Undefined property: stdClass::$from_user in twitter_puller->parse_items() (line 204 of /home/sandboxs/public_html/sites/all/modules/twitter_pull/twitter_pull.class.inc).
    Notice: Undefined property: stdClass::$profile_image_url in twitter_puller->parse_items() (line 207 of /home/sandboxs/public_html/sites/all/modules/twitter_pull/twitter_pull.class.inc).
    Notice: Undefined property: stdClass::$profile_image_url_https in twitter_puller->parse_items() (line 208 of /home/sandboxs/public_html/sites/all/modules/twitter_pull/twitter_pull.class.inc).

Confirming that patch mentioned in comment #28 is necessary to make all this procedure works.

altrugon, I'll get that path sorted out for you, thanks for spotting

I've rolled all my patches into one against version 7.x-1.x-dev, but it seems that version 7.x-1.x-dev has changed since the version I used. It looks like lazy load was later added to the .module file. Anyway, I've attached my patch using --relative so the paths should be ok now. I think the class and info patches are fine with the current 7.x-1.x-dev version, so I'll probably need to apply my changes again to the latest .module file from version 7.x-1.x-dev to keep lazy load intact.

But besides that, what's the decision on all of this? Do we just want a dependency on the oauth module and don't have to worry about setting up a drupal user (just have to get the consumer and access keys from an valid twitter account), which is this solution, or, do we want the other solution to install the twitter and oauth module and the need to create a drupal user to generate the access token from the consumer key of a valid twitter account?

@nkleekamp:

I've installed Twitter Pull 7.x-2.x-dev, which includes Jaesin's patch above. I've also installed the Oauth and Twitter modules and authorized at least one user, etc. Everything seems to be working but how do I know if it's using Twitter's v1.1 api?

I'm pretty sure you can check your site's status report page. The latest 7.x-2.x-dev code should result in a "Twitter Pull Authentication" section on that page that will give you either a "warning" or "OK" message depending on which method it's using to connect. There also should be messages in the logs if it's using the wrong one.

At least, that's how it's supposed to work (I haven't tried the Drupal 7.x-2.x branch myself, only the Drupal 6 version which I backported above based on the code that was in 7.x-2.x)....

Thanks @David_Rothstein. After checking the my site's status, it did indeed report that it's using the Twitter module authentication.

During the blackout test tonight (4/16), tweets did appear, but only after clearing the cache tables. Did anyone else experience this? Does anyone have an idea as to how to fix that or what might be the cause?

Nevermind... the below issue went away. Perhaps it needed a few more clears of cache or cron runs...

My twitter pull blocks aren't populating.

Our tpl.php file for the view (block) field (text field we have on content type) pretty much just contains:

<?php
if (function_exists('twitter_pull_render')) {
print twitter_pull_render($output, $output 3)
}

Patch from #31 does not apply to 7.x-2.x

Since the May 7 date for the old Twitter API to die is fast approaching, I thought I should mention that I've developed an alternative to the Twitter Pull module which is working now:

http://drupal.org/project/twitter_search

The Twitter Search module requires the Twitter module and uses its Twitter API library and OAuth module integration to retrieve and store Twitter search results. It adds some additional Views integration to the integration already available from the Twitter module, making it possible to create blocks and other listings of Twitter statuses based on search terms in addition to the user accounts-based listings available from the Twitter module itself.

The Twitter Search module was originally created by another developer who stopped maintaining it awhile ago, but he recently made me a maintainer, and I've upgraded so that there are now working versions for both Drupal 6 and Drupal 7 which work with the latest avaialble versions of the Twitter module.

This may be a somewhat different approach than the current approach under development for the Twitter Pull module, but it is working now, and I think the Views integration provides for a lot of flexibility.

The dev version seems to be working, except it isn't adding in link / info for the twitter account, such as the twitter-author.
I have to make a decision in about 10 min as to whether or not to go live with this module tomorrow... is that a bug that's being worked on?

Are you using this module in conjunction with the twitter module or no?

Hi. My manager objected to the idea of adding the twitter and oauth modules to our site just to make twitter_pull work. Instead we took a different approach.

https://github.com/J7mbo/twitter-api-php is a lightweight wrapper for making calls to the new api. I copied it into /libraries. Attached is a patch to use that library. It updates get_items to use URLs that use 1.1 and then it queries those urls with the forementioned library. I also included an admin form for oauth keys and instructions on how to register an app.

Also I should mention that this applies to 1.0-rc4, since that's what we're using in prod. Also planning on a D6 version, but that might not come till we've QAed this patch.

Here's #40 but for 6.x-1.2. I removed libraries and hardcoded the path, since our d6 installs didn't use libraries. I'd love to have done something a little more flexible, but with less than a week till 1.1, I'm okay with hardcoding a path or two.

http://drupal.org/node/1983570

My issue regarding username not appearing was fixed with the patch that was posted on this issue. I'm going to close that one :)

@jsagotsky - Thanks for your great work here.

Re-roll
I've re-rolled the patch at #40 against 7.x-1.x-dev, with a couple changes/enhancements:

Changes
I put the URL of the config page to: admin/config/services/twitter_pull, that way you can see the twitter_pull configuration link on the admin/config page (under 'Web Services', which is also where the config for the regular twitter module is).

Drush integration
Also, I put in a little drush integration to download the api - the command is drush twitter-pull-download. This command clones the master branch from the repo, puts it in sites/all/libraries/twitter-pull-api (or anywhere with an optional argument), and then removes the .git cruft. I know I have more than a couple sites to update and I'm thinking this integration would be handy.

Testing
I tested the changes with this new API integration (lightly) and everything is working great for me! I think this is an excellent direction for the module now that the twitter API is changing and I fully agree about twitter and oauth being just too much - it would really kill the spirit of this module IMHO.

The clock is ticking!! I hope we can get some more testers for this patch and get a commit/release real soon so there is a supported upgrade path before the time runs out.

I just noticed that Twitter is extending the v1 API retirement date to June 11, 2013. Always nice to get an extension.

API v1 Retirement Date Extended to June 11, 2013
https://dev.twitter.com/blog/api-v1-retirement-date-extended-to-june-11

@justindodge: i think you forgot to include a copy of twitter_pull.admin.inc plus your drush file in that last patch.
also, you should either list libraries as a dependency or check that it's available before calling libraries_get_path().

all that aside, this works for me. thanks!

@mvc: Thanks, you're absolutely right about that.

I didn't actually write in the call to the libraries function myself, but I did take the liberty of rewriting it so that libraries is not a dependency - the code will attempt to use libraries module if it's available, otherwise it will go with what I think is a sensible default (sites/all/libraries).

I also added this logic into the Drush bit.

Here's another patch.

two small suggestions:

twitter_pull.admin.inc needs to call module_exists() too (better, write one function both can share)

many people won't have git installed, so instead of calling drush_shell_exec() try downloading https://github.com/J7mbo/twitter-api-php/archive/master.zip

@mvc: Thanks for your suggestions- I'm sure you're right about the additional module_exists call being needed, I hadn't reviewed all of the other code that was there. I'll see if I can't take another look when I get a chance.

As far as the git thing is concerned, I agree with you that some may not have it installed - but I'd like to mention that I'm following the footsteps of the devel module and ckeditor module on this one (both of which actually utilize svn export, although I think git being the VCS of choice for Drupal, it may be becoming more common to have around than svn). Also, this being a fairly developer-oriented module it seemed like an acceptable choice. If memory serves me I think that master.zip may have unpacked in a structure that was slightly unexpected. Lastly, I'm not aware of a cross-platform utility that can download the file that's more common than git - I'm in the habit of using wget myself, but it's not often present on a Windows machine. Of course, PHP could do it natively but doesn't normally have permission to write to this part of the filesystem.

At any rate, I'm open to better suggestions on this but otherwise feel like git is adequate for a bonus feature like this.

@justindodge: I was thinking of drush's built-in features for downloading and extracting files, such as those used when running drush dl, but as you say this is just a bonus convenience feature so not a big deal. If that's what devel & ckeditor do, I'm sure it's fine.

Very thankful for this patch, works great. This is just a little change so that the list statuses still work.

Can someone clarify: are there plans for a new release of Twitter Pull that will support the new API before 11th June? Or do I need to migrate all of my sites using Twitter Pull over to the Twitter module before 11th June? Thanks.

@Rob230, my patches in #40 and #41 (and any versions of them that were rerolled since then) will make twitter_pull work without any need for migrating. They both use a library linked in #40.

Like #51, I am feeling a little confused by the lack of decisive action on this issue -- I don't mean to whine, I'm just getting scared about (yet another) deadline looming!

Right now, I'm leaning towards going live with Twitter Pull with the Twitter/OAuth integration as committed to 7.x-2.x-dev, since that seems the most "official" (although, slightly unrelatedly, I really wish it were possible to cache tweets indefinitely for slower streams, see #716958: Old tweets disappear).

@jsagotsky, is your more lightweight solution something you'd see replacing the Twitter/OAuth option entirely -- ie. should I be concerned that the latter might never make it to stable release if yours were chosen instead, or might the two options live alongside?

I think there needs to be a decision made on the best path to take for this module - the Twitter APIv1 June 11th retirement date is less than two weeks away.

After going through the issue history, I see 3 options that have been suggested for making Twitter Pull work with API v1.1:

1. @Jaesin's patch from #12 which uses the Twitter and OAuth modules to authenticate that was committed to the 7.x-2.x-dev branch.
2. @marcingy/@thetoast's patch from #31 which only uses the OAuth module to authenticate.
3. @jsagotsky/@justindodge/@lazysoundsystem's patch from #50 which uses an external library to authenticate.

Personally I think option 2 is the best approach. It uses only the tried-and-tested OAuth Drupal module rather than an external library and does not require the comparatively bloated Twitter module (which requires the OAuth module anyway). The module maintainer has already committed option 1 to a new dev branch, but also expressed an openness to the second option (see comment #17) so I'd like to see that option explored as well.

If the twitter module was broken up a bit more so that different components can be used when desired then it may make sense that this module depends on (or gets merged into) the twitter module. However that's probably a completely different topic.

There are many reason to use the twitter pull module over the twitter module. For many of my sites it is the simplicity, size and performance of the twitter pull module vs the twitter module. Twitter pull also offers features that twitter doesn't. Making a dependency on the twitter module feels like the wrong approach to take especially when the sole reason is to gain access to the OAuth module.

The OAuth module is the current best practice for Drupal modules to utilize OAuth. I would highly recommend that twitter pull integrate with the OAuth module directly.

I really don't think any of the patches or approaches should be seen as a long term solution worth maintaining (and I don't see anyone particularly excited about maintaining them). Think of these patches as bandaids to not force you to completely abandon this module and start over with your twitter integration on your current site.

The entire reason for this module is "give me a list of tweets for a provided search term". This used to be really easy, and Twitter decided to make it really difficult.

Couldn't this functionality just be a patch to Twitter module? Juampy has been doing a ton of work on that module. It seems like a lot of wasted effort to have a separate module that implements such a tiny piece of the Twitter API and now has to maintain its own Oauth integration in order to do it.

Couldn't this functionality just be a patch to Twitter module? Juampy has been doing a ton of work on that module. It seems like a lot of wasted effort to have a separate module that implements such a tiny piece of the Twitter API and now has to maintain its own Oauth integration in order to do it.

The twitter module could implement this functionality. Another user has mentioned they created the twitter_search module to do this but still rely on the twitter module.

The twitter module is bulky and does a lot of stuff. For anyone wanting to provide lists of tweets based on different search criteria this is the best module for that. It's lightweight, at least compared to the twitter module. It sucks that twitter is now requiring authentication but just because twitter did that doesn't mean we should abandon this module for a heftier module.

I think the point is that there is no intention to continue support for Twitter Pull, and the effort would be better placed into making the Twitter module NOT be bloated and bulky. I agree with mrf, that Juampy is putting some significant effort into making the Twitter module be something we can actually use again.

I think the point is that there is no intention to continue support for Twitter Pull...

Is this the case? I haven't seen any mention that twitter pull is on the ropes.

and the effort would be better placed into making the Twitter module NOT be bloated and bulky. I agree with mrf, that Juampy is putting some significant effort into making the Twitter module be something we can actually use again.

I think it's great that effort is being put into the twitter module. I'm still not convinced that would negate the effectiveness of a module like twitter_pull. And unless the twitter module is going to be revamped quickly, we need a solid approach with the twitter_pull module until such time as the twitter module is a good replacement.

I've used patch #40 on one of my sites (it was using 7.x-1.0-rc4 and had the Libraries module, and it seemed like the most lightweight option without installing other modules). It worked perfectly without any messing around, so thanks jsagotsky. At least it'll be covered when 11th June arrives.

In terms of a long term plan, I think the Twitter module is far too bloated and does too much. It seems more oriented around allowing users to tweet from Drupal. It also doesn't seem to support application-only authentication. Twitter pull's original goal of being a lightweight module that only fetches tweets is still possible and desirable. Using the OAuth module is probably the way to go.

Like Mr.F said,

When I created twitter module integration for this module, it was intended to be a temporary fix. At the same time, I created an issue on the twitter module asking them to put their api into a sub-module. This would mean that the twitter_api module would be super lightweight and depend on the oauth module.

We could assist with breaking the api out into it's own module. This would mean that the twitter_pull module would be a super simple module that uses the twitter_api module (also super simple and lightweight). So there wouldn't be any bulky modules enabled.

So let's work together! Let's create a patch for the twitter module that pulls the api out. We will also need to add a settings page to add a fallback twitter account to use for authentication. The twitter module does not currently have this and it would eliminate the twitter modules requirement to have at least one twitter user associated with their twitter account.

@Jaesin... I think long term that's a great approach. I'm just not sure it's feasible prior to the twitter API changes.

What I would propose is this...

1) Get twitter_pull integrated with OAuth using the patch in #31.
2) Refactor the twitter module.
3) Then have twitter_pull 7.x-2.x work through the twitter module.

With all due respect to @Jaesin, I don't think it's realistic to expect that the twitter API will get broken out into a sub-module of the Twitter module anytime soon, and certainly not in time to keep the Twitter Pull module from breaking. The maintainer of the Twitter module is juampy, and he has not responded to that proposal from Jaesin since Jaesin first submitted it in January. If he hasn't responded in five months, why would you expect that he will respond and implement that change (which is non-trivial) in the time remaining before Twitter pulls the plug and the Twitter Pull module stops working altogether?

Breaking out the Twitter API into a separate module sounds like a pretty good idea to me, but I know that Juampy has his own plans for refactoring the Twitter module, which are reflected in the Twitter 7.x-6.x branch that he currently has under development. He has done a lot of work to keep the Twitter module functioning, but my impression is that he does not have enough time to maintain the module and move forward with his own refactoring plans, let alone to incorporate new proposals that are presently just just words without any actual code patches that he can apply to implement them.

It is also not clear from the discussion in this thread how the Twitter module should be refactored. For example, Jaesin has also suggested that the Twitter module should "drop the views and user account integration for the base module" and put that functionality into sub-modules also. Again, that might be a good idea in theory, but it's probably a lot of work to implement and may not be consistent with Juampy's roadmap for for future development. I also find personally that the views integration makes the Twitter module quite a bit more flexible and powerful than it would be otherwise. It enables people to create new Twitter blocks for their web pages with little or no custom coding.

I'm coming to this discussion as someone who needed to create some customized Twitter blocks on a couple of websites I was building and was frustrated that there were no working modules which I could count on to do that. I considered using the Twitter Pull module, but decided against it due to the problems coming up with Twitter's API changes and OAuth, combined with the fact that this thread has been talking about fixing that problem since September of last year but still hasn't reached a consensus on how to actually fix it. I therefore took the alternative approach of of reviving the old Twitter Search module, which was written for Drupal 6 but then abandoned by its original creator. I got him to let me take over maintainership, updated it to Drupal 7, and fixed it so it works with the current release of the Twitter module, upon which it depends:

https://drupal.org/project/twitter_search

The Twitter Search module is pretty small and lightweight. It uses the Twitter module and its Twitter API to handle authentication, and it enables some searches and views that are not available directly from the Twitter module itself. I think it provides all of the functionality that you can get from the Twitter Pull module. You can search on hashtags, Twitter usernames or any other search term. Here are some sample pages on a website I built where each page displays a different Twitter search result feed based on whatever search term users entered in a text field when they created their pages:

* http://www.hackforchange.org/gangplank-hack-change-day-2
* http://www.hackforchange.org/ct-civic-hack-day
* http://www.hackforchange.org/hack-la

The Twitter Search module currently requires that you apply a patch to the Twitter module, which I've noted on the project page. Juampy hasn't yet applied that patch to the main Drupal 7 branch of his module, but he has applied it to his 7.x-6.x branch, so I expect that it will eventually make its way into the 7.x-5.x branch as well. In the meantime, if there is someone who needs help getting it working who has trouble following the patch instructions, I can provide a bit of explanation.

If you don't want to use the Twitter Search module, the Twitter Pull module either needs to do its own authentication against the Twitter API (e.g., follow comment #40 in this thread), or it should add a dependency to the Twitter module in its present form to get that authentication working. There's no point in using this thread to discuss ways that you wish the Twitter module would get refactored so it better supports the Twitter Pull module. That just isn't going to happen within the time frame needed.

@caschbre get's it.

To further clarify things.

What I'm talking about is creating a patch (DIY style) to the twitter module that rips the api out into it's own sub-module. In that case, we can update v2 of this module so that is compatible with the patch or unpatched version of the twitter module.

If luck prevails, the maintainers of the twitter module will see the wisdom and commit the proposed patch. Lightweight and patch free twitter_pull sweet success. WhoHoo!

It is a correct assumption that this is supposed to be more of a long term solution. The short term solutions are already in place as far as I know you have a couple of options for making twitter_pull oauth compatible.

1. Use v2 of this module
2. Use patch #40

For what it's worth (this is sort of a disclaimer as well), I don't use the twitter pull module myself but it needed fixing. That's the only reason we got involved.

@Jaesin wrote:

What I'm talking about is creating a patch (DIY style) to the twitter module that rips the api out into it's own sub-module. ... t is a correct assumption that this is supposed to be more of a long term solution.

OK, but that discussion doesn't belong in this issue thread. It would be more productive to create an issue in the Twitter module's issue queue (or use the issue that Jaesin has already created there), and submit a patch so that juampy can review it and decide whether he wants to accept it. Theorizing here about the best architecture for the Twitter module doesn't help resolve the issue that this thread is intended to address. If you want to propose changes to the Twitter module, the best place to do that is in the issue queue for the Twitter module, not the issue queue for the Twitter Pull module.

Sheldon raises an interesting point by bringing up what discussion belongs in this thread.

The original patch on this issue has already been committed to a new branch. Since that commit we have a patch in #27 that should have been applied against that branch but got lost in that shuffle, a 6.x version of that code that should go in its own branch to support 6.x users along with 2 other alternative approaches that have no relationship to the original patch.

I think it would be useful to close this issue to avoid further bikeshedding, hand-wringing, architecture discussions and experimentation. I'm sure if we leave it open long enough someone will get creative and come up with a fourth way to integrate with OAuth.

We should shift the focus to either cleaning up the current 2.x branch in separate individual issues, or discuss replacing the approach used there in separate feature requests against 2.x.

At the point that 2.x is deemed reasonably stable there should be a release published, and 1.x should be marked as unsupported on 6/11 to warn anyone who has this installed and hasn't kept up with this issue or Twitter's announcements that they need to upgrade.

A lot of these items require maintainer intervention, so it would be useful to have a maintainer step in and give some insight into where they see this module going.

Hey Guys,

I'm here and have been following along.

I'm happy to commit any fixes to the 2.x branch that make things work better. I'll work on going through the issues and closing those out. I'll start out by committing patch in #27.

For the future of the module: I think if there is good way of keeping this module simple then that would be a good thing to commit into 7.x-1.x that would be good, I think the approach in #40 and #41 is interesting - while I agree that generally using the OAuth module is the Drupally way to go, there is definitely something to be said for simplicity. I'm not sure what the right way to go is however, and will be fine with whatever the consensus is (if there ever is one).

Jaesin, if you can get the twitter module to be broken apart into pieces so its not quite as monolithic, that would obviously provide the very best option in my opinion.

Mrf, I really appreciate you taking the lead on this.

Patch from 27 was committed here: http://drupalcode.org/project/twitter_pull.git/commit/cee90f6

Hi,

I've ported the patch from #12 to 6.x-1.4 version of Twitter Pull. This is the solution that uses Twitter module for the authentication. I find the original patch in #12 nicely written and it works well for my other D7 site. It requires the installation of Twitter module which in turn requires Oauth, and Autoload.

I wanted to try #31's approach to use Oauth module without needing Twitter module. But the patch was made against the 7.x-1.x dev branch, which has since changed much and it is tedious to re-roll the patch. The code changes for that proposal were also much more complex, so harder to re-roll. So I decided to use the #12 solution which I had used earlier on a D7 site (when #31 was not available yet).

Thanks to Jaesin, and everyone else working on this.

Victoria

Hi,

I have copied the commits to the 7.x-2.x branch from the #31 approach and combined them into a single patch for 7.x-1.x versions. This is because I don't want to use the 7.x-2.x branch, and would much rather use a tag (7.x-1.0-rc5), but you have only committed the fix to the 2.x branch.

This is based on the following 3 commits:
http://drupalcode.org/project/twitter_pull.git/commit/f3be5d3fce438c970f...
http://drupalcode.org/project/twitter_pull.git/commit/f53b42102e34986f46...
http://drupalcode.org/project/twitter_pull.git/commit/2afde7c45a1a677d18...

There is no need to commit this, but this patch is just a temporary solution for people using the 7.x-1.0-rc5 tag.

Thanks very much,
Victoria

Looks like the API v1 is officially retired.

https://dev.twitter.com/blog/api-v1-is-retired

Hi all

This is not working for me after v1 of the API was retired - but I'm getting some very odd behaviour. On my local machine, the plugin still works ( :S ), on my live site, I get no Twitter feed at all, and on my staging site, the feed is there, but the last tweet was 3 weeks ago.

I've tried updating to the latest stable release and the latest dev version - I get a blank space where the feed should be and no errors. Can anybody offer assistance? Thanks

Hi Webbymatt,

This fix is not on the latest stable release. It is only on the dev version, or if you need to use the stable release, you can apply the patch I have added in comment #70 (for D7). It is also not in the D6 version at all, if that's what you are using. If so, use patch on #69 comment.

Also you'll need to add and enable the latest Twitter module, and Oauth module (required by Twitter).

After that, make sure Twitter module is correctly configured. You'll need to add the keys on Twitter (/admin/settings/twitter/settings), and after that, *also* need to authenticate at least one account on /admin/settings/twitter.

If this still doesn't work, you can look at your recent log entries (/admin/reports/dblog) and filter it by type = Twitter Pull, and you'll get more info about why you are failing to see the tweets.

Victoria

Sorry I forgot to mention you'll also need the Twitter and Oauth modules. I've edited my comment in #73 to add that now.

We've updated all our sites to use the patch in #50. Works perfect and doesn't need any other modules and/or add features you don't (want to) use..

In addition to the patch (#50) MrHaroldA mentions, we've applied a small fix to solve a bug where spaces in a search query get replaced by +, breaking the search query. For instance if you query Twitter for "#drupal OR @drupal".

A dependency to the libraries module is in the patch too.

For this patch to work, download the twitter-api-php library: https://github.com/J7mbo/twitter-api-php

Tested on: 7.x-1.0-rc5

This thread needs more discipline. The main problem is fixed and committed to -dev. Follow-up tasks, bug reports, feature requests, and support requests should be separated into new issues.

@victoriachan many thanks for your detailed response, I'll look into this and report back if there any issues.

Thanks again

Summarizing, correct me if I'm wrong:

If you DON'T want to use the oauth + twitter module solution you can download:
https://github.com/J7mbo/twitter-api-php
and put it in ../libraries/twitter-api-php/TwitterAPIExchange.php.

Then:

For D6:
use latest stable (6.x-1.4) and the patch at #41 (tested, works)

For D7:
use latest stable (7.x-1.0-rc5) and the patch at #76 (tested, works)

If you DO want to use the twitter+oauth module approach, you can just use the latest current dev (right?).

If you DO want to use the twitter+oauth module approach, you can just use the latest current dev (right?)

Yes. And you will need to have the Twitter and OAuth modules installed and configured as described in #73, even though Twitter Pull doesn't list them as dependencies yet.

That looks like a good summary (maybe it should be in the issue summary?) but it's missing one case:

You're running Drupal 6 and DO want to use the twitter+oauth module approach.

In that case I wrote a patch in #25, and @victoriachan also wrote one in #69.

The two patches look relatively similar except in the parsing code - mine looks closer to the D7 code from #12 at first glance, but I don't remember enough about this issue to understand the differences, unfortunately (it was a while ago that I worked on it). I can tell you that #25 is running live on one D6 production site and so far it seems to work with no complaints, though :)

I have applied patch #41 #1781024-41: Make the Twitter Pull module work when Twitter turns off the version 1 API and this works for my purpose. Only found out that when using operators for search, the urlencode on line 66 in twitter_pull.class.inc isn't good enough. Change it to rawurlencode and you're happy to go!

@askibinski: thanks for the summary. i've changed the issue description based on that and other comments here.

Hi,

I think I need a little more explicit guidance, as I carefully tried following the directions to apply the patch, and it didn't work.

I'm using D7, without OAuth. I did the following steps:

1. Updated Twitter Pull to 7.x-1.0-rc5 (didn't realize the cause of the issue, but at least am using last stable version);
2. After reading this thread, downloaded https://github.com/J7mbo/twitter-api-php;
3. uploaded and installed it into public_html/sites/all/libraries/, so that I have public_html/sites/all/libraries/twitter-api-php;
4. inside public_html/sites/all/libraries/twitter-api-php, there was: index.php, README.md, TwitterAPIExchange.php;
5. THEN, I downloaded the patch, which is two files: interdiff.txt and twitter_pull_twitter_api_php-1781024-76.patch;
6. Installed them into ../libraries/ above, with the names just given above; this didn't work;
7. so, I renamed "twitter_pull_twitter_api_php-1781024-76.patch" to "twitter_pull.admin.inc", based on what I read at the top of the file;
8. so now inside public_html/sites/all/libraries/twitter-api-php, there was: index.php, README.md, TwitterAPIExchange.php, interdiff.txt, and twitter_pull.admin.inc; this doesn't work either.

So, I'm guessing I misunderstood the instructions. I've cleared the caches after installing this fix, but it didn't make any difference. Does anyone have suggestions?

Thank you in advance.

@tbc_keyworth, see https://drupal.org/patch for information about patches and how to apply them.

In this case, you don't want the "interdiff.txt" file (it's not a patch, just a helper file for humans to see what changed from the previous version of the patch). Just the twitter_pull_twitter_api_php-1781024-76.patch one.

I just spent about an hour reading through this complex issue trying to understand it. I determined that I wanted to use the first method as outlined in #79 above. I downloaded (7.x-1.0-rc5 and applied the patch from # 73. However I am getting errors so as a result the patch does not apply cleanly.

I tried:

git apply twitter_pull_twitter_api_php-1781024-76.patch

but get these errors:

twitter_pull/twitter_pull_twitter_api_php-1781024-76.patch:11: trailing whitespace. * 
twitter_pull/twitter_pull_twitter_api_php-1781024-76.patch:16: trailing whitespace. 
twitter_pull/twitter_pull_twitter_api_php-1781024-76.patch:22: trailing whitespace.
twitter_pull/twitter_pull_twitter_api_php-1781024-76.patch:28: trailing whitespace. 
twitter_pull/twitter_pull_twitter_api_php-1781024-76.patch:40: trailing whitespace.
        '#title' => t('Consumer Key'),     
warning: squelched 9 whitespace errors
warning: 14 lines add whitespace errors.

I then did:

git apply --ignore-space-change --ignore-whitespace twitter_pull_twitter_api_php-1781024-76.patch

... but also get the same errors. As a result the two new files also do not get created. I also tried falling back on:

patch -p0 < twitter_pull_twitter_api_php-1781024-76.patch

...but that does not work either. I am wondering if anyone can tell me what I am doing wrong. Thanks.

Patches should apply to the latest -dev, conventionally. If they don't then they need to be rerolled.

@pjcdawkins - I just tried the patch from #73 with the latest dev and am getting dozens of whitespace errors. I wouldn't know where to begin to try to sort that out.

If you're on D6 and looking for the fastest way to get up and running:

1. Download the attached pre-patched module (6.x-1.4 with the patch from #41).
1B. Alternatively, use git to checkout the 6.x-1.x branch and apply the attached patch. The patch attached was against commit 0aceff88.
2. Download or clone https://github.com/J7mbo/twitter-api-php into your sites/all/libraries folder
3. Clear your caches and visit admin/settings/twitter_pull to setup your oAuth keys. There's instructions on that page.
4. You can test whether the module is configured correctly by visting /twitter/pull/test

Well good news, I found a Sandbox which is pretty much a prepatched version of the method I want to use and it worked flawlessly. In other words, I don't want to use the oauth + twitter module. The Sandbox is here:

https://drupal.org/sandbox/justindodge/2016387

Thanks to @ justindodge!

#89 - @aidanlis, thanks, I needed this for D6 also and your pre-patched version worked great. I really appreciate it!

Thank you, and the subsequent posters, for helping me understand better how patches work. Unfortunately, Twitter Pull still isn't working, and I'm now getting an error message on the dev site I'm experimenting on. The message says "Twitter has not been configured. Contact your site admin."

The steps I followed are:

1. Re-uploaded a fresh copy of https://github.com/J7mbo/twitter-api-php to public_html/sites/all/libraries/;
2. downloaded Twitter Pull 7.x-1.0-rc5 and unzipped it;
3. downloaded the patch, twitter_pull_twitter_api_php-1781024-76.patch;
4. opened the patch file, and applied the changes inside to Twitter Pull 7.x-1.0-rc5, including
   • created twitter_pull.admin.inc;
   • changed twitter_pull.class.inc;
   • created twitter_pull.drush.inc;
   • changed twitter_pull.info; and
   • changed twitter_pull.module.
5. Following the instructions at the top of the patch file, logged into the Twitter portal for Developers at https://dev.twitter.com/apps/new, and specified the creation of an application;
6. copied the resulting keys and tokens into twitter_pull.admin.inc;
7. uploaded the patched Twitter Pull 7.x-1.0-rc5 and ran update on it.

Any suggestions for why I'm getting the public "Twitter has not been configured." error message?

Again, I'm using D7, and my original intention was not to use OAuth.

You shouldn't enter the keys in the code. You should go to /admin/config/services/twitter_pull and enter them in the appropriate fields.

> I have copied the commits to the 7.x-2.x branch from the #31 approach and combined them into a single patch for 7.x-1.x versions. This is because I don't want to use the 7.x-2.x branch, and would much rather use a tag (7.x-1.0-rc5), but you have only committed the fix to the 2.x branch.

For the fix to actually be useful to people, it needs to get into a release.

Could we either have this committed to the 1.x branch and a new RC release, or have a release of some sort from the 2.x branch?

At this current time, there is no tagged release package that actually works.

adding issue summary

@Jaesin's patch from #12 which uses the Twitter and OAuth modules to authenticate that was committed to the 7.x-2.x-dev branch.
@marcingy/@thetoast's patch from #31 which only uses the OAuth module to authenticate.
@jsagotsky/@justindodge/@lazysoundsystem's patch from #50 which uses an external library to authenticate.

The 7.x branch has already had code committed to follow option 1.

Therefore, in the interests for smooth upgrade paths and everyone's sanity, the 6.x branch should take the same option.

For this, there seem to be (at least!!) two different patches for the 6.x branch -- at #25 and #69. They're not different -- much. But a decision would need to be made as to which one to commit!

FWIW, I am using the one at #25 and it works fine so far :)

The patch at #69 has a minor problem in that it removes the suppression of warnings for PHP 5.3:

-        //-- We need to suppress possible warnings (in PHP 5.3+) related to non-set timezones because
-        //-- Drupal6 does not save proper timezones (just offsets) and there's no good way to fix this.
-        $obj->timestamp = @strtotime($item->created_at);
-        $obj->time_ago =  t('!time ago.', array('!time' => format_interval(time() - $obj->timestamp)));        
+        //-- Convert date to unix timestamp so themer can easily work with it.
+        $obj->timestamp = strtotime($item->created_at);

On the other hand, the patch at #25 folds the processing done to each tweet from parse_items() into twitter_get_items(), which could be seen as a DX regression.

Updated issue summary: added links to comments

Here is a patch which unifies those at #25 and #69:

- Use parse_items(), as this is what 7.x-2.x does, so we keep the codebase more in line which makes future backports easier
- restored the use of the @ warning suppression on strtotime(), which is necessary for PHP 5.3 and Drupal 6.
- restored the setting of 'time_ago' on each tweet -- on D7 it's set in the theme preprocessor, but on D6 it's not.

Furthermore, I've added this:

- Fix from #27: breaks with lists and doesn't display the authors of the tweets.

(Version should change from 7.x-2.x to 6.x-1.x, but my comment in https://drupal.org/node/1781024#comment-7562523 stands -- this fix NEEDS a new release to be viable.)

Updated issue summary.

Unless this is still an issue can someone update the front page rather than linking to this thread? For new users being pointed to this thread it is very confusing.

Better to tell people to download the new commits and create new documentation.

Use parse_items(), as this is what 7.x-2.x does, so we keep the codebase more in line which makes future backports easier

Ah, good point - that looks like it was added to 7.x-2.x in a later commit. I wrote the patch in #25 as a straight backport of the original committed D7 patch here, and as far as I know that's the only reason mine didn't include any changes to parse_items(). So it probably does make sense to change that (especially now that there is only one supported API method to deal with; before Twitter actually shut off the old one, both code paths could work separately so there was a reason to have two independent methods).

> before Twitter actually shut off the old one, both code paths could work separately so there was a reason to have two independent methods).

We still have handling of both APIs. And the old API is now switched off. But for clarity, I think it's best for the 6x1x patch to match the 7x2x patch as closely as possible. I've filled a follow-up for removing code that supports both APIs: #2025127: [meta] clean up twitter API 1 code.

Thanks for that suggestion; at any rate, found the instructions kind of pointing me that way.

Regardless, I applied the patch, registered the application, and entered the pieces of relevant information into the site webform; it's now working well, so can attest to the viability of Twitter Pull v1.1

Thanks, everyone!

Can someone help me install the patch from post #76. I'm not sure how to do it.

Hey guys,

I extended the patch in #76 with a new permission for admin page.

@103: the patch in #76 is IN. Please file further changes as follow-up issues.

This issue is now about:

a. the need for a new stable release on D7
b. the backport of the fix that was committed to D7, to D6.

I'm using D6 and would rather not add any more modules to my website. I'm also managing my platform via drush make. Below is a snippet using the method from #41:

projects[twitter_pull][type] = module
projects[twitter_pull][version] = 1.4
projects[twitter_pull][patch][] = https://drupal.org/files/twitter_pull-d6-twitter_api_php-1781024-41.patch

libraries[twitter-api-php][download][type] = git
libraries[twitter-api-php][download][url] = git@github.com:J7mbo/twitter-api-php.git
libraries[twitter-api-php][destination] = libraries
libraries[twitter-api-php][directory_name] = twitter-api-php

I've never pulled from github before, and had to add my server's SSH key to my github account before I could clone. Hope this helps!

Ok, I'm shifting this issue to being about the backport to 6.x only -- it's too confusing otherwise.

The matter of a release being needed is now at #2028929: make a new release on each branch for Twitter API change.

@105 & others: Sorry to be blunt, but if you don't want to add twitter and oauth module to your website, then you are no longer using Twitter Pull module. You want the sandbox at https://drupal.org/sandbox/justindodge/2016387.

Rather than commenting here, please post any further issues on that sandbox project, and help the maintainer of that take it to full project status. Twitter Pull module has basically been forked, because there are two totally different directions to take at this point, both of which are valid.

Updated version of my patch at #97.

There was a problem with retweeted tweets not showing username or userpicture, because the conversion of the tweet in parse_items() from an array to an object wasn't deep enough.

(Though TBH I don't know why we need to do that -- doing json_decode(json_encode($item)) seems really ugly to me, but this is what has been committed to 7.x, so cleaning that up should be left to a future issue.)

The solution showed in the Issue Summary worked perfectly for me. =)
I wonder when they are fixing it in the module.

Changed patch needed for D6

I'm using patch manager to try to patch this and I'm trying to use the Oauth/Twitter method with the patch in 107. I'm getting the following error. Any ideas?

Patching did not go smoothly.
This command was issued: /usr/bin/patch -p0 --verbose -d '/usr/local/www/sites/wsupress/www.80/sites/all/modules/twitter_pull' -i '/usr/local/www/sites/wsupress/www.80/sites/default/files/patches/twitter_pull_twitter_api_php-1781024-76.patch'
This was the output from patch:
Hmm... Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff --git a/twitter_pull.admin.inc b/twitter_pull.admin.inc
|new file mode 100644
|index 0000000..db0bb34
|--- /dev/null
|+++ b/twitter_pull.admin.inc
--------------------------
Patching file twitter_pull.admin.inc using Plan A...
Hunk #1 succeeded at 1.
Hmm... Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff --git a/twitter_pull.admin.inc b/twitter_pull.admin.inc
|new file mode 100644
|index 0000000..db0bb34
|--- /dev/null
|+++ b/twitter_pull.admin.inc
--------------------------
Patching file b/twitter_pull.admin.inc using Plan A...
Hunk #1 succeeded at 1.
Performed Apply patch on 1 item.

Drupal.org patches are -p1. Please read the documentation about patching on d.org!

I have, but I'm not a developer. I don't have SSH access to the server, so I'm trying to use a module that applies patches. I have no idea what -p1 means to be honest. I've read the information on patches. I'm still stuck.

Bonnie the -p is the level to remove of path. For example if the path use a/twitter.... -p1 remove a -p2 remove a /twitter ....

Thank you! I finally figured out to do it and the patch ran.

Committed!

The D7 patch further up was in fact committed to a new 7.x-2.x branch, so I have followed suit and made a 6.x-2.x branch for this. That way we keep things consistent, and anyone wanting to fork the module at a point prior to the dependencies on Twitter and Oauth being introduced can do so easily.

Issue #1781024 by Jaesin, David_Rothstein, victoriachan, joachim: Updated for Twitter API 1.1.

(Hope I've not missed anybody off!)

I'll make new releases on both 2.x branches soon.

There are now new alpha1 releases on the 6.x-2.x and 7.x-2.x branches. Both include this fix.

If you don't want to have Twitter and Oauth modules as dependencies, your options are:

- look at the sandbox mentioned above
- make your own fork of the module. For your convenience, the 2.x branch starts with the commit for this issue :)