Community
Select to view content in your preferred language

Migrating custom widgets and apps to ExB 1.20

598
1
04-14-2026 08:08 AM
WalaZargouni
by
Emerging Contributor
‎04-14-2026 08:08 AM

Hello everyone,

I’m currently facing an issue while migrating existing widgets and applications from Experience Builder 1.19 to 1.20.

I noticed a breaking change in the WidgetManifestProperties interface related to the former defaultOffPanel flag, which has been replaced by defaultInControllerUx. In order to preserve the previous behavior for widgets inside a controller, I now need to manually update each widget’s manifest to reflect this new property. After doing so, I also have to restart the client and remove and re-add each modified widget individually for the changes to take effect.

The main issue is that this approach is not scalable, as I cannot realistically modify all widget manifests manually or replace existing widgets with newly added ones, since this would require reconfiguration to reproduce the same behavior.

I also noticed that all built-in widgets already include this update in their manifest.json starting from version 1.20, and there does not appear to be any backward compatibility mechanism in place.

Given these constraints, I would like to know what options are available for handling this migration.

As mentioned earlier, replacing widgets with new instances is not a viable option in my case.

Thank you in advance

 

1 Reply
Allen_Zhang
by
Frequent Contributor
‎04-23-2026 06:22 PM

There are two separate migration layers in ExB 1.20:

1. Manifest layer (custom widget definition)
This controls the default behavior for newly added widget instances.
So in custom widget manifests, replace:

  • defaultOffPanel: true
    with:
  • defaultInControllerUx: "offPanel"

2. App config layer (existing widget instances)
This controls behavior already stored in existing app configs.
Old instance config fields like:

  • offPanel: true
    need to become:
  • inControllerUx: "offPanel"

ExB’s version-manager handles this app-config upgrade in both runtime and builder, but with different persistence behavior:

  • Runtime: applies migration in memory for compatibility, does not write back to original config files.
  • Builder: applies migration, and when you save, the upgraded values are persisted to the original config.

So the practical takeaway is:

  • You must update custom widget manifests.
  • Existing app configs are usually upgraded by version-manager; they are only persisted after opening in Builder and saving.

 

I assume your concern is about batch updating many custom widgets' instances in app-config. 

Ask me if any other concerns.

0 Kudos