U4-6102 - Add warning for removing or renaming Grid row configurations since after renaming/delting all data is lost

Created by Jeroen Breuer 12 Jan 2015, 19:41:24 Updated by Shannon Deminick 12 May 2015, 02:52:12

Relates to: U4-6148

Relates to: U4-6533

''NOTE: to fix this issue U4-6148 needs to be fixed but we can't fix that in a patch release, for now it will warn you about these changes.''

Not sure if it's a bug, but I'm experimenting a bit with the Grid. After adding more row configurations to the datatype I renamed some other row configurations because I needed a better naming convention with all the extra row configurations. After renaming them all the data was lost on the content that had the old row configuration names. Since I'm only experimenting it's not a problem now, but I could imagine some angry customers if they lost all their content after this.

Not related, but I've had the same problem with Archetype.


Asbjørn Riis-Knudsen 12 Jan 2015, 20:20:51

Confirmed on a clean 7.2.1 install with Fanoe. I took the Text Page grid and renamed "Article Wide" to "Article Wide Test". Subsequently, all content below the banner on text pages was lost.

I would argue that this a major issue, as it causes severe data loss. Nothing in the UI indicates that a rename will delete content.

Interestingly, if you don't save the content pages, and reverse the rename, the content comes back.

Jeroen Breuer 12 Jan 2015, 20:29:52

That's probably because the content is saved as json and stil there. I just won't be rendered because the row configuration expects something different. You can check the json in the umbraco.config file.

Matt Brailsford 18 Feb 2015, 15:23:11

I'm assuming this is because all of the config is done in browser and stored as a complete dataset against the grid config, thus the row configs don't get their own ID's so the only thing that umbraco has to go off to find the relevant row contents is the row config name. It could be a good idea to look at generating id's for the row configs so that data can be maintained if a row config rename is required.

Seem like a reasonable limitation till you think of it being used site wide and later on the client requests it to be renamed to something more meaningful.

Matt Brailsford 18 Feb 2015, 15:24:51

Also worth noting, if something like ID's is introduced, this needs to be "upgradable", so grids auto update existing values, giving them an id if they don't have one. Wouldn't want everyone who has used a grid to loose all their data.

Michal Koblasa 18 Feb 2015, 15:54:53

There should be warning for user before changing name, "all created grid content would be broken". But i prefer to change storing thru IDs. Even if you have to solve current grid usage and content upgrading on ID usage. Actualy it is one of the reasons why i dont want to use grid in release environment.

Asbjørn Riis-Knudsen 18 Feb 2015, 16:34:01

Yes, using an ID will make much more sense. And I'm also holding off on using the grid in production because of this issue (though I suppose you could work around it by running some code to modify grid property JSON).

Asbjørn Riis-Knudsen 18 Feb 2015, 17:22:40

This is also a localization issue, as the current implementation makes the Grid row config names un-localizable. Using an ID would make it possible to localize the row config names (perhaps via a dictionary key).

Igor Dragutinović 02 Mar 2015, 10:42:08

I'm experiencing this issue also, I just added description to grid layout property in one document type.I tried to find some errors or differences in grid property JSON in the database, but everything seems ok. Content XML and Preview XML are the same, all id's are correctly set. Umbraco.config contains the same data as in the database. No idea what else to try in order to fix this.

Shola 02 Apr 2015, 14:30:29

A similar issue:

Create a grid.

For settings, add a setting for the CSS "class" that is a radiobuttonlist of prevalue class names, that you can apply to rows. For example:

[ { "label": "Highlight Row", "description": "Choose background color", "key": "class", "view": "radiobuttonlist", "prevalues": [ "Blue", "Grey", "White", "Black" ], "modifier": "Highlight {0}", "applyTo": "row" } ]

Create a doc type that uses this grid, and create a piece of content that uses that doc type.

While your editing this content, have one of the rows use one of the above CSS classes, and save.

Under datatypes, go back to the grid settings and add a 5th CSS class to the above current list of prevalues.

Go back to the content node in the backoffice. The row that you selected a CSS class for has "forgotten" your selection.

It seems that the general issue here is that the grid is quite fragile when it comes to modifications, after any doc types are already using it.

Shola 03 Apr 2015, 18:13:04

I was wondering--should my above comment be under its own separate issue? I put it here since it's essentially the same problem: grid configuration changes cause apparent data loss/data disconnect.

Priority: Major

Type: Bug

State: Fixed

Assignee: Shannon Deminick

Difficulty: Normal


Backwards Compatible: True

Fix Submitted:

Affected versions: 7.2.0, 7.2.1, 7.2.2, 7.2.3, 7.2.4

Due in version: 7.2.5


Story Points: