After a couple of weeks trying to figure out why my own website was having issues getting data via the Patreon API, some of which was my own fault, some of which wasn’t, I’ve decided to maintain my own fork of the PHP API that is both 100% compatible with the official API but also allows settings on construction of the class, bypassing the API cache (which caused some of my issues), and streamlines a few operations in the code.
Certainly, it does, I didn’t see a reason to not include this in the existing fetch_* functions that call the get_data function though, and thus added it. My thought was that most people are going to only think to use the fetch functions initially–as I’m a PHP programmer and honestly that was my first thought–so why not give the option there.
That said, after troubleshooting my own site I suspect my issue is actually something to do with how my app builds it’s cache of the code for production or how it retains classes in memory and not anything to do with your package itself (or it’s own cache), as I can’t duplicate my issue outside of my own app in standalone files with mock data. Which is a bit infuriating, but such is how frameworks go sometimes.
App cache issues are a major class of issues which patrons report as ‘Content doesnt unlock’ or ‘I cant access content’. It may not even happen due to your app - a patron’s browser/device or even ISP may cache pages for some time. For some reason sending no cache headers is pretty useful, like how WP plugin does.
Checking the code used in sending no cache headers in the WP plugin may help you choose which headers to send for your app.
The script worked fine for my patrons, but they access it from the front-end of the website, and if it caches their details, well, it’s only requesting their details anyways so it doesn’t matter.
My issue is when an update command executed from the system shell on the server used the script to check statuses and update patron data in the background using their stored access tokens. Duplicating the API cache logic in my own developer instance to see how it operate produced no issues. So I know it isn’t that. I feel pretty confident ruling out an external cache as it’s a data center hosted virtual machine instance–the only thing that’d be receiving those headers is the Patreon API on Patreon’s side. That only leaves something about my app, and I know it’s caching because I’ve done enough debugging to know that it switches between patron access tokens before passing them to the API package but always returned the same patron’s details afterwards.
Given that I’ve found a resolution for it and it’s 40-ish lines of, now fully functional, code that interfaces with the API inside 20k+ other lines that are themselves inside a couple hundred thousand line PHP framework, I’m going to focus on more pressing issues. If I circle back to this later to do more troubleshooting, I’ll try to remember to let you know what I find in case other Symfony developers have the same issue later.
So, I’ve figured out where I want to take this next, and the answer is “simplifying the entry requirements for using the API”.
What this means, is I’m going to extend my API fork to include basically every API call you can do, to include relationships of relationships of API data.
Working on it earlier today has lead me to conclude that there’s no properly decent tutorials out there on how to do some of this stuff, and rather than just tell you how to do something I’m going to show you how to do it with a tool that can do it and then provide you that tool.
I’ve already finished the condition checks for how this works when basing off a user and it can grab just about every reasonable thing you could want that the API docs say exist. There’s also a “just give me the basics” flag which returns fields not exposed by the existing PHP package and also, by default, includes the campaign of a membership and the tiers that member is entitled to. There’s also an override for when you just want to throw your own request string to save on runtime. With that figured out, it’s just a matter of figuring out the other API starting points and either copying and adjusting logic or incorporating them into the existing function.
Beyond that, I’m going to build a parser function that will take the API return and turn it into something more easily workable, meaning even if you request every scope for a user and that user has 100 creators they support, it can be returned in a fairly neatly organized way that cuts down the headache of figuring out who supports which creator at what amounts for how long and how often they payed and anything else I feel like tossing on the pile. It’s a bit of making an API for an API but it should significantly flatten and simplify the API returns before returning them to the application.
Oh, and it’ll still be backwards/hot-swap compatible with the existing package. I’m only adding functionality here.