How to prevent widgets becoming "customized default" when using ContentFragments.UpdateScriptedContentFragments(...) for factory default widget automatic deployment

We are currently using methods ContentFragments.UpdateScriptedContentFragments(...) method for automated deployment of factory default widgets

What have we done:
1. Deploy a DLL with a factory default widget provider plugin

2. Plugin from DLL installs widgets via ContentFragments.UpdateScriptedContentFragments(...)

3. Corresponding widgets become available in Widget Studio as a "default" widgets

4. After some time, we change these widget in a source repository

5. We compile and deploy new version of DLL that contains changed widget

6. Plugin from DLL updates widgets via ContentFragments.UpdateScriptedContentFragments(...)


Wanted result:
- New widget version should be available in widget studio just after DLL deployment


Actual result:
- Widgets in widget studio become labeled as a "customized default" and they contain code of previous version of widget until you do Revert on them, only after that they will become "default" and will contain latest code

  • The purpose of ContentFragments.UpdateScriptedContentFragments() is to provide API level support for upgrading widgets in the same way that the platform does with a version update. That process will version all updated widgets based on the provided source files and return a message that can be shared with a user to identify those changes (and types of changes) and review and approve those changes. It does not force the upgrade (similar to how a platform upgrade does not force the UI to update).

    The platform sends the widget upgrade message as part of the upgrade system notification and custom widget providers can do the same. There is not currently an API to revert customized widgets or force an upgrade of factory default widgets. 

    The alternative approach when attempting to automate a UI update would be to automate the importing of widgets, however, there is not a supported API for that either.

    In either case, for your use case, I would recommend logging a feature request.