We are using the grid with Le Blender and have come across an issue with the grid settings. We are using some user defined data types as properties on Le Blender and we have an issue with deployment.
As Le Blender stores the guid of the data type in the grid setting file, during our deployment these id's changes. It doesn't affect the inbuilt properties in Umbraco as these are always the same.
Has anyone come across a work around to this? Is there something similar to Umbraco Forms where the settings can be stored on a storage container?
We've been having this issue for a while on one of our sites. It happens infrequently enough that we have not out of our way to find a proper work-around (not sure if Courier might help?).
To get around it, post deployment, we are changing the Unique IDs of the datatypes to match those created in local/staging environments in the umbracoNode table.
This has worked well for us so far, but if is a faff, and we have only had to do it on shiny new DataTypes, so there's been no conflicts.
Am sure you have got around this by now, but for others this may help in the short term.
yeah - the GUID ids can change between installs, but a they can be set programatically. I think Courier might set these and i know uSync will, so if you use something like them then the GUIDS won't change, and you should be ok.
Grid settings and deployment of custom data types
We are using the grid with Le Blender and have come across an issue with the grid settings. We are using some user defined data types as properties on Le Blender and we have an issue with deployment.
As Le Blender stores the guid of the data type in the grid setting file, during our deployment these id's changes. It doesn't affect the inbuilt properties in Umbraco as these are always the same.
Has anyone come across a work around to this? Is there something similar to Umbraco Forms where the settings can be stored on a storage container?
We've been having this issue for a while on one of our sites. It happens infrequently enough that we have not out of our way to find a proper work-around (not sure if Courier might help?).
To get around it, post deployment, we are changing the Unique IDs of the datatypes to match those created in local/staging environments in the umbracoNode table.
This has worked well for us so far, but if is a faff, and we have only had to do it on shiny new DataTypes, so there's been no conflicts.
Am sure you have got around this by now, but for others this may help in the short term.
This is a fairly fundamental flaw though...
Hi
yeah - the GUID ids can change between installs, but a they can be set programatically. I think Courier might set these and i know uSync will, so if you use something like them then the GUIDS won't change, and you should be ok.
Kevin
is working on a reply...