block hashes in (Mini) Panels, just like in Views [#1239544]

hey
i'm getting an issue, where really long Mini Panels machine names are causing duplicate SQL entry errors for the blocks table, because the `delta` field has a limited size (32 characters), and when drupal attempts to insert the blocks, the machine names get trimmed to the limit allowed, and the different rows collide, resulting in only one being saved to the db (the rest dumped to void), and nasty errors all over the place.

user warning: Duplicate entry 'zen_blablablah-panels_mini-blablablabla_minipanel_sidebar_1' for key 2 query: INSERT INTO dpl_blocks (module, delta, theme, status, weight, region, custom, throttle, visibility, pages, title, cache) VALUES ('panels_mini', 'blablablabla_minipanel_sidebar_1_variant_b', 'zen_blablablah', 0, 0, '', 0, 0, 0, '', '', -1) in /drupal-6.22/includes/common.inc on line 3538.
user warning: Duplicate entry 'zen_blablablah-panels_mini-blablablabla_minipanel_sidebar_2' for key 2 query: INSERT INTO dpl_blocks (module, delta, theme, status, weight, region, custom, throttle, visibility, pages, title, cache) VALUES ('panels_mini', 'blablablabla_minipanel_sidebar_2_variant_a', 'zen_blablablah', 0, 0, '', 0, 0, 0, '', '', -1) in /drupal-6.22/includes/common.inc on line 3538.

i think the solution is to immitate Views behavior, in which instead of inserting machine names in the `delta` field, Views instead inserts hashes.
would it be possible to implement this for both 6.x and 7.x?

since i'm using Panels Everywhere, it's not as bad for me, because i don't use the blocks system directly, but errors pop up everywhere in the watchdog and http logs, as well as in the screen if i have html errors enabled.
however, were i not using Panels Everywhere, and instead relying on Blocks, Blocks 2.0 or Context, i would have to rename all the Mini Panels/Blocks which has long names.

some SQL from blocks table:

Panels:

INSERT INTO `dpl_blocks` (`bid`, `module`, `delta`, `theme`, `status`, `weight`, `region`, `custom`, `throttle`, `visibility`, `pages`, `title`, `cache`) VALUES
(238, 'panels_mini', 'blablablabla_minipanel_sidebar_1', 'zen_blablablabla', 0, 0, '', 0, 0, 0, '', '', -1),
(230, 'panels_mini', 'blablablabla_minipanel_sidebar_2', 'zen_blablablabla', 0, 0, '', 0, 0, 0, '', '', -1);

Views:

INSERT INTO `dpl_blocks` (`bid`, `module`, `delta`, `theme`, `status`, `weight`, `region`, `custom`, `throttle`, `visibility`, `pages`, `title`, `cache`) VALUES
(177, 'views', '57c991db2afb68f9229606bb18b8c7ac', 'zen_blablablabla', 0, 0, '', 0, 0, 0, '', '', -1),
(178, 'views', 'a6b5650a992d08ff1d8bf841775ec474', 'zen_blablablabla', 0, 4, '', 0, 0, 0, '', '', -1);

Comments

Comment #1

merlinofchaos commented 4 August 2011 at 16:26

Well. I think maybe mini panels probably should limit the field to 32 characters. People hate that md5 thing because it makes the block-module-delta.tpl.php suggestion impossible to guess.

Comment #2

lpalgarvio commented 4 August 2011 at 18:24

edit: was in a hurry, let me rephrase

when dealing with blocks in raw SQL dumps, i used to hate when Views would do that mess with hashes
but nowadays, with Features, i think that backup/manipulation problem is irrelevant :)

for dumping out configs, i see 3 means to achieve the same goal
- my favorite, features + panels everywhere
- an alternative, features + context
- another one, features + regular blocks
certainly it's much easier to do with the first 2

usage of features extra, uuid features, etc can help with exporting certain things we normally can't export.

regarding the inside of .tpl files... i guess the only long-term solution is to use CSS IDs / Classes. that guarantees uniqueness, no need to resort to automatically generated IDs (same goes with Semantic Views and Semantic CCK vs CCK/Fields).

regarding the .tpl files themselves... no much luck there. idk.
can't somehow the Mini Panels be correlated to their hashes and with their machine names? map .tpl filenames to panel/views block machine names, with a relationship to hashes?

i dont know how .tpl files work for Views, but if somehow Block Views with hashes do work the normal way with .tpl files, then i guess whatever approach it uses, would be the way to go. if thats the case, perhaps move the code to ctools?