Simple free shipping module/method?

http://www.ubercart.org/faq/2942

EDIT: The above link is outdated and applies mainly to the Drupal 5 version of Ubercart. Updated documentation can now be found at http://drupal.org/node/1326736

As this is a FAQ and it's not obvious, we could add a very simple "Free shipping" module (or quote method directly in uc_quote) that users can simply enable and add conditions as needed.

Something like that should be a contributed module. But I think it's not very useful. Free shipping all the time requires no conditions and no special module. Free shipping under some conditions requires you to configure Rules. You will have to do that whether you have a special module or not - the only difference *might* be that with a special module you might be able to configure one and only one condition, whereas with just Ubercart core you have to configure two (one for the "free shipping" case, one for the "not free" case.).

I personally feel this is a documentation matter, and no code change is needed. The existing FAQ is for D6, and not very findable - if we could move these FAQs to drupal.org and update them for D7 like is being done for the rest of the documentation then I think providing a pointer to the FAQ should be sufficient.

@rockwright: The patch doesn't provide anything you can't do simply already. It just creates a $0 flatrate.

I've moved the documentation to http://drupal.org/node/1326736 and updated it for Drupal 7 with screenshots. I also updated the documentation for Drupal 6 and removed the Drupal 5 stuff. I think it could still use some work, but I think this should be the basis of any help we provide for setting up free shipping. It also serves as a concrete example of how to use Rules for shipping, which is where I think the primary confusion is.

So back to #3:

Something like that should be a contributed module. But I think it's not very useful. Free shipping all the time requires no conditions and no special module. Free shipping under some conditions requires you to configure Rules. You will have to do that whether you have a special module or not - the only difference *might* be that with a special module you might be able to configure one and only one condition, whereas with just Ubercart core you have to configure two (one for the "free shipping" case, one for the "not free" case.).

All this patch does is create one $0 rate. As I said above, that requires no conditions and no special code - it's just a $0 flat rate. If that is going to be done, I would much rather have this be a pre-defined uc_flatrate method, so that we can have multiple free shipping methods based on different conditions (although, it will still be strange to turn on "Free shipping" for the first free shipping, then have to define a $0 rate for the second free shipping...). I don't think this belongs in uc_quote - it needs to be its own module or be part of uc_flatrate. Otherwise, this "free shipping" method will behave differently than all other shipping modules. Currently, to add a shipping method, you enable a module then go to admin/store/settings/quotes/methods and create or turn on all the methods you want to use. I would prefer to have this procedure be the same for *all* shipping methods, so we don't have to riddle the documentation with "except if" clauses. Currently, when there are no shipping methods showing up at admin/store/settings/quotes/methods, the user should think "Why don't I see any shipping methods?" and quickly conclude that's because there are no shipping modules enabled - this is something the user can figure out without asking. When "Free shipping" but nothing else shows up, the user sees that *something* works, and wonders why there are no other options - that will result in a support request because it is anomalous behavior.

(EDIT: I think the UI could still benefit from a short description at the top of the admin/store/settings/quotes page, like I promised to do in http://drupal.org/node/1307900#comment-5124876. I'll try to get that in today.)

I don't see that the patch addresses any of the issues that people have with setting up free shipping. The problem is not that they can't figure out how to define a $0 flat rate. It's that they have a conceptual problem with how Rules works to apply conditions to the quote, or a conceptual problem when dealing with the Boolean logic of the Rules conditions. The most common problems I see are 1) "Data comparison" is not the obvious choice, 2) people don't realize that when they put a condition on the $0 rate, they have to invert that condition for the *non-free* methods they're using, and 3) people use OR when they mean AND. This patch doesn't do anything to address what is essentially a documentation problem of teaching people how to use Rules in the context of shipping quotes. You're still going to get questions like the one in the original post with this patch in place.

I think the best course of action is to continue to improve the documentation I started in #7.

Why would you need a second "free shipping"? Wouldn't you just add conditions to the single free shipping method? Perhaps we should allow shipping condition sets to be OR as well as AND to make this easier? One minor advantage of this single free shipping method is that it doesn't add per-product rate fields to the product edit page like flatrate does - for many users the per-product rate for "free shipping" will always be $0 (edit: perhaps we could add options to each flatrate/weightquote to hide the per-product rate fields if they will not be used?)

And for improving admin workflow, what do you think about #1317910: Split tax and shipping conditions out into their own pages and #1313684: Add Rules conditions for multiple country comparison - and maybe other simple conditions so people don't have to use "Data comparison"?

... which begs the question, what happens for orders *below* that [user enters amount here] ? You still have to set that up and make sure that gets applied only when the order total is below that amount. Which involves "all this jazz", especially if you want to do something other than a fixed shipping charge for orders below your total (say you want to charge actual UPS shipping cost...) So even in your simple, very narrow use case, you need to understand what you want to accomplish and know how to use the provided tools to accomplish it.

Charging a fixed shipping charge below a cutoff and free shipping above the cutoff is something that's not nearly general enough to satisfy more than a small fraction of users. An improvement on that would be to let you specify different flat rate shipping charges (one of which happens to be $0) for different *ranges* of order total. That's a more complicated task - it needs a UI to define the price bands (not just "free" and "non-free", but any number of bands) and a way to override each band separately for each product sold. And again, this only satisfies some fraction of users (and is a pretty horrible system in practice - I've used this before and you always end up charging the customer too much or too little).

Now, what happens when you want to specify free shipping only for "premium" members (members who have purchased some special role, for instance). Or free shipping only for some products? Or free shipping when you buy 5 or more items? Or free shipping within a certain distance from the store. Or free shipping for a week before Christmas. Or ... There are literally hundreds of use cases. We can't possibly build in special functionality for each of these, but what we can do and what we have done is build a generalized system which CAN do everything without any great effort. ALL of these unlimited use cases could be made easier by a dedicated module, and that's how they should be done - as separate contributed modules. We already have a number of these for Drupal 6 (for example, the price band module described above exists already). If someone thinks one of these is important enough to spend some effort on, they'll port it to Drupal 7. If not, that's pretty good proof it's not generally useful.

Frankly, I think it's much easier and more effective to document a number of these use cases with tutorials than it is to try to write and maintain dedicated modules for each of these minor use cases. Only a small fraction of the Ubercart community can/will write and maintain a module for the community, but a much larger fraction is willing/able to document the process - documentation is thus a much better means of encapsulating and transmitting knowledge about configuring shipping.

That's what I've started at http://drupal.org/node/1326736. That document can be edited by *anyone* in the community, and you can add your own pages with your own use cases. So if you think your special shipping needs are something that others would be interested in, I suggest the first step is documenting how to do it so the next person, or the "admin lady", will find it simpler to do.

@longwave (#9): Yes, you're right, a second method wouldn't be needed, just an OR condition, and that already exists.

One minor advantage of this single free shipping method is that it doesn't add per-product rate fields to the product edit page like flatrate does - for many users the per-product rate for "free shipping" will always be $0

Actually, I count that as a minor *dis*advantage. In practice, *everyone* has exceptions - there will *always* be certain products that the store owner doesn't want free shipping to apply to (too large, too heavy, too valuable - things that cost a disproportionate amount to ship).

A flat rate of $0 on all orders is not useful. The point I started with above is that there has to be at least one other non-free shipping method. (Otherwise, all you would have to do is turn off shipping entirely - no need to mess with a "free shipping" shipping method.) And once you introduce a second shipping method, you need to apply a condition to BOTH your free method AND the second method, specifying the conditions under which to apply one or the other. So I don't see any way to avoid learning how to do elementary things with the Rules UI, with or without the patch.

OK, I'm sold on not committing this, but I still think we can improve the admin workflow by splitting "edit quote settings" and "edit conditions", and adding some conditions that duplicate "Data comparison" but are more obvious to new users for specific common use cases.

..though I might still upload this as a contrib and see how much use it gets, if any!