When you set the $form['shipping']['#access'] to false and then you try to save the node (once or few times), it will record a data with empty shipping_type on the uc_quote_shipping_types table which I think it should not record anything.
and I think it will fix the following error I encountered before:
INSERT INTO
{uc_quote_shipping_types}
(id_type, id, shipping_type) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2); Array
(
[:db_insert_placeholder_0] => product
[:db_insert_placeholder_1] => 136
[:db_insert_placeholder_2] =>
)
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | 2899191-empty-shipping-type-1.patch | 567 bytes | slawira |
Comments
Comment #2
slawira commentedComment #3
tr commentedThis is not a bug in Ubercart - it is YOU who changed the code so that the shipping type form element is removed from the submission. You encounter an error because YOU did not also ensure that the default value of that element would be valid when you did this - the shipping_type column should always be a string, NULL is not allowed as per the schema. That's one reason we check against '' instead of using empty().
I don't see any benefit from changing this, and it might affect (break) existing code from contributed modules. Data typing in PHP and Drupal 7 is non-existent, but Drupal 8 provides a type layer that helps a lot by allowing type declarations / initialization on entity fields like this. But in D7 we have to make our own rules to ensure typing and for shipping_type we've chosen to always treat it as a string.