All plans

How sections become widgets

Your AI app picks an Essential Addons widget per section, FigWP checks the choice against the widget catalog, and a widget that drops content is demoted.

Updated October 28, 20263 min read
Open .md
On this page

A page built from the right widgets is easy to edit; a pile of nested containers is not. FigWP makes the AI app decide every section, checks every decision, and refuses to let a wrong one lose content. This page explains the three parts of that: the mapping, the catalog, and the gate.

The mapping

Before converting, the app proposes a mapping: for each top-level section of the frame, one of

  • an Essential Addons widget, with the layers that fill its parts (title, content, image, items) and, where the design shows one, the layout or skin to use;
  • an Elementor widget, the fallback tier, only when no Essential Addons widget fits;
  • container, with a reason, when the section is layout rather than a component.

FigWP validates each proposal: the widget exists, the layer is in the frame, the parts are ones the widget has, the layout value is one the widget offers. Accepted choices are kept for two hours per frame. A conversion without a mapping is refused, so sections are never guessed into widgets from layer names unless you ask for exactly that.

A section left out of the mapping is built from containers, text and images. Leaving a section out is a decision, not an omission.

The catalog

The app chooses from a design map of every Essential Addons widget, Free and Pro: what the widget looks like in a design and how to recognise it, its parts and the controls they fill, every layout, skin and preset value, carousel options, and the quirks the converter knows about. Elementor’s free widgets have a map of their own, each entry naming the Essential Addons widget to try first. The app can read a widget’s whole guide before deciding.

FigWP builds more than 120 widgets this way. The remaining Essential Addons widgets can still be placed after import by replacing an element on the page.

The fidelity gate

After building a widget, FigWP compares the text the widget captured with the text in the section. Below 70%, the widget is dropped and the section is rebuilt from containers, so a wrong choice degrades to a plain layout instead of losing a paragraph. The conversion reports every widget that was dropped and why.

Every widget the app chose but the converter could not build is reported too, naming the layer and the reason: a layer whose name says otherwise, a group whose member is the widget, a nested-tabs case that became something else.

Settings the app can set

A section can carry the layout the design shows: a card skin, an icon position, a carousel’s slides per view. The app takes the control names from the widget’s guide, FigWP checks them against it, and the converter sets them on the widget it built before the conversion is saved. Everything else about the widget is written by the converter from the layers themselves.

Repeated items

Cards, plans, testimonials and FAQ items are recognised as repeater items when the frames inside a section share a shape. The widget gets one item per frame, with each item’s title, text and image from that frame’s layers.

Troubleshooting

A section became containers although the right widget exists. Either the mapping left it out, or the gate dropped it. Ask the app which; then either ask it to remap that section to the widget, or make the section’s text reachable (text inside a mask or a boolean, for example, is not).

The widget is right but the layout is wrong. Ask the app to set the layout on that section. It reads the widget’s guide for the value and patches the element.

A widget the site does not have. Import refuses widgets the site lacks instead of silently dropping them. Make sure Essential Addons Pro is active there.