On cron: Unexpected error: Sorry, that page does not exist

Updating twitter api in twitter setting to api.twitter.com/1 will solve the problem.

Thanks for the tip. I can attest that changing the API URL solved this issue for me.

A simple patch, change Twitter API address to "https://api.twitter.com/1".

Changing the api didn't work for me.

Doesn't work for me either

I think URL is what needs to change, but not for all requests - api.twitter.com/oauth/whatever for example should not have the preceding /1.

Here's a patch I wrote that works for me, but I'm doing very little with the twitter API so I'm sure it could use some testing.

To clarify my statement in #7 - the URL should NOT be changed in the module settings, this is a code only fix.

This works for me.

Does this "1" refers to API version?

@vitalsouto - Yes, '1' is the API version.

This info is posted on the 6.x version of this issue, it comes from twitter:

"All non-versioned API endpoints will go away. Though you may occasionally find these endpoints responding as we ramp down, expect them to be gone in two weeks. This list includes:

All API endpoints on www.twitter.com and twitter.com.
Endpoints on api.twitter.com without /1, /1.1 or /oauth in the fully qualified URL."

On #7, it looks like the TwitterOauth object is only used for OAuth requests.. I'm not sure how your patch would solve the problem, since OAuth shouldn't have the version in the url. The create_url function in the non-OAuth section seems to already add the version to the uri already. Not sure where the breakdown is but I'm having trouble with the registration portion of module. So login and authentication works perfectly and the user lands on the registration page successfully. After logging in or creating an account I get the error.

@Matt - I think the assertion that the TwitterOauth object is only used for OAuth requests is incorrect -
In twitter.pages.inc you have:

function twitter_oauth_callback_form_submit($form, &$form_state) {
  $key = variable_get('twitter_consumer_key', '');
  $secret = variable_get('twitter_consumer_secret', '');
  $response = $form_state['twitter_oauth']['response'];

  $twitter = new TwitterOAuth($key, $secret, $response['oauth_token'], $response['oauth_token_secret']);
  try {
    $twitter_account = $twitter->users_show($response['screen_name']);
  } catch (TwitterException $e) { 

This submit function is part of the process of adding an account, and this instance of the TwitterOAuth class calls ->users_show which actually uses the create_url function modified in my patch, since at that point we have the OAuth object. For me this was the holdup - unless I made TwitterOAuth's version of create_url make the adjustment to the outgoing url for this non-oauth request, I couldn't complete the process and got the 'not found' error, since users/show was missing the API version before it. I think but am not sure that the oauth version of the class is used whenever it is possible, but I don't really know the module that well.

After logging in or creating an account I get the error.

Can you be a little more specific about what's going on there? I'm not certain what the problem is you're having at this point or what you're doing to reproduce the problem.

#7 fixed the issue for me.

Changing the Twitter API address to "https://api.twitter.com/1" cleared up the errors for me.

@BeatnikDude - That solution seems to work for some uses cases, but I think you will have problems when doing something like adding a new twitter account, for example.

#7 fixed the problem for me, too.

Thank's a lot :)

Works for me, too. However...

Programmatically forcing a "/1" onto the end of the API url bodges any hope of compatibility with other microblogging services, doesn't it? Wouldn't the right solution be to have an extra configuration field for "API version", or else to separate the OAuth API address from the versioned API address?

Sorry I was at the great american beer fest this past weekend and didn't put up the use case.

I have the twitter and twitter sign in modules turned on. There are two major use cases with twitter sign-in:

1. Sign in with twitter, user does not exist already, register new user
2. Sign in with twitter, user already exists, sign-in to link registered account to twitter account

The actual twitter sign in seems to work perfectly fine. After signing in, I'm sent to the user registration page, also good. The last steps are the problem. No matter which way I go (either sign-in or new registration), I get "Request failed: Sorry, that page does not exist."

#7 fixed the problem.

Add new twitter account - PASS
Import users twitter on cron - PASS
Post to twitter.com - PASS
Sign in with twitter - Not Tested

Hello,

This patch works for me.
It adds a new variable to set the API version we need to use.

Regards,

I can also confirm the patch in #7 worked for me. But it seems like a kind of hack. Shouldn't we be fixing this module to work only with the Twitter API v1.1 and leave behind 1.0?

@#19, #22, and #23:
I think you guys are adopting an appropriate programmer's attitude about compatibility and being forward thinking, but I don't think multiple versions/variables for the API is applicable here.

The twitter.lib.php file is bound to the version 1 API, and changing to '1.1' or any other thing via variable input would likely just break the code right now. Using a new version of the API needs to coincide with a development effort to support that API on the back end, at which point the version should be hard coded to '1.1', as a variable set to '1' would also break things.

Personally, I can't see the value in being able to use more than one version of the API at a time, but if someone has real justification for it, that would be nice to know.

I'm sure that using the most recent version of the twitter API is the way forward eventually, but for now Twitter has stated:

"All non-versioned API endpoints will go away. Though you may occasionally find these endpoints responding as we ramp down, expect them to be gone in two weeks. This list includes:

All API endpoints on www.twitter.com and twitter.com.
Endpoints on api.twitter.com without /1, /1.1 or /oauth in the fully qualified URL."

So there isn't anything especially hacky about the explicit use of a version of the API that is supported by Twitter - what's hacky is the unversioned requests that broke it in the first place.

Personally I continue to recommend the patch at #7.

Hopefully that's helpful!

I created a similar patch here:

http://drupal.org/node/1814610#comment-6610254

Sorry, I didn't see this issue :-)

I agree with #24. I think we should just dump API v1 and support v1.1 in the back end.

#7 work, fixed the issue for me to.

Thanks.

Tnx #22, I've created patch for drupal 6 on its base.

Hi edhel, what D6 version of the module did you make the patch for? It's failing on hunk 2 when I try to apply it to the latest dev version (2012-Aug-20), and doesn't look like it works on the latest version in git.

Marking duplicate of #1814610: Use proper API URLs, which has been committed to 7.x-3.x-dev and will be backported to 6.x-3.x-dev.

http://drupalcode.org/project/twitter.git/commitdiff/67814a1

@justindodge
I finally sat down and traced the stack through the application. You were correct on the location of the bug; it was the call to https://api.twitter.com/users/show.json.

After patching the file on my dev box everything worked well but on my production instance it wasn't. On both installations I had the twitter.api.php file in the libraries folder (as well as inside the module directory) and had not patched the twitter.api.php file inside the modules directory.

Do I need the twitter.api.php file in the libraries folder?

@Matt The file in question is actually twitter.lib.php, and it should be in the module's folder, there's no reason that I know to have files in the libraries folder for this module.

fizk has managed to get a patch committed that resolves the issue though, so patching is no longer required - I would just download the latest dev version of the module which has already updated.

2timmerk: I use 6.x-3.0-beta3.

fix should be in 6.x-3.x-dev also, as of http://drupalcode.org/project/twitter.git/commitdiff/118d859ebb8e786010b...

this duplicate issue is resolved, please test the -dev version and report back so we can get a stable out