Affiliate Manager 5 and Other Development Campaigns

I’m always surprises me at how quickly time passes (Thursday already!?). By now you’d think I would have adjusted my expectations. I had intended to post every few days but that didn’t last long.

The update of Affiliate Manager to compatibility with Merchant 5.x (although it’s a bit of a stretch to call it an upgrade given how much re-writing had to be done) has been done for a number of weeks now but the development of the module is still on going. It was my intent to add the ability to permit “product specific” payout configuration (i.e. the ability to, on an affiliate-by-affiliate basis, set different payouts for different products) to the initial release. However, I ran into some indecision on how best to implement it which slowed it down enough to get left out. I am still working on it but the indecision remains on how best to go about it. I polled a few developers who were looking for the features for their opinion on how they saw it as working but I never got a reply. So, I’ll lay out some possibilities and see if any one out there has an opinion (more specifically an opinion on how best to go about it….we all have opinions but not all are particularly relevant to this particular question).

In earlier versions of the module, “product specific” payouts were sort of a hack (and that hack still works in 5.x). The merchant would set each product’s “cost” to a particular value, then configure each affiliate’s payout to be based on a % of the product’s cost and thereby achieving a variable payout for each affiliate. Of course that kept you from using the cost field for anything else, but it was a nice representative of that “bang a square peg into a round hole” mentality that typified the glory days of Merchant (ahhh, the memories).

In the 5.x version of the module I’d like to add this as a more particular option configurable on each product’s page in admin. The question is how far to take it; how many options are really going to be used? Currently, each affiliate can have their payouts configured as a percentage (of the price paid, product cost, list price, or “profit”), a “per purchase” payout, and/or a “per product” payout. And each of these can be configured separately depending on what “level” the a referral was. Do we need that many configurable options for the prdouct-specific payouts? Would it be safe to assume that product-specific configurations would be necessary only for “primary” affiliates (i.e. those directly responsible for the referral)?

I’m currently in the process of upgrading/re-writing the Affiliate Login module and hope to have that ready next week. After that will be a new module, Affiliate Design which will replace the “Affiiate store-settings” feature of Affiliate Manager 4.x. I’m not entirely certain how best to go about changing the Merchant 5.x templates but I’m sure I’ll get it worked out.

I have been pushed off the boat…it’s the Viking way

After months  of managing to find a millions reasons not to get my feet wet in the “blogosphere” my fellow Vikings have taken the “sink or swim” approach and pushed me off the boat.   I’m averse to death so here you have it, my first blog post.

Last year we attended the Rails Conference.  One of the speakers asked the crowd, a room of  maybe 1000 people, how many had blogs.  Very nearly 1/2 the crowd raised their hand.   I personally doubt that 500 people in that room really had something to say worth reading.  And I suspect the same can be said for most of what I  would really like to say (which is probably where all those other bloggers go wrong).  That said, I’m going to try to focus on what you might be interested in reading, mainly information on our modules and development (current and future).  Also feel free to make suggestions on subjects you’d like to hear me ramble on about.   At least that way I’m guaranteed at least one interested reader.

First up will likely be a discussion on the upgrade of Affiliate Manager to 5.x.

Michael Brock
a VikingCoder

Hyper Development Mode!

Hyper development..maybe not, but it does save a few clicks. Here’s how I use Miva Merchant with MySQL for local development:

I use Instant Rails (Ruby, Rails, Apache, and MySQL all bundled together–there are similar suites for php). What’s nice about this, and the php versions, is the inclusion of phpmyadmin, so you get an environment very much like a web server.

I also use a batch file to fire everything up at once, launching myself into a hyper-productive development mode…in theory. Here’s the batch file:

@echo off
start /d “C:\Program Files\EditPlus 2\” editplus.exe
start /d “C:\MIVAMia\BIN\” Mia.exe
start /d “C:\InstantRails” InstantRails.exe
start /d “C:\Program Files\Mozilla Firefox\” firefox.exe “http://vc3/merchant.mvc|http://127.0.0.1:8000/mysql/|http://vc3/admin.mvc?username=x&password=y”

That Firefox command opens three tabs–store, admin and phpmyadmin. There is an about:config setting you need to change in Firefox if you want those tabs to not overwrite your existing window. Don’t recall it offhand but it may resurface in my memory at some point.

Bret.

2008 …with a vengeance

So far I’ve done pretty well with the new year and haven’t yet signed a check, written a letter, or added code to a module with the wrong year. Dreamhost did. Badly. And it’s a nightmare for them, despite the forthright and somewhat amusing blog. Check out their Um, Whoops! here.

37signals, the Rails people, used this as an example of why it’s a good idea to not kowtow to “flexibility” when developing–don’t add a feature just in case someone needs it.