Trouble saving changes for a widget in a deeply nested FlowPart during migration.

[willnationsdev]

I have a form with many nested flow parts to split things up between form steps, fieldsets within a step, and fields within a fieldset. Display/Edit/Update all work fine, but now I want to do a migration that will 1) update the content definition of one of the "field" content item widgets and 2) iterate through all instances of that item in forms and modify its JSON data.

I can manage to iterate through the items and update their JSON data (verified by inspecting the Content property of the top form ContentItem and going deep into the nested FlowParts and their Widgets), so I can see that the data has updated, but I can't get it to actually save in the SQLite database. I'm doing the content definition updates afterward, but those seem to be working fine.

I use ContentManager.UpdateValidateAndCreateAsync(formItem, VersionOptions.Published) just like I've done before to create a new, published item in the Document table, but the database doesn't change. There are no errors in the log.

Any ideas what I could be doing wrong?

Edit: I also tried creating a new content item, merging the data over, applying the changes, and then using the function, but that legitimately makes a new item entirely rather than updating the existing one, even though I ensured the ContentItemId was the same, so not sure how to do it properly.

[Skrypt]

Are you missing a call to _contentItemDisplayManager.UpdateEditorAsync ?

[willnationsdev]

No, I'm doing this inside of a Migration, so I'm not submitting an editor at all. It just happens on pipeline initialization. I did however figure it out eventually. See the other answer on this discussion for details.

[willnationsdev]

I finally figured this out. Only took me a few hours of experimentation, source code analysis, and annoyance. XD

First, it looks like I have to assign a new List<ContentItem> to the set of widgets on the FlowPart in order for it to properly recognize that the Widgets property has changed. If I just inline modify the Widgets in question, it doesn't appear to actually update the nested data. So, I assigned the widgets to themselves with a Select(...) statement via LINQ, remapping the widgets I needed to change as needed. This ended up being simple for the higher up FlowParts (steps, fieldsets) since they just returned the same ContentItem, whereas the deepest FlowPart (for field widgets) needed to actually make the changes to the parts/fields on the widget before returning the widget. By the end, I'd mutated the necessary nested widgets, but all FlowPart's Widgets properties had been reassigned to new List instances.

Second, I needed to properly create a new row in the database just like the update operation does in the form. To get that to work as intended, I had to use IContentManager.GetAsync(item, VersionOptions.DraftRequired). This returns an entirely new instance that, if committed, will create a new draft row in the database (I reference this as newItem in the following sentences). The instance already comes "loaded", so you don't need to do a newItem.Merge(oldItem) operation or anything (when I tried doing that, I ended up with duplicate data). Finally, I called IContentManager.PublishAsync(newItem) to update the published status of the previous item and the new item. This perfectly emulates the "submission" behavior of submitting to the Editor page without actually performing all of the various UpdateEditorAsync operations, so you can just do some inline logic to change the item's data structure in your Migration code.

Hope this explanation helps someone else down the road.

[Skrypt]

You're getting good 😉

[willnationsdev]

Thanks! Been a long time coming. One day I hope to actually get around to compiling the OC source code and contributing something. For now though, I'm just buried in work. Have to rebuild a legacy, proprietary CMS using OC in a limited time. XD Trying to engineer it all to be generic/extensible though so that the various modules can eventually be open-sourced and contributed back.

[Skrypt]

We all been there at some point 😉
Using OC might be a time saver in the end moving forward so that's a good start.