💡 Patreon WordPress 1.2.4 Beta is available


We are providing upcoming 1.2.4 version of the Patreon WordPress plugin to interested creators for testing.

This version highlights are:

  • Your integration will now acquire and use Patreon avatars of your users if they have a Patreon avatar and they dont already have an avatar at your WP site
  • A semi-important issue which may have forced re-acquisition of API credentials, leading to potential issues with post lock input boxes getting locked was fixed

Full changelog:

= 1.2.4 =

  • Plugin now automatically acquires Patreon avatar of Patreon users and uses it if they dont already have an avatar
  • Addressed reports of client credentials being deleted and forcibly refreshed
  • A rare issue which could cause spammy but harmless accounts being created when Patreon API was returning HTML was addressed
  • Unused remove_fetch_creator_id was removed

To install the 1.2.4 beta, just deactivate+delete your existing Patreon WordPress, and upload and activate the package below:

Your settings, info, locked posts will all stay the same.

When you install, the version will show 1.2.3, despite it is 1.2.4 beta. This will allow you to upgrade it easily from your plugin admin, later when 1.2.4 is actually released.

To revert back to 1.2.3, you can just deactivate/delete the 1.2.4 beta package you installed, and just install 1.2.3 from your plugin admin via WP org repository.

Any feedback and questions welcome!

Installed but content access looping back to the allow screen
Difficulties with Post Locking

So this beta version uploaded and took the place without any issues. On the first try, it did something new and asked for access to the user profile. Once that permission was granted, it would go to a login option for “login with patreon,” “login with wordpress.” The user chose “login with patreon” and it took the user back to asking for access to the profile again.

So, I deleted the client token and started from scratch. Didn’t help. Am I doing something wrong? I’m just filling in the information and copying it over to the wordpress site. I’m not sure how I could be doing something wrong.

Thank you for your help so far.


Once that permission was granted, it would go to a login option for “login with patreon,” “login with wordpress.”

Where does your user start the process from? From a locked post’s unlock button? Or, a ‘login with Patreon’ button in a login screen?


From a locked post on wordpress. We have also tried to start at patreon and click on a link internally to push them into wordpress.


So then the user is asked access, asked to pledge, and when he does that, is he returned back to your site?


No, it cycles back to asking for access again.


This may be due to some cookie situation at the browser of the user.

You can debug this more efficiently in the below fashion:

Create a new Patreon account with a new email. Then using another browser, pledge and login to your WP site with this new Patreon user. Just putting in a $1 locked test post and trying to unlock it will do.

This will allow determining if the issue is specific to that patron, or a general issue.


Did you solve this issue?


1.2.4 has just been released at WordPress.org repo:


Not yet. It’s happening to every user at the moment. I’ve been busy and haven’t attempted to try anything else once all my users said they couldn’t access the site. Definitely not a cookie issue. I’m led to believe it’s something I’m doing, but I don’t know what that could be since it’s pretty much a copy and paste project. I’ll keep looking and let you know.


You can check if you have any plugins that involve or modify cookies. Also, any oAuth plugins. If you have one, it may be taking over oauth procedure and you may need configuring it to recognize Patreon’s oauth.

Also ensure that caching does not interfere with the process - your site’s cache plugin, or host caching may be configured to show cached pages to even logged in users. Or there may be opcode cache in the server which may be interfering with the way pages rendered.