elementor/update-data overwrites the full Elementor document tree for a post with a caller-supplied element array.
It is the bluntest write in the suite.
Before you run it
This replaces the entire page. Every element, every setting, everything anybody built — gone, with no trash and no undo beyond a WordPress revision if one exists. The force_replace guard fires when the new payload is smaller than what is there, which is the shape of the accident, but a same-size payload that is simply wrong is written without complaint. Read the document first with elementor/get-data.
At a glance
| Ability | elementor/update-data |
| Toolset | Elementor — toolset/elementor |
| Group | Elementor › Documents |
| Requires | Elementor, active on the site |
| Capability | manage_options |
| Safety | Destructive — overwrites an entire document. Guarded by force_replace. |
| Repeatable | Not idempotent — each call changes the row set, so re-running is not a no-op |
| Ships in | AcrossAI Abilities Manager 0.0.34 and later |
How it works
There are legitimate uses: restoring a document from a copy, applying a tree built elsewhere, importing a layout wholesale. All of them involve a payload somebody already has and trusts.
What it is not is an editing tool. Changing one heading by reading the document, editing the array and writing it back works and is several orders of magnitude more dangerous than elementor/merge-element-settings.
An Elementor document is a tree of elements serialised to JSON and stored in the _elementor_data post meta. Every element carries a seven-character hex ID, a type, its settings, and its children. Nothing about that structure is validated by WordPress, so a malformed write produces a document the editor refuses to open.
The payload must be a valid element array. A structurally wrong payload is written successfully and produces a document the editor refuses to open — at which point the previous content is already gone.
The guard catches the most common accident: replacing a populated document with something much smaller, which is what an empty or truncated payload looks like.
Page settings are optional and separate. Omitting them leaves the existing ones.
Elementor generates a CSS file per post and caches it. A change to the document does not change the rendered page until that CSS is regenerated, which is why elementor/clear-cache is the second half of several operations here.
Input
| Name | Type | Required | What it is |
|---|---|---|---|
post_id | integer | Yes | The post holding the Elementor document. |
elements | array | Yes | The complete document tree. |
page_settings | object | No | Document-level settings. Omitted leaves them alone. |
force_replace | boolean | When shrinking a populated document | Required when the payload is smaller than the existing document. |
What comes back
| Name | Type | What it is |
|---|---|---|
post_id | integer | The post written. |
element_count | integer | How many top-level elements the document now has. |
success | boolean | Whether the call completed. |
message | string | A one-line summary of what happened, suitable for showing a human. |
error_code | string | Present only on failure — a stable machine-readable reason, such as a missing field, a wrong field type or an unmet confirmation. |
Example
Ask your assistant:
Restore this page from the copy I took.
It resolves to one call:
{
"ability": "elementor/update-data",
"parameters": {
"post_id": 412,
"elements": [],
"force_replace": true
}
}Worth knowing
- Read the document first. There is no other copy.
- A structurally invalid payload writes cleanly and breaks the editor.
- Not an editing tool — use the element abilities for edits.
- Clear the Elementor cache afterwards.
Related abilities
- Get Elementor Document Data — take the copy first
- Merge Elementor Element Settings — for actual edits
- Clone Elementor Document Data — copy from another post
Get the plugins:
AcrossAI Abilities Manager · AcrossAI MCP Manager
Browse the rest: Every ability, by category