elementor/clone-data copies the full Elementor tree from one post to another, with fresh element IDs throughout.
Page settings can come too, and the target is guarded when it already has content.
Before you run it
The target’s existing Elementor content is replaced, not merged. force_replace is required when the target already has content, and once it is gone there is no trash — only a post revision, if one exists. Confirm you are pointing at the right target: source and target are both post IDs, and transposing them overwrites the page you meant to copy.
At a glance
| Ability | elementor/clone-data |
| Toolset | Elementor — toolset/elementor |
| Group | Elementor › Documents |
| Requires | Elementor, active on the site |
| Capability | manage_options |
| Safety | Destructive — overwrites the target 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
Element IDs must be unique within a document. Two elements sharing an ID is a state Elementor does not expect, and the symptoms — an edit landing on the wrong element, a duplicate that disappears — are hard to trace back to the cause.
Across two posts, duplicate IDs matter less than within one — but only until somebody copies content between them again, or a template is built from one of them. Regenerating is cheap and avoids the question entirely.
The page settings option is worth taking deliberately. A page’s layout, background and custom CSS are part of how it looks, and a clone without them produces a page with the right content and the wrong frame.
Anything referencing an element ID does not survive the clone — custom CSS keyed to an ID, anchor links between sections. Those need updating on the copy.
The source is unchanged. This reads from it and writes to the target.
Not idempotent in the sense that re-running regenerates the IDs again, producing a different document with the same content.
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 |
|---|---|---|---|
source_post_id | integer | Yes | The post to copy from. |
target_post_id | integer | Yes | The post to copy into. |
include_page_settings | boolean | No | Copy the document-level settings too. |
force_replace | boolean | When the target has content | Required when the target already has an Elementor document. |
What comes back
| Name | Type | What it is |
|---|---|---|
target_post_id | integer | The post written. |
element_count | integer | How many top-level elements were copied. |
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:
Copy the layout from page 412 onto the new page.
It resolves to one call:
{
"ability": "elementor/clone-data",
"parameters": {
"source_post_id": 412,
"target_post_id": 598,
"include_page_settings": true,
"force_replace": true
}
}Worth knowing
- IDs are regenerated, so ID-keyed CSS and anchors do not follow.
- Take the page settings unless you have a reason not to.
- The source is untouched.
- Check the direction — transposing the IDs overwrites the wrong page.
Related abilities
- Get Elementor Document Data — inspect the source first
- Create Elementor Page — make the target
- Duplicate Elementor Template — the template equivalent
Get the plugins:
AcrossAI Abilities Manager · AcrossAI MCP Manager
Browse the rest: Every ability, by category