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

merlinofchaos’s picture

Status: Active » Closed (won't fix)

64 is enough to handle any subtype I know about.

agalitsyn’s picture

Status: Closed (won't fix) » Active

On 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

merlinofchaos’s picture

Status: Active » Closed (won't fix)

Display 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.

agalitsyn’s picture

Status: Closed (won't fix) » Active

Ok, 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

merlinofchaos’s picture

Status: Active » Closed (won't fix)

Well, 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!

agalitsyn’s picture

Ok, thanks for answers!

agalitsyn’s picture

Status: Closed (won't fix) » Active

May be it is better to add some validation though? Because without validation it is "silent" bug, not evident

pprischepa’s picture

+1 I've the same problem.

IRuslan’s picture

I have same problem.
I think validation in this case would be great solution.

Letharion’s picture

Component: Views panes » Code

I 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.

merlinofchaos’s picture

Ok 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.

Letharion’s picture

Closed #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.

kars-t’s picture

Version: 6.x-3.9 » 7.x-3.x-dev

Pushing 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.