Posted by tormu on December 1, 2009 at 1:34pm
20 followers
| Project: | Panels |
| Version: | 7.x-3.3 |
| Component: | Mini panels |
| Category: | bug report |
| Priority: | major |
| Assigned: | merlinofchaos |
| Status: | closed (fixed) |
Issue Summary
When going to /admin/build/block I get following SQL error:
user warning: Data too long for column 'delta' at row 1 query: INSERT INTO blocks (module, delta, theme, status, weight, region, custom, throttle, visibility, pages, title, cache) VALUES ('panels_mini', 'over_32_characters_here_causes_this_error', 'my_theme', 0, 0, '', 0, 0, 0, '', '', 1)
panels_mini_block() seems to create the block delta based on the mini panel name. However, there seems to be no validation for the name, so the user can type names exceeding the 32 character limit that is set by the database schema.
Comments
#1
Checked in a max length value on the name property. Thanks for the report!
#2
Automatically closed -- issue fixed for 2 weeks with no activity.
#3
This happened today with D7. The mini panel name column in the DB is set to 255, but block delta is only 32. Happened after cloning a clone of a clone.
#4
Using Drupal 7.4 & Panels 7.x-3.0-alpha3 on CentoOS 5 and Apache 2.2.3. Received the following error when attempting to clear the cash using drush:
WD php: PDOException: SQLSTATE[22001]: String data, right truncated: 1406 Data too [error]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); Array
(
[:db_insert_placeholder_0] => panels_mini
[:db_insert_placeholder_1] => vetrinary_compounding_megameu_content
[:db_insert_placeholder_2] => bartik
[:db_insert_placeholder_3] => 0
[:db_insert_placeholder_4] => 0
[:db_insert_placeholder_5] => -1
[:db_insert_placeholder_6] =>
[:db_insert_placeholder_7] => -1
)
in drupal_write_record() (line 6859 of /var/www/html/includes/common.inc).
WD php: Warning: Cannot modify header information - headers already sent by (output [warning]
started at /usr/local/lib/drush/includes/drush.inc:922) in drupal_send_headers()
(line 1039 of /var/www/html/includes/bootstrap.inc).
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); Array
(
[:db_insert_placeholder_0] => panels_mini
[:db_insert_placeholder_1] => vetrinary_compounding_megameu_content
[:db_insert_placeholder_2] => bartik
[:db_insert_placeholder_3] => 0
[:db_insert_placeholder_4] => 0
[:db_insert_placeholder_5] => -1
[:db_insert_placeholder_6] =>
[:db_insert_placeholder_7] => -1
)
in drupal_write_record() (line 6859 of /var/www/html/includes/common.inc).
Drush command terminated abnormally due to an unrecoverable error.
Deleted and recreated the mini panel with a shorter machine name (i.e. - 'delta') as a workaround.
#5
I also had this issue today - I increased the length of the column in the block table as a temporary work around.
#6
I've also encountered the fatal PDO error: String data, right truncated: 1406 Data too long for column 'delta' at row 1
When I clear the cache and I have a mini-panel with a machine name that's longer than 32 characters.
I was able to recover from it by cloning the offending mini-panel and setting the clone to have a shorter machie name, then deleting the original one with the long name.
Seems we're missing that max length index on the machine name, at least for mini-panels in the current alpha!
#7
This is related to #956394: Database column not large enough making it impossible to assign a layout to a panels page, but this time in the opposite direction - allowing minipanels with names longer than 32 varchars will cause problems for the internal Block system.
#8
Thank you for helping me resolve this issue -- it was a problem with a mini panel whose machine name was very very long. Ive recreated it!
#9
Could this not be resolved by not copying the old machine name when cloning - or perhaps enlarging the "edit" text, or maybe its just my eyes which are failing? To emphasise, I couldn't see that the field was editable and got caught by clone of a clone etc.
#10
@merlinofchaos Has the maxlength perhaps just gone missing from D7? Is that still the solution? I'll roll a patch if that's the case.
#11
The same error even occurs during cron-run and when installing/activating new modules (/admin/modules/list/confirm). Seen in 7.x-3.0-alpha3.
I therefore raised the priority to major and adjusted the issue title.
Setting the database-field block.delta to varchar(64) helps, at least as long as the names don't get longer than 64 chars.
#12
This issue just struck me while building some minipanels.
In my scenario it would have been good to have a limited on the machine name as the resulting error was very unhelpful.
We increased delta to 64 chars to work around.
Please fix :)
#13
I believe this is fixed thanks to #956394: Database column not large enough making it impossible to assign a layout to a panels page? Anyone care to test it?
#14
Yes I think the maxlength has disappeared due to the conversion to export ui. This may not be a simple patch. This is annoying.
#15
Ok. So one reason to limit the names to 32 characters is that the core Block module won't allow a block delta longer than that, so you wouldn't be able to place the minipanel using block rules and in fact it may give an error if you happen to save the Block page at all (not confirmed). Just something to be aware of.
#16
Yeah.
We could go the route Views did and keep a hash so we can keep deltas short enough if necessary. That'd remove the need to fix the names, but of course it'll have the same problem Views has of totally wrecking your deltas if your names are too long.
#17
Definitely an issue with cloning of a mini panel. It's biting us like mad right now.
Have to wind up changing block table to 64 chars, and/or force renaming the clone's machine name to stop the errors coming out.
Seems like this can be trapped just on the machine name creation for the mini panel name. truncate as necessary and if dupe name, truncate shorter and do a _1 _2 or something?
#18
this is a major issue for us, any fix in the pipeline?
rgds Dave
#19
Really? You can't just make sure your mini panel names are under 32 characters? I realize it's a bug and all, but there's an obvious workaround.
#20
I believe it prefixes stuff and you don't realize it until too late; and once it is in the database it is broken without manual database surgery. At least in my experience.
#21
I ran into this issue as well, worth fixing IMO. Patch attached for review. Works for Me (TM).
#22
Personally, I would not do:
$form['info']['name']['#description'] .= t(' The machine name length is limited to 32 characters, due to a limitation in the core block system.');but:
$form['info']['name']['#description'] .= ' ' . t('The machine name length is limited to 32 characters, due to a limitation in the core block system.');In that way, the translatable string doesn't start with a space, which is nicer. Apart from that, it works fine.
#23
Like the patch, I am using it to prevent site users who are unaware of this issue from regularly breaking cache clearing and update.php by adding yet another mini panel that causes this issue.
Patch still applies cleanly.
I'd prefer a solution that goes to the core of the problem... but any port in a storm.
#24
re-roll incorporating the suggestion in #22 - imo it's not a big enough change to warrant changing back to needs review...
#25
Committed and pushed. Thanks for the patch!
#26
Automatically closed -- issue fixed for 2 weeks with no activity.
#27
Just wanted to give you a heads up that the patch #24 is missing in 7.x-3.3
I just had this happen again after updating the module.
#28
The release date of 7.x-3.3 is in 2012. The patch in #24 is dated 2013.
I believe this should adequately explain why 7.x-3.3 doesn't contain this patch.