Migrating custom widgets and apps to ExB 1.20

WalaZargouni

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

 

Allen_Zhang

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.