Feeds OAuth conflicts with OAuth module [#2026453]

UPDATE: The fix to this issue requires you to download a new version of the php-proauth library! See this comment for details.

Since this module removed the OAuth module dependency and includes OAuth on its own, it now conflicts when used with a module that requires OAuth, such as Twitter. If both are used in the same page request, the OAuth classes are declared twice and causes a 500 server error.

This happens consistently on cron with the OAuth and Twitter modules enabled and a feed with OAuth authentication. The error does not occur when OAuth is disabled.

Comments

Comment #1

Phil Wolstenholme commented 24 June 2013 at 16:53

Same problem for me:

Fatal error: Cannot redeclare class OAuthException in ... /sites/all/libraries/php-proauth/lib/oauth/OAuthUtil.php on line 82

I'm using:

Feeds OAuth Fetcher - 7.x-1.0-beta1+3-dev
OAuth - 7.x-3.1+4-dev

Comment #2

infojunkie

Vancouver

commented 26 June 2013 at 16:19

Thanks, working on it.

Comment #3

kc99 commented 10 October 2013 at 16:30

Any new developments on this issue?

Comment #4

kscheirer

English

Vallejo

commented 14 October 2013 at 23:28

Priority:

Normal

» Critical

Both modules should be using the Libraries API module to handle this conflict.

Comment #5

cwithout commented 15 October 2013 at 17:16

How would Libraries API handle two classes loaded into the same page request with the same class names? I'm not aware of any way it can prevent the issue of the class name already being declared.

Or are you suggesting that by using Libraries API, only one OAuth class would be loaded? It's not as simple as that, because the OAuth module and Feeds OAuth module use different OAuth libraries. The classes are named the same, but their properties and methods are different. So the code would have to be changed on one or the other so they're using the same OAuth library.

In which case, there might be no benefit to Feeds OAuth loading the OAuth library on its own rather than using the OAuth module as a dependency for loading the OAuth library as it used to.

Comment #6

kscheirer

English

Vallejo

commented 15 October 2013 at 18:38

Priority:

Critical

» Normal

Ah, sorry, I didn't understand the issue then. Any suggestions? Seems like going back to a dependency on oauth module would fix the problem, but they only support oauth 1.0 - how big of a problem is that?

Is the report in #2 still valid? Looking at the 7.x-3.x branch of oauth: http://drupalcode.org/project/oauth.git/blob/refs/heads/7.x-3.x:/lib/OAu..., it seems they've added a check to make sure OAuthException wasn't already defined. But I guess that doesn't help if you can't control the order in which they're loaded.

There's a thread in the oauth issue queue (#1591692: Replace current OAuth library) with some reservations about even supporting 2.0, partly because of the lead developer's post http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/.