✨ Patreon PHP — a modern PHP library for Patreon

1

As of January 2019 this library is archived and will no longer receive any updates and/or fixes. This library is not compatible with the new Patreon API.

Due to lack of use this should be not impactful, however if anybody is using the library and wishes to take over maintenance please let me know. The post that follows is the original post, please note that some links may no longer work.

Hi!

I have put together a new library for PHP developers working with the Patreon Platform. Patreon PHP is designed to make integrating Patreon into your modern PHP application very easy.

Features

  • Modern PHP (7.2)
  • Ready-to-use example project available (visit it at patreon.1f991.com)
  • Accept Webhooks from Patreon — secure signature verification included!
  • Retrieve all pledges (the library handles pagination for you)
  • Determine entity state with helper methods, e.g: $user->hasActivePledge(), $reward->isAvailableToChoose(), $campaign->getAvailableRewards(), $goal->hasBeenCompleted() (and many more)
  • Simple Patreon OAuth client

Also…

You can find the source and documentation on GitHub and the example project is available on GitHub too. The following are a couple of quick examples to show how easy this library is to use.

Output the name of every patron of your campaign:

use Squid\Patreon\Patreon; 

$patreon = new Patreon('creators-access-token');

$campaign = $patreon->campaigns()->getMyCampaignWithPledges();

$campaign->pledges->each(function ($pledge) {
    echo $pledge->patron->name;
});

Output a link to each of your available rewards:

use Squid\Patreon\Patreon; 

$patreon = new Patreon('creators-access-token');

$campaign = $patreon->campaigns()->getMyCampaign();

$campaign->rewards->filter(function ($reward) {
    return $reward->isAvailableToChoose();
})->each(function ($reward) {
    echo "<a href='{$reward->getPledgeUrl()}'>{$reward->title}</a>";
});

Determine if the user who just logged in via OAuth is an active patron:

use Squid\Patreon\Patreon; 

$patreon = new Patreon('visitors-access-token');

$me = $patreon->me()->get();

if ($me->hasActivePledge()) {
    echo 'You are an active patron, welcome to my website.';
} else {
    echo 'You must be an active patron to access this website.';
}

All feedback, ideas and contributions are gratefully received and welcomed. Please let me know if you have any questions about using the library, happy to provide guidance :slight_smile:

Thanks!

4 Likes
2

Kudos, meticulously written and seems to be a labor of love or a very tight spec doc.

I’d say 7.2 as a requirement is a bit too early since 7.x versions are only ~15% at the moment and 7.2’s share is ~5% among 7.xes, but if maintained, this lib can be very good for people who want to get going with 7.2.

One bit - while going through the code i dont think i spotted a way in which the code caches any call/return from the API for any particular value (current pledge $ of the user, or campaigns etc) and returns that same value if it is requested in the same page load or the same instantiation of the class. Which could save many API calls. Am i mistaken? Or any of the lib(s) you used provide that?

If not, that would be a very good point for improving your lib.

1 Like
3

A cross between a labor of love and knowing that I’m going to be using this library so if I cut corners I’ll be paying for it in a week.

The decision to use 7.2 is based on the desire to be able to take advantage of what modern PHP has to offer. PHP 5.6 is already EOL (with less than a year of security fixes remaining) and 7.1 is approaching EOL too. Supporting 5.6 is a no-go and as modern PHP developers probably aren’t deploying to shared hosting – they’re either managing their own environment or using a PaaS – they’re unlikely to be bound to 7.1 (if they have access to 7.1, they almost certainly have access to 7.2).

The classic mistake when developing open source software is making a bad decision and then being bound by that decision for eternity, I didn’t want to find myself doing everything I could to allow this library to work on legacy systems now because if I do it now then I’ll be doing it for the rest of my life[1]. The Patreon team have said that the intention is for the platform to evolve and grow over the coming years (and my own view is that Patreon is here to stay and developer interest will only increase) so I wanted to build something forward facing.

The library was designed to be flexible[2] so it is not opinionated about caching, developers are free to implement their own caching which can be done in a couple of lines using php-http’s plugin system (and the Cache Plugin specifically). That said, I am sure there’ll be people unfamiliar with the flexibility of php-http so I should definitely document how to do that, thanks for the suggestion! I’ll add it to the documentation in the coming days.

I was a little conflicted over whether or not get or fetch was the right method prefix to communicate clearly to developers which methods hit the API but I figured it didn’t matter much as it’s unlikely a developer wouldn’t assign the result and work with the result instead. e.g:

echo $patreon->campaigns()->getMyCampaignWithPledges()->creator->full_name . ' has ' . $patreon->campaigns()->getMyCampaignWithPledges()->patron_count . ' patrons.';
// vs.
$campaign = $patreon->campaigns()->getMyCampaignWithPledges();
echo "{$campaign->creator->full_name} has {$campaign->patron_count} patrons.";

Thank you for the feedback! Much appreciated :slight_smile:

[1] I learned long ago that the moment you release something into the world you become responsible for it and you cannot just give it away or just shut it down, you’re chained to maintaining it indefinitely unless you’re lucky enough to find someone else to take over. I launched a service more than 5 years ago now that was never intended to be production ready, it was a proof of concept, and since then it has delivered hundreds of millions of requests and continues to deliver millions every month and I have an obligation to continue to run it because people depend on it. Every time I launch something now, whether that’s a library or a service, I make decisions on the basis that I will probably still be responsible for maintaining it in 5 years, and I definitely don’t want to wake up 1,825 days from now to thoughts of legacy PHP. Shudder.

[2] Although I’ve already identified one shortcoming in that respect, I will also be adding support for extending entities in the coming days, so that developers can implement their own helper methods.

3 Likes