This is appearing from v 7.6.0 upwards, upgrading from v 7.3
The backoffice is loading fine, but the public facing home page is not, pointing at line 5
Line 5: var topNodes = home.topLinks.Split(',');
My guess here is that somewhere in the templates, there is a list of toplinks, and one of them has an invalid type?
Where would I find the links?
I updated the obselete types at 7.6.0 as that is the only version I can see all the old/new types.
Do I need to hunt through anything else to correct any code?
It's been a bit since I ran into this, but as I recall 7.6 was where they started introducing the pickers which use the UDI (Umbraco GUID) references rather than the original integers. However to avoid having to change lots of the already stored data it left this alone and most of the datatypes would still handle either type of reference internally up until about v9/v10.
Where this can cause problems though is on the frontend. As the data stored on a picker could now be either a classic integer or a UDI, it could cause some differences in behaviour with existing code in the solution. While its possible to mitigate for this your code, the better long term solution is to get everything stored in the pickers migrated over to using UDI references internally and then just correct code to work with UDIs instead, as even if it can be made to work with the classic integers for now it'll cause problems at some future point.
Proworks did a project called Our.Umbraco.Migration to help with this. It's not perfectly documented, but it includes a demo 'IdToUdiMigration' base migration to convert ID to UDIs internally. It's available on nuget, but I have a feeling I actually had to use the code repo itself for it to work so I'd suggest go there first. Also, though not detailed on there, I also vaguely recall I had to run the migration more than once for it to actually catch and update all the picker references.
String "32242" is not a valid udi.
This is appearing from v 7.6.0 upwards, upgrading from v 7.3
The backoffice is loading fine, but the public facing home page is not, pointing at line 5
My guess here is that somewhere in the templates, there is a list of toplinks, and one of them has an invalid type?
Where would I find the links?
I updated the obselete types at 7.6.0 as that is the only version I can see all the old/new types. Do I need to hunt through anything else to correct any code?
It's been a bit since I ran into this, but as I recall 7.6 was where they started introducing the pickers which use the UDI (Umbraco GUID) references rather than the original integers. However to avoid having to change lots of the already stored data it left this alone and most of the datatypes would still handle either type of reference internally up until about v9/v10.
Where this can cause problems though is on the frontend. As the data stored on a picker could now be either a classic integer or a UDI, it could cause some differences in behaviour with existing code in the solution. While its possible to mitigate for this your code, the better long term solution is to get everything stored in the pickers migrated over to using UDI references internally and then just correct code to work with UDIs instead, as even if it can be made to work with the classic integers for now it'll cause problems at some future point.
Proworks did a project called Our.Umbraco.Migration to help with this. It's not perfectly documented, but it includes a demo 'IdToUdiMigration' base migration to convert ID to UDIs internally. It's available on nuget, but I have a feeling I actually had to use the code repo itself for it to work so I'd suggest go there first. Also, though not detailed on there, I also vaguely recall I had to run the migration more than once for it to actually catch and update all the picker references.
https://bitbucket.org/proworks/Our.Umbraco.Migration/
What I've since discovered is that three things seem to have happened at the 7.6 step.
1 the 'top picks' set up have been wiped out. I added one back in and it started to show ok again.
2 the CSS file link fell off.
3 the one custom datatype we have can't be found in Backoffice, even though its in the database.
Makes me suspect there is a lot of undocumented stuff going on.
I realised the value must be a GUID of some sort so I will try out the Proworks project
is working on a reply...