In the Optimizely CMS world, we see GUIDs everywhere. They are unique identifiers for content types and more. As part of Optimizely CMS development, developers are advised to always specify GUIDs in their Content-Type declarations. If one isn’t specified, the DB assigns one dynamically when saving the Content-type.
A big reason for this is that behind the scenes, whenever Optimizely code is looking for content type for rendering, they search by GUID first. If a match is found, they fetch the content. They even update specific characteristics/properties on that content if they have changed in code to keep the data up to date.
The above seems reasonable enough, and thankfully Optimizely has a fallback in place for when a developer forgets to put a GUID on a content type; the save logic will take care of it. But does the same apply to other things like property definition types, for example?
From a recent troubleshooting experience, I realized that’s not true across the board. Property definition types are defined when we create PropertyLists. They do have a GUID property, but not required. And no GUID is assigned dynamically to save time, either.
What Does This Mean?
Normally, there won’t be much of an impact. Optimizely CMS falls back to searching by Type Names and Assembly Names when there is no GUID to match. And since type and assembly names are not some, we change quite often in code, and that match always returns results.
The scenario where this got problematic was upgrading a CMS 11 site to CMS 12. Our CMS 11 site was already live and a work in progress. So we didn’t directly want to touch the same solution. So instead, we opted to clone it into a new repo, a new solution, and upgraded to CMS 12 there. For some reason, we ended up putting a slightly different Assembly Name on this new solution. And also ended up doing some code refactoring, moving files/folders around for better structure, thus changing namespaces and technically Type Names on some of the defined types.
How Will This Change Impact Us?
Well, because we didn’t exactly understand the importance of GUIDs and Assembly Names then, we didn’t realize that those minor changes could lead to practically breaking previously working things like Navigation and Menu, which extensively used Property Lists.
As explained above, our Property List definitions did not have a GUID specified on them. So now Optimizely relies on Type and Assembly Names to find the property definition types. And now, in our new solution, those changed too, so working with a copy of the existing CMS 11 database, it couldn’t find anything for the new type and assembly name combination and hence couldn’t show data for it or render it. And kept throwing this weird JSON serialization error in logs. We couldn’t even save new data on those property lists now.
Geta Categories
The same was true for Geta Categories. When we upgraded the Geta Category package and launched the CMS 12 site, it started throwing errors for not finding the category types we had created in the code. When we looked in DB, we saw new Categories were created suffixed with (1) for all the types we had in code. Initially, we wrote some SQL scripts to clean those out, so those errors disappeared.
But after the above finding around GUIDs and Assembly Names, we looked deeper into the data. Categories are also content Types, so they always have a GUID, either specified from code or dynamically generated. They also have the fully qualified Type Name on them, which has both the type and assembly name included. And our code had GUID specified too. So then this should have just worked.
But no. Apparently, when the categories were first created, they didn’t have GUID specified in the code. So DB dynamically assigned one at save. But later, someone added new GUIDs in principle to all of them. But that didn’t match what the DB had. So when Optimizely tried to match on GUID, it didn’t find anything. Now it tried matching on that fully qualified Type name, which, thanks to our minor tweaks to CMS 12 solution, had changed too. With neither match, it created new ones, thinking those are new types altogether. And when it came time to save the name on these, because the original name already existed in DB, the save auto suffixed the new one with (1). So now the places that used those categories found the match via GUID, couldn’t actually match on name and hence errored out.
What was the solution?
Once we realized what had happened here, we made small but very relevant changes to fix not one but multiple issues. We renamed the assembly to what the CMS 11 solution had, added GUIDs to our property list definitions, and matched the code and DB GUIDs for our Category Names, and that’s it. Everything fell into place automatically, the menu started working, and no more new category types got created. No more JSON serialization errors.
I know this was quite a bit of storytelling, but what I realized from this exercise is that we tend to focus so much more on the big, complex, architectural, and design strategies and implementations that we sometimes miss out on the small nitty gritty things, that are small, but way more impactful than we realize. GUIDs and Assembly Names are 2 such examples.
I hope this comes in handy for others on their way / in the process of upgrading to CMS 12, and I don’t have to spend as much time figuring this out as I had to.
It’s great information everyone should know; GUIDS are essential in CMS and can not be ignored; what do you think about WordPress GUIDS?
Thanks Jitin! I haven’t worked so much with wordpress in depth to explore exactly how GUIDs are used there, but if you research, you might find some useful information out there like this : https://pressidium.com/blog/wordpress-database-guid/
Hope it helps!