Product kits inconsistent when order created by admin

Marked #389818: Product Kits, Attributes and Manual Orders as duplicate.

That issue notes that product attributes don't work when adding a product kit to an order as well.

Hax... There's no better way to work with this API, I reckon.

Yeah, I guess the skip_save hack is what needs to happen to make that work. What I don't understand is what uc_product_kit_form_uc_order_add_product_form_alter() is doing. Maybe I'm just not seeing it, but I can't find a reason to add $form['products'] to that form.

Please add PHPDoc comments to any new functions in patches, even if it's just "Implementation of hook_order_product_alter()." I've got a patch that fixes them on all the old functions, so I don't want to have to search through the code again. :)

Rerolled.

Sorry, last patch had some stillborn code left in.

To get drupal_write_record() to work, I had to write #487882: hook_schema() should mark certain columns to be serialized. When you apply the patch, don't forget to clear you cache.

On the view order page, the product kit's components look like they have the right attributes and options, but only the ids are being displayed. The titles are dereferenced in ordered products in case the attributes and options are changed after the order is completed.

Tagged.

Adding the products key to that form is what causes uc_attribute to alter it. That makes sense.

However, with the advent of hook_uc_form_alter(), this makes altering uc_order_add_product_form() much more difficult. I think I've worked around this by implementing hook_uc_form_alter() in uc_product_kit, and deferring the uc_attribute alter until Drupal's hook_form_alter(). But then there was another snag. uc_order_edit_products() works off the $_POST data, which includes the already existing products in $_POST['products'], despite the fact that it's in a different form. (This is probably a good thing to test in multiple browsers. I don't feel confident that this is standard behavior.) To get around this, uc_attribute_form_alter() duplicates uc_attribute_uc_form_alter() and puts the changes into 'sub_products'.

Again, without dpm().

OK, it works in Chrome, Firefox, and IE 8. Handling POST data is pretty uniform, I think, so I probably didn't need to worry about that. Committed.