Adding a new tax rate with a long name causes a PDO exception to be thrown on save. This leaves the tax in the listing at admin/commerce/config/taxes without options to edit/configure/delete.
To reproduce:
My guess is that it's related to the machine name that is auto-generated from the human-readable title. The machine name auto-generation script likely needs a length cutoff so the machine name fits in the database table.
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | commerce-long_tax_rate_name_causes_pdo_exception-1877552-1.patch | 1015 bytes | chrisolof |
Comments
Comment #1
chrisolofThe exception: PDOException: SQLSTATE[22001]: String data, right truncated: 1406 Data too long for column 'name' at row 1: INSERT INTO {rules_config} (name, label, plugin, weight, status, module, data) ...
Here's what appears to be happening:
1) "Scientific and Cultural Facilities District Sales Tax" converts to a machine name of "scientific_and_cultural_facilities_district_sales_tax," which is 53 characters in length. This passes form validation because the machine name field specifies a #maxlength of 64.
2) The tax rate is saved into the {commerce_tax_rate} table with success. The "name" field here is a varchar(64) so the 53 character name fits.
3) Then a record gets written to the {rules_config} table regarding this new tax rate. The "name" field here, also a varchar(64), gets populated with the machine name prefixed by "commerce_tax_rate_" turning what was once a 53-character name into a 71-character name, which is too big to fit into the 64-character {rules_config} "name" column, resulting in a PDO exception.
I think we need to account for that 18-character addition and limit the tax rate machine name to 46 characters in length. The attached patch against 7.x-1.x does just that.
Comment #2
rszrama commentedWorks for me, and apparently the machine_name element will validate itself to ensure you don't have a duplicate. No need to have an update function for this, since it basically wouldn't have worked for anyone before. I've also added notes in the .api.php file pertaining to the length of tax type and tax rate names, as the same issue applies to tax types and tax types / rates defined via modules.