Thanks for this great module. It's quite complex to properly add ad DFP to a Drupal site and the module comes in very handy.
There is no other report about this bug. So I assume it is still in the dev, but I didn't verify that.
The error:
PDOException: SQLSTATE[22001]: String data, right truncated: 1406 Data too long for column 'delta' at row 1: INSERT INTO {block} (module, delta, theme, status, weight, region, pages, cache) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7);
[...]
db_insert_placeholder_1 is 34 characters long. I follow the naming guide of DFP, which is recommended in an official tutorial video at YouTube: sitename_category_adformat_dimensions
The error occurs when opening /admin/structure/block. Are the blocks created first when opening the blocks listing? Seems so. It breaks the blocks listing for admins.
It's a common situation, because many modules (e.g. Panels) don't check for the length restrictions of the db when creating blocks. A quick fix for users would be to change the machine_name maximum length at db level.
Another quick solution: disable the block feature in Ad tag configuration. I'm lucky blocks were just a 'nice to have' feature for me. Unchecking "Create a block for this ad tag" helps (verified!).
I suggest to create the DFP blocks not when showing the administrative blocks listing, but when saving the Ad tag. This kind of errors would raise in place then and it would be easier to identify their origin.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | 1705400.patch | 1.48 KB | bleen |
| #4 | 1677548.patch | 1.36 KB | bleen |
| #3 | 1677548.patch | 1.36 KB | bleen |
Comments
Comment #1
bleen commentedhrmmm ... I know that views solved this issue by using an MD5 hash of the block name as the delta but thats sooooo ugly. Let me marinate on this for a bit...
Comment #2
Anonymous (not verified) commentedYou're right.
Actually, when porting all this to the production site, I first noticed the option to define a machine names by myself. It's easily overlooked when first faced with all those options and names and IDs. Setting it manually is however no way to deal with cloned ad tags: they name after the original and can't be renamed, can they?
A good solution may be to truncate the machine name and add a number, but I'm not aware, if there are implementation pitfalls.
Comment #3
bleen commentedThis follows the example used by views ... would you mind talking a look...
Comment #4
bleen commentedfixed a syntax error
Comment #5
bleen commentedI went ahead and committed a modified version of the patch in #4 after some more testing.