contact-form-7/remove-form-field takes a field out of the template, and takes the label with it when that label wrapped nothing else — so you are not left with an orphaned “Phone number” caption above empty space.
The response lists any mail tags that now resolve to nothing, which is the part that matters more than the removal itself.
Before you run it
A mail template still referencing the removed field keeps sending, with a blank line where the value used to be — and nothing reports it. The visitor still sees a success message. That is why this refuses without confirm: true, and why the response hands you a dangling_mail_tags list to act on with contact-form-7/update-mail.
At a glance
| Ability | contact-form-7/remove-form-field |
| Toolset | Contact Form 7 — toolset/contact-form-7 |
| Group | Contact Form 7 › Fields & Template |
| Requires | Contact Form 7, active on the site |
| Capability | manage_options, plus edit_contact_forms |
| Safety | Destructive — deletes stored values, and refuses to run without confirm: true |
| Repeatable | Idempotent — running it twice leaves the same result |
| Ships in | AcrossAI Abilities Manager 0.0.34 and later |
How it works
The confirmation gate runs before the template is touched, so a refused call leaves the form exactly as it was.
Removal is idempotent: taking out a field that is already gone reports the same result rather than failing, so a retry after a dropped connection cannot remove something else.
The dangling-tag report is the whole point. Contact Form 7 has no notion of a broken mail tag — an unresolvable tag simply renders as nothing — so this is the only moment the breakage is visible.
Input
| Name | Type | Required | What it is |
|---|---|---|---|
form_id | integer | Yes | Form post ID, as returned by contact-form-7/list-forms. |
name | string | Yes | Name of the field to remove. |
confirm | boolean | Yes — must be true | The irreversibility gate. Without it the call is refused before anything is touched. |
What comes back
| Name | Type | What it is |
|---|---|---|
form_id | integer | The form that was written. |
removed | string | The field name that was removed. |
template | string | The template after the removal. |
dangling_mail_tags | array | Mail tags that now resolve to nothing. Fix these. |
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:
Remove the phone field from form 42 — we stopped asking for it.
It resolves to one call:
{
"ability": "contact-form-7/remove-form-field",
"parameters": {
"form_id": 42,
"name": "your-phone",
"confirm": true
}
}Worth knowing
- Act on
dangling_mail_tagsin the response. Leaving them is a notification that silently loses a value. - Contact Form 7 keeps no revisions. Duplicate the form first if the field might come back.
- Removing a field that does not exist succeeds quietly — the operation is idempotent by design.
Related abilities
- Update Contact Form Mail Template — fix the dangling tags
- Validate Contact Form Mail Tags — confirm nothing else broke
- Add Contact Form Field — put it back, or rename by re-adding
Get the plugins:
AcrossAI Abilities Manager · AcrossAI MCP Manager
Browse the rest: Every ability, by category