[Plugin: Flattr] Cannot authorize with application

Then I recommend you to reinstall plugin (delete the plugin directory).

I’ve tried to remove/reinstall the plugin and delete options in DB, but always the same error.

So, there’s no solution for my problem ?

This can very well be a problem at your hoster and totally unrelated to the plugin or API code…

I run the latest Wordrpess (3.2.1) and the latest Flattr Plugin (0.9.25.4.1). I tried the cookie/cache deletion. I tried 3 different browsers. I tried different callback domains – no help. I always end up with “Callback Error. Please clear…” after I click Authorize.

I cannot test TheSteelRat’s suggestion. I’m not sure where and how to add print_r. For me line 506 is a “return” – so I don’t see what to do there. I’m not a real programmer.

I have a very widespread German/English host (Host-Europe). They should be configured fine.
So I dunno what else to do – and get a bit annoyed having to put everthing by hand on flattr.

Anybody alse with Host-Europe NOT experiencing this problem? It could very well be that your hosters firewall rules forbid direct communication of the flattr plugin API with the flattr webservice… Numerous people report communication issues with their cheap-hosters…

I’ve finally found the source of my problem. It’s due to the “WP To Twitter” plugin who have also OAuth classes but use 1.0a version.

I’ve rename the oAuthRequest class in Flattr plugin and now it works ^^

I wouldn’t know how to rename any oAuthRequest in the Plugin. This is all a bit over my head. I don’t even know what an oAuth really is. I don’t have “WP To Twitter” – and the only plugin that sends stuff to other sites is Akismet, for all I see.
That one works fine though. And the provider is good quality – considering their size I would think they wouldn’t have unusual settings. Maybe I could check with them. What specifically should I ask them for?

The problem is historical,

Flattr and some Twitter plugins use a generic oAuth class that they derived their specific subclasses from. As we first discovered the problem with duplicate function definitions, we decided to encapsulate Flattrs oAuth implementation. This would result in class definitions if not yet defined. Now whatever plugin occupies the oAuth namespace first can define it’s functions and Flattr will use them as well because they should be generic, right?

But if Twitter plugin developers claim that oAuth and especially Flattr are not their concern this can become a hassle as soon as they make specific additions to the otherwise generally used classes and functions. Developers can get very reluctant on that ??

Best thing to fix the problem would be to encapsulate Flattr oAuth library to a private namespace. This would fix all incompatibilities at once at the cost of additional memory overhead in the php engine.

In addition I have to say that I can’t work on the plugin anymore until middle of september as I’m pretty occupied with live and work stuff. I’ve got some fixes on the test bench already thanks to bloggers extensive feedback but I’m lacking the time for proper testing and further fixing… Sorry about that.

Any development on this issue?
I’m using the plugin version 0.9.25.5, WordPress 3.3.1. Disabled all plugins that use Twitter, didn’t help. Still the problem that “token” is empty.
thanks

I’m also still struggling to authorize the plugin. For some reason I can only choose “(re-)Authorize with Flattr.”

I’ve tried to delete the plugin and re-install it. Still, when I push “(re-)Authorize with Flattr” I get “An error with the sent parametrs occurred. Go back”

This is the address: https://api.flattr.com/oauth/authorize?oauth_token=&access_scope=read,readextended,click,publish

Anybody have a clue what’s going on?

Please install the update as soon as it is available for download. It should fex all authorization issues.

Hm. I’ve just installed the Flattr plugin from scratch — it’s my first time (so I’ve got a clean database!) and I’m a brand new Flattr user.

I have the same issue as @mabahi above. The URL for authentication is the same, the error is exactly the same, the page seems to be the same.

Plugin version is 0.9.25.5. My hosting provider is Dreamhost, which usually has no problems in contacting external sites, with three (possible) issues:

1) Sometimes, Jetpack also fails to connect under PHP 5.3. The solution is to go back to PHP 5.2, attempt to connect, and try again. Should I do the same for Flattr? What do you think?

2) I’m using W3 Total Cache.

3) My blog (https://gwynethllewelyn.net/) runs behind CloudFlare. Again, this usually doesn’t make any difference, but it might — I would probably need to punch a hole through CloudFlare.

I’ve registered another site as a test, which is also hosted on Dreamhost (but with PHP 5.2 FastCGI instead of PHP 5.3), uses W3 Total Cache, but doesn’t use CloudFlare. I got precisely the same errors.

This latter site has an advantage: I can bring it down (it has next-to-zero visitors). So I did the following experiments:

– Downgrade to PHP 5.2 (not FastCGI). Same errors.
– Deactivate W3 Total Cache. Same errors.
– Deactivate all plugins except Flattr. Same errors.

So my guess is that Dreamhost is to blame. Jetpack is also misbehaving, so that could be a hint. I’ll try again tomorrow early morning (less traffic on the ‘net) and see if the problem remains.

And I’ll try to install Flattr on a different hosting provider, too.

All right! Version 0.99.1 seems to have fixed all issues. Thanks, @aphex3k ??

I started with my “test” site, with W3 Total Cache turned off. Authentication was immediate and worked well. In fact, I appreciate the complete rewrite of the plugin: now the buttons will immediately appear, even if there has been no Flattr authentication (which I assume that is only important to feed posts back into Flattr but not for getting the button to work). But authentication worked well. The communication tests are a great idea, and they all went green in my test, and I saw my username & avatar on the popup. Great work!

On my “main” blog, I was a bit more “evil”. I did not turn W3 Total Cache off (and remember, it still uses CloudFlare on top of everything). So I tried the new version. Well, the connection went well. It redirected to the correct Flattr page to ask for authorisation. A new “connection” appeared in Flattr under Settings/Applications. When returning to WordPress, however, both the username and the avatar were blank! Nevertheless, the buttons show up as expected. I’m not 100% sure if my main blog is feeding articles to Flattr or not, but I’ll be watching them closely.

In any case, 0.99.1 seems to be working fine, and in case of doubt, disabling the W3 Total Cache during Flattr authentication might be all that is needed.

Thanks!