hook_ms_affiliates_commission($commission, $level, $amount, $account) - should $account be $affiliate ?

4 replies [Last post]
Mon, 05/10/2010 - 16:23
vector84
Offline
Membership Suite
Pay to Publish
Affiliates Suite
File Downloads Suite
Bonus Pack
Pay Per View
Joined: 04/01/2010
Status: 
Answered

So I was going through the code trying to figure out the best way to add a feature I need - affiliate commission schedule based on memberships (or user roles they grant) rather than the override setting on a membership setting the affiliate schedule when that membership is bought...

And I stumbled onto a very convenient hook, hook_ms_affiliates_commission, implemented as $hook($commission, $level, $amount, $account) in ms_affiliates.module.

The thing is, in this context, it seems like $account is undefined... if the hook is intended to receive the account of the affiliate receiving the commission, the variable passed to $hook in that context should be $affiliate, the account of the affiliate, not $account (assumedly that would be the buyer's account if it were defined?)

‹ Manually Assign Affiliate Status to Users? weight for the tabs ? ›
Top
Mon, 05/10/2010 - 16:50
#1
Leighton Whiting
Offline
Membership Suite
Pay to Publish
Affiliates Suite
File Downloads Suite
Bonus Pack
Pay Per View
Joined: 06/02/2009
Vector, Yes, you are right,

Vector,
Yes, you are right, it should have been $affiliate. None of my modules use this hook so that's why it wasn't caught before. I'll include this fix in the next release.

Sincerely,
Leighton Whiting

Top
Wed, 05/12/2010 - 15:40
#2
vector84
Offline
Membership Suite
Pay to Publish
Affiliates Suite
File Downloads Suite
Bonus Pack
Pay Per View
Joined: 04/01/2010
Well, not sure if you're

Well, not sure if you're interested, but figure I'll toss it out there...

What I needed was affiliate payouts based on what membership the affiliate in question has - denying a payout if the level of distance between the affiliate and the buyer is farther than the membership permits, the commission is not paid.

With the aforementioned hook (patched to $affiliate) this was actually very easy to accomplish, especially going a bit around best practices ;)

Membership plans store their override values even if they're not using them for anything... I exploited this to not have to add supporting form code and such, though obviously a better way to go about this would be to in fact have an extra option for it...

But anyhow, barring a few hacks to make things a bit more friendly...
(making the specific DB field max_levels display on membership plans, making 0.00 affiliate payments not get recorded)

  1. function custom_af_ms_affiliates_commission(&$commission, $level, $amount, $acount) {
  2.   if (!empty($account->ms_memberships)) {
  3.     // Find the first active membership and use it to verify
  4.     // Kinda assuming Enforce Single Membership Plan, probably shouldn't?
  5.     foreach ($account->ms_memberships as $membership) {
  6.       if ($membership['status'] == 1) {
  7.         $membership_plan = ms_membership_load_membership_plan($membership['mpid']);
  8.         break;
  9.       }
  10.     }
  11.     // If we got a membership plan, use it to validate the commission
  12.     if ($membership_plan) {
  13.       if ($level <= $membership_plan->data['override_settings']['ms_affiliates']['settings']['main']['ms_affiliates_max_levels']) {
  14.         return;
  15.       }
  16.     }
  17.   }
  18.   // If we made it here, unable to find membership, or to validate... no commission
  19.   $commission = 0.00;
  20. }

Top
Wed, 05/12/2010 - 17:19
#3
Leighton Whiting
Offline
Membership Suite
Pay to Publish
Affiliates Suite
File Downloads Suite
Bonus Pack
Pay Per View
Joined: 06/02/2009
Vector, So what you are doing

Vector,
So what you are doing is allowing affiliates with a certain membership plan to get commission for more (or less) than the default number of levels?

If that is what you are after, I may be able to add a setting to MS Affiliates that would let you specify custom levels and commissions on a per-role basis that should accomplish the same type of thing.

Sincerely,
Leighton Whiting

Top
Thu, 05/13/2010 - 11:51
#4
vector84
Offline
Membership Suite
Pay to Publish
Affiliates Suite
File Downloads Suite
Bonus Pack
Pay Per View
Joined: 04/01/2010
Just less than the default

Just less than the default levels actually, but yes, that's exactly what I'm doing.

On a per-role basis was indeed my first thoughts on implementation, this was a rather convenient shortcut I stumbled onto while looking for how to do it based on user roles...

As a side note though, I think I can use Pay-to-Publish to accomplish some other functionality I was looking for, and if that's the case...

Essentially I'm thinking about trying to use Pay-to-Publish to facilitate direct donations to the site, since I want content created when the donations happen anyhow, but the point is I would still need the tie-in to happen at around the hook_ms_affiliate_commissions level roughly, since I need it to still loads the order-specific affiliate data for the Pay-to-Publish orders, which will be set to 0 affiliate levels, ie direct donations not providing a referral commission at all.

As such, if user-role based overrides were done at the MS_Affiliates form level, that would make it overridable at the order-type level again, right?, which would achieve precisely what I'm looking for by being able to disable that setting for pay-to-publish orders.

(Though I'm not actually all that opposed to requiring the actual active membership plan the way I'm doing now, not just the user role it creates, especially with how well the add membership functions work now - but I suppose it at least a bit outside best-practices to offload what should be controlled by affiliate permissions to go looking for membership plan data, especially the hackish way I've done it ;)

Top

Twitter Feed