#1 is something that I'd like to see built into core - the ability to "require" attribute selection in the order page. Right now I think you'd have to write a small custom module and invoke hook_form_alter() to require those fields. You can see an example of how it's done in the Gift certificate Contribution. It would simply be adding '#required' => TRUE), to that form's particular element.

#2 is probably a Javascript addition, I'd looking to jQuery to do your bidding. You'd have to make calls to onChange and whatnot, no need to specific since jQuery can traverse down the DOM using the elements' IDs. (Sorry if this is all babble to you, you'll understand eventually

#3 - Using hook_form_alter, set the attribute '#maxlength' => 25 or whatever # of chars you want to restrict to.

#4- Again, using hook_form_alter (sensing a pattern yet? ), you can add '#weight' => 10 or some higher number to sink the element you want towards the bottom. Although for styling your add to cart form (and not affecting its functionality such as the above issues) you could put the Submit form pretty much wherever you want. (On my site, I've gotten rid of it entirely - except for when an attribute is selected - and made it into a button.)

The main issue is Contemplate doesn't interact with the Forms API, so you can't change how the form gets rendered, you can only affect its output - and then interact with the data that it's giving you. In other words I could spit out a list of "Other Products in this Vocabulary" but I couldn't say "make all fields required". Does this make sense?

Sorry if some of this is over your head. Definitely start looking through the Contribs, they will help a lot, and also the drupal.org site. I would also recommend Pro Drupal Development by Matt Westgate and John VanDyk. The book is worth its weight in gold. (And the community here rocks as well!)

There are a couple ways you could do it, probably the easiest method without writing a custom hook or a bunch of conditionals, is to create a Product Class. That'll allow you to create templates for each class .. if I'm remembering correctly. Pretty sure the answer is yes, though

EDIT: Now I remember. In your store product settings you can choose node types to assign as a product; so one trick would be to create a node type for whatever product you want to look differently and then create a new template for that product.

I know there are a couple other ways to do it that involve a bit more time and code but, this should steer you in the right direction.

Ryan, would you consider a patch for adding 'required' to attributes? This would add a Required checkbox under the Order field on the Manage Attributes screen which would then show as the default in a checkbox next to Remove on the Edit Attributes screen of a product. That might sound a bit confusing, but I think that would work out.

I pictured it working with the default option still being recognized but in the absence of a default option a "Please select..." line would be added as the default. And in the case of an attribute with no options the text field would work like any other required field.

This would essentially mean that using a default option and making an attribute required would serve very little purpose as it wouldn't be easily possible for them to unselect an option on that field. So perhaps setting up an attribute as required would eliminate the ability to set a default option or would simply ignore it and place a message on the admin side stating that default options are ignored for required attributes...and then it would behave as stated above in the absence of a default option.

Well...here is a small diff that adds required attributes.

First off, update.php will need run since the install file adds a new field, 'required', to the uc_product_attributes table.

The changes will add a 'Required' checkbox on an individual product's attribute settings page. I decided to make this product specific, although a checkbox could be added to the general Attribute settings page and the product could inherit that by default in the same way that Attribute prices/costs/etc. work.

A product's attribute with options still requires a default option even if the attribute is required, but on the attribute settings page the Default Option will show as n/a, the same as it does for an attribute with no options. (this could be changed to ignored, ignored when required, or anything like that).

On the cart page, required attributes will be set to '#required' => true and in the case of attributes with options, a select box will show with a default first option as 'Please select an option'

The patch also does whitespace trimming that Komodo does automatically which explains a large part of the diff file. It should apply fine to the latest Bazaar code.

If anyone wants to test that out I think it might be a decent start towards having Required Attributes. Lyle, I guess that is directed mostly at you to see if you want to consider adding this sort of functionality to core.

Cool stuff. Not sure about other attribute related modules, but I know at least the Ajax Calculated Field module will need updated to account for this extra option potentially showing up on attributes now. So if things break...that is probably the culprit.

Actually, I'm reviewing the AJAX attribute calc functionality right now and it looks like it is behaving the way I'd want it to. When the page first loads for a required attribute it will show 'Please select an option' but then once an option is selected and the select box is re-created this option has no reason to show up. KillerJerseys, can you describe what you mean by