Active
Project:
Panels
Version:
7.x-3.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
22 Dec 2011 at 05:34 UTC
Updated:
10 May 2012 at 12:32 UTC
Field 'subtype' in 'panels_pane' table is VARCHAR(64).
In some cases is not enough, and appears bug with missing/deleted pane on panel after panel saving.
I'm suggesting to change it to VARCHAR(128)
Comments
Comment #1
merlinofchaos commented64 is enough to handle any subtype I know about.
Comment #2
agalitsyn commentedOn our project we have more than 700 different displays in views. So, names can be long.
Subtype forms as "view_name+display_machine_name". We haven't any check on name length. And appeared bug, as I wrote in first post. There is no error message, and how to fix this bug is obviously not clear for the first moment, so we spend some time.
For example:
View name - custom_node_listing_p2
Display name - custom_panel_pane_place_culture_city_strasbourg
Should be - custom_node_listing_p2-custom_panel_pane_place_culture_city_strasbourg
Write in DB as - custom_node_listing_p2-custom_panel_pane_place_culture_city_stra
So 64 is not enough for us
Comment #3
merlinofchaos commentedDisplay names do not need to be unique, they are attached to the view. There is simply no reason to create display names that long.
If you have 700 displays on a single view, you have made a gigantic error.
Please select shorter display names.
Comment #4
agalitsyn commentedOk, I know that needn't to be unique.
It's business requirement. We have some content type, amount of it is huge. All displays have similar category, because it is needed to use the same templates. Content manager (not a developer) creates and attach different displays to the nodes with own panel. He add unique machine names, because it is convenient.
That's why name are long for this case. It's hard to take care about length of display's machine name, when you have project with big amount of content. So we altered the table
Comment #5
merlinofchaos commentedWell, then you may as well just hook_schema_alter and make the subtype field bigger so this will work for you. I'm not in the habit of making changes like this to support unusual business requirements. I have no idea if making that field bigger will hurt anything; probably not.
This is a good argument for having not actually made the display ids editable, though!
Comment #6
agalitsyn commentedOk, thanks for answers!
Comment #7
agalitsyn commentedMay be it is better to add some validation though? Because without validation it is "silent" bug, not evident
Comment #8
pprischepa commented+1 I've the same problem.
Comment #9
IRuslan commentedI have same problem.
I think validation in this case would be great solution.
Comment #10
Letharion commentedI agree that validating that the length of names and giving an error message is a good idea, but adding to the number +1 is not going to help. Please spend the time writing a patch instead.
Comment #11
merlinofchaos commentedOk yes, we can add validation in the content pane display, though that won't actually help onnon-content pane dislays going through the other more generic views integration.
We might have to use the same trick that blocks use -- an md5 hash when the string goes out of bounds. That'll be fun too, but it at least prevents silent errors.
Comment #12
Letharion commentedClosed #1230492: Plugin names must be a maximum of 32 characters long as dup of this one.
Perhaps we can validate several fields when panes are saved to avoid "strange" rendering fails.
Comment #13
kars-t commentedPushing this to D7.
We ran into this because the name of the View was very long and this added up with the name of the views pane to a string much longer than 64 chars.
It's not a big problem and we did change the machine name of the view. But some kind of warning / validation would be great.