It sounds like you have JavaScript turned off, because clicking the "Calculate Shipping" button shouldn't cause the page to refresh. That would also explain why the address checkbox isn't working.

The shipping pane will still be a problem since it expects you to have shipping methods of some kind. If all you're selling is magazine subscriptions, I think you can just turn off the Shipping Quote pane in the Checkout Settings. If you sell other things that don't have the cost of shipping built in, things get harder. Basically you will have to rearrange the data so that the subscriptions don't cost anything to ship. Or this might be a good candidate for the setting to allow orders to go through without shipping quotes. I believe that's found in the Shipping Quote Settings.

Sorry, it's not JavaScript being off. It's not, according to the browser settings, and by checking all my web sites and servers that use Javascript.

Also, I checked the UC checkout form in multiple browsers, including Firefox 2, FF3, and IE 7 -- and the same problems exist.

No matter where I check, UC is requiring that I enter Billing info even if I check the box that it's the same as Delivery info.

Separately, I'll experiment with ways to handle the bundled shipping cost problem, but please consider whether UC needs to be modified to handle this -- it's common not only in print subscriptions, but also in ticket sales, many CDs sales, and other products where postage is so inexpensive that it's simpler and more appealing to quote a "delivered" price, and also in a variety of scenarios where the marketer chooses to bundle shipping as a sales tool. So it really is a selling mode that needs to be supported cleanly. If it really can be done now (rather than requiring code mod), it should be documented rather than left to experimentation.

I'll let you know if I find a way to do it (can't use UC without this, and without solving the no-images problem).

-- John

I don't know if there are JS errors, but nothing in my config should have altered your JS that I know of.

Looking at your JavaScript in IE7, I see what likely should be single quotation marks as HTML entity &039; (that's entity value 39, if it gets trashed here). This is happening in the JS line that should populate Billing from Delivery info.

If it should be simply single quotation marks, I don't know where that conversion from character to entity is happening, or how the JS interpreter sees and handles it.

Here's my one test product to see for yourself: http://www.advisor.com/store/filemaker
Add it to the cart, then see how the checkout page works (or not)...

Separately -- on the shipping cost challenge, on the Shipping Quotes admin page I see something called "Shipping types" that defaults to "Small package". Thinking maybe this is an element of providing cost-free shipping of magazine subscriptions, I decided to create another Shipping Type option. But searching the store links and docs I can't find any way to control this. What am I overlooking?

Thank you for helping. I really want to ditch Yahoo Store!

-- John

I see that in Firefox, UC's JavaScript file isn't loaded (it seems to load in IE but still doesn't work).

But I don't know what to check or configure in UC or Drupal. It's not a Firefox JavaScript problem, lots of other JS loads from Drupal and my non-Drupal sites/servers. What could possibly prevent UC's JS file from loading with the rest of the checkout form?

I'm still running Drupal 5.7, don't want to make too many changes at once.

Thanks for the suggestion. I checked my main template files (template, node, page, block) and none have "$scripts" in them, not in a print statement or anything else.

If it *should* be there but isn't, that's quite a mystery because I'm either using stock Drupal 5.7 files, or mods are minor and not related to removing anything.

To verify this, I just checked the originals that I preserved and didn't find $scripts in them either.

Continuing to investigate, I checked the equivalent Drupal 5.8 files and sure enough, they have the line

So, I just added it to my page.tpl.php. And (drumroll) that seems to fix UC's cart problems!

But, other than this I have not found any problems that led me to even investigate Drupal's loading of .js files. Maybe I'll discover some new behavior...

This just deepens the mystery of why it was lacking from my 5.7 (and earlier) template files.

Separately, I hoped this would fix the ImageMagick problem but it didn't, so that's still a mystery.

Back in the shopping cart, I now need to determine how to charge California sales tax on some products (CDs) but not others (magazine subscription).

>> Each tax has a setting that determines which product classes will be charged.

I see this, and already created suitable tax classes.

But I don't see how to assign a product to a product class. It's not a field on the page (or its subpages) that defines my product (subscription). Where else should I look for it?

Got it -- UC "product class" is essentially Drupal "content type".

I created a new type for publication subscriptions, and set sales tax to NOT be applied to this type -- and it works. Thanks.

I'm still stuck on ImageMagick telling me it can't find an image that is right where it claims to be looking. It's happening the same in the new product type as with the old. Any suggestions for that?

I'm using ImageCache 2.1, which was already on my system before adding UC. I read that downgrading to 1.5 is essentially impossible.

Also, my problem isn't similar to the reported 1.6 errors. My problem is that ImageMagick reports it can't find the original image file, yet it says it is looking for the file at a path and filename that exist and are correct. So apparently either the error message is wrong, or it's not really looking where it says it is. With so many pieces in the chain I don't know which might be the culprit.

The only "fix" I can discover is to switch from ImageMagick back to the GD library, which works.

But -- my product now shows TWO images, yet the product form only has one image field on it.

I can control one of the two displayed images, the one that might be what you call CCK image, in 3 ways via these pages:

/admin/content/types/pubsub/fields lets me position it vertically on the product's page via Weight.

/admin/content/types/pubsub/fields/field_image_cache lets me control where the image file is stored and a few other things I'm not using.

/admin/content/types/pubsub/display lets me control which version of the image is displayed -- only Default seems to show it in the size I desire, the original image size I uploaded.

From experimentation, it seems the above three forms control the same image.

I can control the "duplicate" image via this: /admin/store/settings/products/edit/fields

This one seems to be UC's Product image. But it's smallish compared with the other one. Can I control the size of this one?