Hello, I recently wanted to create a table with Patron status. Many former Patrons had the active status, while they were unsubscribed for a long time.
I tried using the plugin’s function Patreon_Wordpress::getPatreonUser($user).
I supply a valid user object, but the return value is always false.
I’ve found that the problem might be in the token refresh, as it has the error:
{“error”: “invalid_grant”}
I followed the steps to refresh the V2 API (💡 How to upgrade your Patreon WordPress to use API v2) but nothing changed.
How can I make the plugin refresh the user activity statuses correctly?
Some questions:
Do these former patrons have active patron status at your site only? How did you determine that? (ie what field did you check)
I tried using the plugin’s function Patreon_Wordpress::getPatreonUser($user).
For any patron who have logged in at least once, this function will return the saved/cached patron info unless it is able to contact the api. This cached info is used for 3 days. So try checking whether you are getting such a return from your local cache instead of the live result.
Best way to test patronage is to create a new patron account at patreon.com with a different email, (same payment info is ok) and pledge to your campaign from a $1 tier and try unlocking a post locked for $1 etc. If this test results in false returns, then there may be a more fundamental problem at your site.
1 Like
Thank you for the reply!
Do these former patrons have active patron status at your site only? How did you determine that? (ie what field did you check)
Yes, I am cross-referencing their status with Patreon’s dashboard.
I’m checking the data I get with get_user_meta( $user->ID, ‘patreon_latest_patron_info’ );
From that I check [0][‘included’][0][‘attributes’][‘patron_status’] to get the status.
For any patron who have logged in at least once, this function will return the saved/cached patron info unless it is able to contact the api. This cached info is used for 3 days. So try checking whether you are getting such a return from your local cache instead of the live result.
With Patreon_Wordpress::getPatreonUser($user) I’m just getting a FALSE result (gets to the end of the function, as the token refresh method returns {“error”: “invalid_grant”} ). It does not get cache data, as I’m looking at users who have not logged in for over 3 days mostly.
Thus, I’d like to be able to verify if their status is really active, versus the status stored in their metadata.
Best way to test patronage is to create a new patron account…
Yes, I am testing that way. For a fresh login with Patreon, Patreon_Wordpress::getPatreonUser($user) provides the expected result.
Issue is, I have Patrons who log in once a month and are active. Or are annual and log in once a quarter. I’d like to be able to run a cron job once a month, going through all Subscriber accounts on my website and checking their current status via the API.
I know I can make a workaround and just use the monthly CSV data from Patreon to manually set activity status for users, but this is going against automatization.
Can you try calling the api using a patron’s token? Then also try with creator token? Try to make some of the calls that are in api v2 class and see if you are able to get any valid return from any of them. And any errors if there are any.
1 Like
Calling the API with a Patron’s token like this ($patreon_access_token for the tested user was verified to exist and was of the proper string length):
$patreon_access_token = get_user_meta( $user->ID, ‘patreon_access_token’, true );
$patreon = new Patreon_API( $patreon_access_token );
$api_return = $patreon->fetch_user();
The error I get:
Array ( [errors] => Array ( [0] => Array ( [code] => 1 [code_name] => Unauthorized [detail] => The server could not verify that you are authorized to access the URL requested. You either supplied the wrong credentials (e.g. a bad password), or your browser doesn’t understand how to supply the credentials required. [id] => 316e7d0c-9a07-59fc-afae-9cd8b1d4c725 [status] => 401 [title] => Unauthorized ) ) )
When calling the same function with my creator access token, I get a proper result with all the data expected.
When calling the same function with my creator access token, I get a proper result with all the data expected.
That means that patron token is expired and that patron will be prompted to re-auth via Patreon the next time he or she comes to your site. Its normal.
And yes, you should be able to access that patron’s info normally with your creator access token just like you have.
And yes, you should be able to access that patron’s info normally with your creator access token just like you have.
Sorry, I was not precise here. I get the proper result data about me (creator data), as in that function, the token used is my token. At no point was the user addressed in that function when supplying my creator access token. There is no way to do this, from what I know - the function takes only one token.
You can use the same includes and the fields that are used in fetch_user call in the api v2 class and use it to have your members return the same fields when you are calling the members endpoint with your creator token.
1 Like
Thank you for the suggestion. This is something I’ve tried a long time ago, and the results are the same as back then.
Using a call like this:
$api_return = $this->__get_json( “campaigns/<my_campaign_id>/members?include=currently_entitled_tiers,campaign&fields[user]=email,first_name,full_name,image_url,last_name,thumb_url,url,vanity,is_email_verified&fields[member]=currently_entitled_amount_cents,lifetime_support_cents,campaign_lifetime_support_cents,last_charge_status,patron_status,last_charge_date,pledge_relationship_start,pledge_cadence” );
First of all it doesn’t return the emails.
Secondly, it doesn’t return all currently subscribed members. The return value has 21 results, while I have over a thousand subscribers.
You must specifically include the email and then ask the field like how fetch_user call does. Also, you need to paginate the result. You can request up to 1000 results per page though, this would give you most of your subscribers. However better to do 2 pages of 700 so that you can get all your subscribers in 2 calls.
1 Like
Thank you for the help!
The email was in the member include, while in the fetch_user call it’s in the user include.
Pagination also did the trick.
We can mark this as solved.
1 Like
Great to hear. If you have any more questions after this, just post a new topic and we will look into it.
1 Like