Forms layer with an unrecognised form_type cannot be opened, and the error blames an add-on

[subodhr258]

Current behaviour

Clicking a Forms layer in the Video Editor can replace the whole settings panel with this message, and the layer cannot be opened at all:

This layer could not be opened. It may be provided by an add-on that needs updating to work with this version of GoDAM.

Two things are wrong here.

#	Problem	Effect
1	The Forms layer editor throws a JavaScript error when the layer's saved form_type is not one of the ten supported values, or is an empty string	The layer can never be opened or edited. The only action left is Delete.
2	The message blames an add-on	form is a core layer type that ships inside the GoDAM plugin. No add-on update can fix it, so the message points people at the wrong thing.

The same video plays fine on the front end. inc/templates/godam-player.php:785 treats an empty form_type as gravity, finds no gf_id, and prints nothing. So the layer is silently skipped there while the editor crashes on it.

How a layer ends up in this state

Not through the editor UI. Every path in the shipped UI writes one of the ten supported values (SidebarLayers.js:323 uses formType || 'gravity', and the Add layer menu only offers those ten). The routes that do reach it:

Route	Real today?
Anything that writes rtgodam_meta over the REST API. The meta field is stored verbatim with no schema and no validation of form_type (class-meta-rest-fields.php:43)	Yes. Seeded test data, fixtures, migration scripts, and any third party integration with edit rights
Content imported or copied from a site running a different build, including branches that added an integration we never shipped, for example feat/hubspot-forms-integration which wrote form_type: 'hubspot'	Yes, for anyone who ran such a build
Removing or renaming a form integration in a future release	Not yet, but every existing layer of that type would turn into this crash on upgrade
A supported form plugin being deactivated	No. That keeps a valid form_type and correctly shows disabled controls

So this is a robustness gap, not something a customer can trigger on their own today. It is worth fixing because the failure is total for that layer, the message misdirects whoever hits it, and a future integration rename would make it customer facing.

Found on the internal dev site, on a video whose layers were seeded by script:

id: aaaa1111-2222-4333-8444-form00000001
type: form
name: Signup Form
form_type: ""      <- empty

Expected behaviour

1. Opening such a layer shows the normal layer header plus a plain message saying the form integration stored on this layer is not available, together with the integration picker so a supported one can be chosen. Display time, Allow skip and Background colour stay editable, and the layer can be repaired instead of only deleted.
2. The message that mentions add-ons is only shown for layer types that actually come from an add-on, for example the WooCommerce Shop Hotspots layer, and not for the core types CTA, Hotspot, Forms, Ad and Poll.

How to recognise it

In the Layers list the affected row shows the generic type name Forms and the generic icon, instead of the integration name and logo such as "Gravity Forms" or "WPForms". That combination appears only when the saved form_type matches no supported integration.

The browser console shows:

GoDAM Video Editor: a layer editor failed to render.
Element type is invalid: expected a string (for built-in components) or a class/function (for composite components) but got: undefined.

Steps to reproduce

With any video that has a Forms layer, and its attachment ID:

wp eval '$m = get_post_meta( VIDEO_ID, "rtgodam_meta", true ); foreach ( $m["layers"] as $i => $l ) { if ( "form" === ( $l["type"] ?? "" ) ) { $m["layers"][ $i ]["form_type"] = ""; } } update_post_meta( VIDEO_ID, "rtgodam_meta", $m );'

Any string outside the ten supported values does the same, for example hubspot. Then open the video in the Video Editor and click that layer. The right panel shows the message above instead of the form settings.

To read what is stored:

wp eval 'print_r( wp_list_filter( get_post_meta( VIDEO_ID, "rtgodam_meta", true )["layers"], [ "type" => "form" ] ) );'

Affected versions

Present on develop and on the 2.1 QA branch.

For implementers (code references and a suggested fix)

Crash 1: unknown integration

pages/video-editor/components/layers/FormLayer.js:117

const FormLayerData = FormLayerComponentType[ layer?.form_type ?? 'gravity' ];
const FormLayerComponent = FormLayerData?.component;

?? 'gravity' only covers form_type being absent. An empty string or an unrecognised value passes through, FormLayerData is undefined, and line 126 still renders it:

<FormLayerComponent layerID={ layer.id } />

React throws Element type is invalid ... got: undefined.

Crash 2: layer missing from the store

Same line 126 reads layer.id with no optional chaining, so a layerID that is not in state.videoReducer.layers throws a TypeError and lands on the same message. LayersHeader on line 123 already handles this safely with layer?..

Where the message comes from

pages/video-editor/components/layers/LayerErrorBoundary.js:47, rendered for every layer type by Layer.js:85. Suggested change: pass the layer type in, and use the add-on wording only when the type is not one of the core five.

Suggested fix in FormLayer

Return early when FormLayerComponent is undefined: render LayersHeader plus a notice and the integration picker.

Reproduction used to confirm this

A temporary Jest test rendering the real Layer component with a mock store:

form_type	Result
gravity	renders normally
signup	Element type is invalid ... got: undefined, message shown
''	Element type is invalid ... got: undefined, message shown

Worth keeping a permanent version of that test alongside the fix.