yab_shop (simple textpattern shop with paypal support)

tom1 · 2012-01-31 21:05:31

Well theres a lot to digest, i’ll get back to topic after good nights sleep

Bloke wrote:

I’ve not done multiple promo codes yet. Not rocket science, and I have a version (somewhere) that has discount tiers in it based on a customer’s ‘status’ (e.g. a Gold partner might receive a better discount than a Silver partner). I could try and fold one or both of those in at some point if it’s helpful.

I was reading around the forum and noticed your smd_access_keys. Couldn’t unique promo codes work just like access keys. Only that instead of hashing and crypting the string, it could be 5-9 characters long readable data. processing Checkout data could check if key / code is valid and not let customer continue if it is not. I might be missing something here, but concept sounds so alike.

I was also mulling over the idea of price breaks recently after I was contacted by someone who wanted them. It’s a great idea but I’ve not got my head round the best way to configure them, since it could be on a per-product basis (implies the breaks go in a custom field) or you could get a price break on total order value (e.g. 10% off if you order over $100; $25% off with orders over $500; free car with orders over $10000; etc). Or maybe both types at once(?), which gets very confusing. We already have “free shipping at $N” so that part of it is covered. Ideas on this welcome.

What you think about seperating all variable costs into own set of pricing rules. If it wasn’t this late, i could think this well thru before posting but now i just have to share my mindflow :)

For price breaks, new pricing rule could take following arguments:

Comparsion unit ( options Cart total price, Cart total weight, Cart total shipping, product, product attribute (weight, size, any), product category, shipping country / state )
< / = / >
value to compare ‘Comparsion field’ value
price change ( -20%, -10$, +20€ )

this would lead us to make rules like these for example

CART total price > 50 -10%
Product( id or name) color = RED +2€
Cart total shipping > 100€ -100%

This could help out figuring shpping by weight aswell, because you could make few rules to apply on weights: Cart total weight > 1kg 10€

Ofcourse i have no idea yet how this could be implemented into current code, but i hope you get the point.

Bloke · 2012-01-31 22:03:18

tom1 wrote:

Couldn’t unique promo codes work just like access keys.

Kind of, but yab_shop doesn’t work that way (ummm, I don’t think at least). I’m going to be diving into promo code land tomorrow on the shop site I’ve set up so I’ll know more then. Off the top of my head, the simplest way to go (if not the most elegant) might be to allow a comma-separated list of promo codes and a comma-separated list of percentage discounts to apply, on a one-to-one mapping basis. e.g.

Promo code(s): SUPER20, HOLIDAY2012, EARLYBIRD1
Discount percentage(s): 20, 25, 15

If the promo code logic took that into account then I think it’d just work since we could split into an array, find if the code is in the array, grab the index and then take the corresponding discount value. The only extra thing to consider would be to check that only one code can be applied to an order so once a code is used, that’s it for the order. If we’re lucky, the cart logic probably caters for that already since only one code can be applied to the cart contents. If someone was to apply another one, it’d replace the previous one so only one could be in effect at any time. The cart grand total is updated each time a code is entered and the discount is applied on the real prices from the custom fields of the items bought… I think. Will check that.

Longer term that’s probably not going to cut it because peope are getting inventive with coupons these days. e.g. THREE-FOR-TWO or TEN-DOLLARS-OFF etc. Being limited to just percentage knockdowns seems to be missing a trick, so if we can factor in some greater flexibility it’d be cool.

That takes care of generic promos, but some promocodes are unique for a customer. Is that something worth pursuing (in the vein of smd_access_keys, but with more readable, shorter keys)? I don’t know. Conceivably we could generate a two-way hash of some known unique, secret data linked to a customer’s account, apply that to a known promocode with a defined outcome, then send the scrambled version. Upon reception of the key we could reverse the process, obtain the unencoded promo code and apply it. Not foolproof, but maybe good enough. Does that offer any benefit? Probably not, since you might as well just publish the generic code. And it does imply having user accounts, which is a further hurdle so perhaps this idea is best left to another plugin, or as a bolt-on module for someone else to worry about.

A curve ball idea is simply to not do anything except add a callback to the promo code add function. Then each time someone enters a promocode some third party plugin could be called and it’s down to that app to interpret the passed code and return some discount (value, percentage, whatever) to be applied.

I think longer term the whole plugin could be refactored like this: just a state machine with a series of callbacks. The plugin uses its own callbacks to offer base cart functionality and it’s up to plugin developers to write modules that interface with those callbacks to offer more esoteric applications. It’s the Textpattern way™ :-)

Comparsion unit / operator / value / action

I see where you’re going and I like it. Would need some brain power though. More than I have capacity for at this time of night.

This could help out figuring shpping by weight aswell, because you could make few rules to apply on weights: Cart total weight > 1kg 10€

The only sticking point here is that we’d need at least one more parameter: max.

At the moment you can designate a set of weights for different couriers. Some have defined minimum or maximum weights below or above which it’s either not worth using that service, or they refuse to take the package. So if your cart was 2.5Kg it means you might have a choice of courier and the one you choose from the dropdown is the one that represents the best value for the speed of service you require. But if your cart is 25Kg you may be limited to only one courier.

The plugin currently takes care of all that for you by allowing you to tag MAX onto a weight->price combo. If the cart weight is above that value, that particular courier is greyed out.

Given the extra processing involved and also the fact that some countries charge Tax on shipping and some don’t, I’d be tempted to leave shipping separate and just apply break points to product combinations. Does that make sense?

Last edited by Bloke (2012-01-31 22:06:50)

tom1 · 2012-02-02 20:51:35

Whoa, theres a lot to digest. Good points in there, but since its this late again i will try to concentrate only on few for now :)

Bloke wrote:

Longer term that’s probably not going to cut it because peope are getting inventive with coupons these days. e.g. THREE-FOR-TWO or TEN-DOLLARS-OFF etc. Being limited to just percentage knockdowns seems to be missing a trick, so if we can factor in some greater flexibility it’d be cool.

I agree, there should be something more in it. Have to think about different possibilities a merchant could ever come up with, and find similarities in those.. back to this at some point.

A curve ball idea is simply to not do anything except add a callback to the promo code add function. Then each time someone enters a promocode some third party plugin could be called and it’s down to that app to interpret the passed code and return some discount (value, percentage, whatever) to be applied.

I think longer term the whole plugin could be refactored like this: just a state machine with a series of callbacks. The plugin uses its own callbacks to offer base cart functionality and it’s up to plugin developers to write modules that interface with those callbacks to offer more esoteric applications. It’s the Textpattern way™ :-)

I agree with you on the fact, that yab_shop shouldn’t itself concentrate too much on handling promocodes, since it serves the shopping cart functionality.
That being said, how you feel about planning a plugin that handles promocodes? :)

Given the extra processing involved and also the fact that some countries charge Tax on shipping and some don’t, I’d be tempted to leave shipping separate and just apply break points to product combinations. Does that make sense?

damn, didn’t even think about tax issue on shipping costs. Maybe it would be better to leave that out of discounting thingies, as it maybe more about delivery method anyways.

tom1 · 2012-02-02 20:53:50

hah just realized i didnt really say a word on that post. Luckily its weekend starts tomorrow, and work shouldn’t bother my freetime :)

Bloke · 2012-02-02 21:01:33

I took a look at the code yesterday and building in support for multi promo codes isn’t hard. Takes a bit of refactoring of the cart to actually stash the code being used instead of just stashing a 1 (= “promo code in use”). That’s necessary so the code can be looked up when it comes to applying the discount value to each product.

And on that note I found a handy hint by trenc in the plugin help that might explain why only percentage knockdowns are permitted:

Absolute discounts like 5€ on all products are not supported due the lack of support by paypal and google checkout.

So that explains that one :-)

Angelic Relic · 2012-02-03 06:39:15

Thank You * * * Thank You * * * Thank You Manaus
This has been driving me nuts
Your solution is perfect
Thanks again…………………

Manaus wrote:

Men I just managed to get it right: just put the checkout tag within the shop_cart tag, like this:

<txp:yab_shop_cart>
  <txp:yab_shop_checkout />
</txp:yab_shop_cart>

Cheers

tom1 · 2012-02-03 09:02:08

Bloke wrote:

Absolute discounts like 5€ on all products are not supported due the lack of support by paypal and google checkout.
So that explains that one :-)

Why should payment aggretator even know how total price is made up? Isnt total price to pay and return url usually enough, or does Paypal handle shopping cart contents aswell nowdays?

Bloke · 2012-02-03 14:20:09

tom1 wrote:

Isnt total price to pay and return url usually enough, or does Paypal handle shopping cart contents aswell nowdays?

It does indeed. It itemises stuff on the invoice and takes a whole cart as input.

uli · 2012-02-03 14:57:50

Bloke wrote:

It itemises stuff on the invoice and takes a whole cart as input.

One more nose poking where it doesn’t belong :-/

Bloke · 2012-02-06 14:12:30

uli wrote:

One more nose poking where it doesn’t belong :-/

Yeah, or a “fraud prevention/detection mechanism” depending on which side of the fence you stand.

Incidentally, I added rudimentary multi-promo code support. You can list the promocodes from the yab_shop prefs, supplying an equal number of discount percentages in the box beneath: first code maps to first discount % value, 2nd code maps to 2nd discount value, and so forth. Handy.

hidalgo · 2012-02-07 03:05:09

Hi Stef, multi-promo code support is something I could most definitely use, even if it’s just rudimentary!

Ultimately, it would be great if promo codes could have their own extension tab so that users with less privileges could manage them separately from the core preferences.

I’m really glad that there’s talk of reviving/expanding this great plugin.

Last edited by hidalgo (2012-02-07 03:16:36)

progre55 · 2012-02-07 16:24:53

maniqui/bloke (or anyone else)

Still hoping to find an answer for this question —-

(1) I need to add a dropdown box to the form. I have modified the form before — but only by adding new input fields —-

Thanks.

progre55

Textpattern CMS

Textpattern CMS support forum

#637 2012-01-31 21:05:31

Re: yab_shop (simple textpattern shop with paypal support)

#638 2012-01-31 22:03:18

Re: yab_shop (simple textpattern shop with paypal support)

#639 2012-02-02 20:51:35

Re: yab_shop (simple textpattern shop with paypal support)

#640 2012-02-02 20:53:50

Re: yab_shop (simple textpattern shop with paypal support)

#641 2012-02-02 21:01:33

Re: yab_shop (simple textpattern shop with paypal support)

#642 2012-02-03 06:39:15

Re: yab_shop (simple textpattern shop with paypal support)

#643 2012-02-03 09:02:08

Re: yab_shop (simple textpattern shop with paypal support)

#644 2012-02-03 14:20:09

Re: yab_shop (simple textpattern shop with paypal support)

#645 2012-02-03 14:57:50

Re: yab_shop (simple textpattern shop with paypal support)

#646 2012-02-06 14:12:30

Re: yab_shop (simple textpattern shop with paypal support)

#647 2012-02-07 03:05:09

Re: yab_shop (simple textpattern shop with paypal support)

#648 2012-02-07 16:24:53

Re: yab_shop (simple textpattern shop with paypal support)

Board footer