Congratulations and thanks for all of the hard work.

I can now tell my boss we are going live with our new e-commerce site using a shopping cart that is in beta and not alpha!

I think my uc_addresses module should be considered for the beta to-do list. I still need to finish a few things and normalize the data by creating a "names" table, but I have to finish rolling out our new ERP system first. Are you interested in including this feature in core or should I create hooks to override the check out forms?

The only usability issue I've really come into contact with is the degradation of Javascript in the shopping cart (fetching quotes and displaying the payment method, especially).. but if people don't have JS enabled that's their own fault

Other than that, I have my own uc_file_retro contrib to add for Beta, since Shawn took that function out of the uc_file module in anticipation - so I'll try to finish that out this weekend for you guys.

Congrats on going Beta! (Can I have an Early Adopter badge?)

torgosPizza wrote:

The only usability issue I've really come into contact with is the degradation of Javascript in the shopping cart (fetching quotes and displaying the payment method, especially).. but if people don't have JS enabled that's their own fault

I wrote a module that simply changed the shopping cart checkout link to go to a 'how to enable javascript' page if javascript is disabled. If javascript is enabled then javascript sends the user, via the click of the button, to the checkout. It's a very simple workaround to this issue.

As far as the /cart checkout button, I used form_alter() include a hidden field with a simple value of '0', then if javascript is enabled it will change the value to '1'. Also using form_alter() I changed the submit function to a copy of the submit function that depending on the value of the hidden field would redirect to either the checkout page (hidden field value of 1) or the enable javascript help page (hidden field value of 0).

The only issue I had in doing this was in the Ubercart's own cart theme function, it specifies the exact form fields to print. The problem with this is my hidden field that is added via form_alter() did not get printed. This issue can be found with a patch here

I would like to see the patch to the theme_uc_cart_view_form() be added as is or some variation there of for beta, as well as at least the simple javascript degradation as I have mentioned above. If any one has need of my custom module for the javascript degradation, let me know.

I've only just started using Ubercart (read about my development @ http://www.ubercart.org/forum/ideas_and_suggestions/2434/mp3_shop_downlo...) but i really enjoy using it. Big thumbs up for going to beta, i look forward to finding/squashing bugs and getting 1.0 ready to roll with you all.

My respects to you and everyone who was involved with ubercart. I must say I wish I was there at least to give a contribution.

Hats off to you guys.

Ad

Hi Ryan,

I like to see you take a closer look at workflow_ng in beta. I'm not convinced its ready for prime time yet. The conditionals are a little flaky, some times it works, and sometines it doesn't, especially in the shipping module. The conditional menus have been inproved and look good, but the code behind the conditionals has not been fully tested. I know I had some problems that I posted that were never resolved.

Other than that, I think the core is running great and its time for Beta.
Thanks, for a great shopping cart.

That really depends on the taxing jurisdiction. In my state (WA), by law, for orders shipped or delivered to in-state addresses retailers must collect local sales tax based on the jurisdiction from which a product is shipped or delivered - "origin-based". This is nice and simple - I know my store's tax rate and I just have to apply it to in-state orders.

Starting 7/1/08, we will need to collect taxes based on the destination of the shipment or delivery - "destination-based"; this will be very disruptive to business because tax rates vary from county to county, city to city, block to block - there are even "regional" taxing authorities. The boundaries of these different taxing zones do not correspond to anything simple like ZIP code - you have to look up each individual destination address in a huge table to determine the exact rate for that address!

About half the states currently use destination-based shipping. I don't know of any case where the billing address is relevant to the tax calculation - tax is based on either where there item is "picked up" or where it is "delivered to".

And of course, other countries have their own rules. The best Ubercart can hope to do is make the architecture flexible enough to accommodate all these variations.

Hey Ryan,

I know this one has been on the to-do list for awhile, but I would like to once again voice support for a way to handle check out if the customer's balance is $0 (such as if they used a coupon or "bought" a free product).

Many of the websites I work with use free giveaways or "loss leader" products to draw in potential customers (who they can then market to later). With the ability to change a user's role upon purchase now in Ubercart core, this feature is especially needed so that a store can offer something like a free "7 day trial membership" (which upgrades a user's role for a short amount of time).

I'm hoping this can make the beta cycle. I view being able to accept a $0 balance total (without requiring a credit card number) as quite important.

Thanks,
Ben

I'm trying to keep things as light as possible as we move into beta in terms of adding more code. Speaking for the core team, we haven't been good about consistently fixing known bugs before adding new code, so I'd like to make that a focus in future releases. Boiling down the items mentioned above, I came up with the following document that will probably serve as an initial roadmap for beta development:

Things to keep an eye on: (not necessarily bugs, but might be)

• Installation process
• Shipping quotes
• Workflow-ng conditions and default configurations
• Anonymous checkout and user account creation
• PostgreSQL support
• Make sure reports are being generated correctly

Known bugs to iron out:

• Supporting a required zone field when a country has no zones
• Allow items to be added to the cart view form
• Creating new accounts for redirected payment methods
• Caching bugs for anonymous users (like the cart block)

Features still in the works:

• Recurring fee support
• Review and include more Views integration
• Adding encryption to CC numbers in the database

Items in need of some contributed love: (best served up as modules or patches for review as we can't seem to find the time to get to these)

• Support for $0 order total checkout
• Address/profile integration
• Support for non-JS users (I like that idea about instructing users how to turn on JS for a contrib module)
• Attribute enhancements, specifically images per attribute and dependent attributes
• Product kit enhancements

I'm probably missing stuff here, but that's why we have an issue tracker (or two). For the time being we have opened up the Drupal.org issue tracker to specifically handle bug reports/patches (no feature or support requests, please).

I'd like to request checking all javascript files for missing ';'. Ones I have found and possibly all that are missing:

• uc_quote.js
  • Line 24
  • Line 55
  • Line 66

Hi Ryan, I've got one thought that might be some kind useful. What do you think about adding additional field to checkout panes which would serve like additional question or sth like that with a possibility of requirement or not.
For example most shops in Poland has a checkbox field just before "send order" button which states that you read shop regulations and you agree with them.
Other thought: You can "ask" by such a field if a customer by any chance agree to get a weekly newsletter or sth like that.
I haven't found this functionality neither in uc core or in contributions. (if I missed sth please forgive me
What do you think about that?

greets from Poland