Front-end forms overview

A form lets visitors or members of your site create or change content from a normal page, without entering wp-admin. You build the form in the admin from your existing field groups (or from a data table); the plugin renders it, checks the input, protects it from spam and saves the values exactly like the edit screens do.

Open WPM Fields › Forms (wp-admin/admin.php?page=wpmcf-forms, in the Pro tools menu). The screen has two tabs:

• Forms: the forms of this site (this page and the next ones);
• Connections: save the submissions of other form plugins in a data table, see Connections to other form plugins.

Forms are a Pro feature. The free plugin has no forms.

The four kinds

The Data table entry kind is offered only when your plan also includes data tables (Pro does).

The Forms list

With no forms the screen says No forms yet: "Build a form from your field groups, then put its shortcode or the "WPM Form" block on any page." Deleting a form asks Delete form? ("«Title» disappears from every page that shows it. Entries it already created stay."); the posts, users and rows it created are not touched.

The first thing to do is Create a form.

Put a form on a page

Use either of these in a page, post, widget area that runs shortcodes, or template:

• the shortcode [wpmcf_form key="contact"];
• the block WPM Form (category Widgets). Choose the form in Form › Form; inactive forms are marked "(inactive)".

To edit an existing post, a post form also takes a post ID: [wpmcf_form key="submit_event" post_id="123"], or the block's Edit post ID; see Post forms.

An unknown key prints nothing for visitors; administrators see There is no form with the key "x". Only administrators see this note. The form's stylesheet and script load only on pages that contain a form.

How a submission works

1. The visitor fills in the form and clicks the button. The browser sends the form to the same page as an ordinary post request (multipart, so files work). There is no admin-ajax and no JavaScript needed to send it.
2. The server checks, in this order: the license, the honeypot, the security proof (a signed token for guests, a nonce for logged-in users), who may use the form, the rate limit, your own CAPTCHA filter, the duplicate guard, then the values (types, required fields, uploads). See Guests and spam protection.
3. On success the entry is saved, the optional email is sent, and the visitor is redirected (HTTP 303) back to the page with a ?wpmcf_done=... marker. The page then shows your Success message once (or the visitor is sent to your Redirect to address instead). Reloading the page does not show it again, and it never sends the form twice.
4. When something is wrong, the same page is shown again with a box Your entry was not sent: that lists every problem with a link to the field, and the values the visitor typed are kept (a password never is).

The page can be cached: the guest proof is a signed token, not a per-visitor nonce, and a script refreshes an old token before sending. Logged-in visitors get a nonce, so do not let a page cache serve logged-in visitors a cached copy of a form.

The submit button is disabled after a click so a double click cannot send the form twice.

Which field types work in a form

The form shows every field of the chosen field groups (or table columns) whose type can work on a public page. In the form editor a field that cannot is listed with the badge Not available in forms and is left out of the form.

Rules for containers:

• A Group or Repeater works only when all of its sub-fields work. A repeater whose sub-field is an Image is listed as not available, because uploads work only for fields at the top level.
• Layout fields (Tab, Accordion) are not shown as fields; they do not appear in the field list.
• Image and File fields upload from the visitor's device (see File uploads).
• A Password field works. It asks for the password twice when the field's Confirm option is on, stores a hash and never prints it back.
• Conditional logic and Required set on the fields work in the form like on the edit screens.
• A field the form cannot show is left unchanged when the form edits an existing post or user.

Plans and licenses

When a license expires or a trial ends:

• the Forms screen and its API are locked (Your current plan does not include this feature.);
• the form definitions are kept;
• a form on a page prints nothing for visitors, and administrators see Your plan does not include front-end forms, so visitors do not see this form. Only administrators see this note.;
• a submission that still arrives is refused with This form is not available right now.;
• entries already created (posts, users, rows) stay.

See Trials, renewals and expiry.

Styling

The form is plain, semantic HTML: form.wpmcf-form (with wpmcf-form--post, --user-profile, --user-register or --entry), .wpmcf-form__field, .wpmcf-form__label, .wpmcf-form__input, .wpmcf-form__help, .wpmcf-form__errors, .wpmcf-form-notice and the button .wpmcf-form__submit which also carries WordPress's wp-element-button class, so your theme styles it like any block button. A small default stylesheet is loaded where a form appears.

For developers

• Action wpmcf/forms/submitted (form, object ID, kind) fires after an entry is saved; see the actions reference.
• Filters for the rate limit, client IP, CAPTCHA, uploads, registration roles and password strength are described in the next pages and in the filters reference.
• Form definitions are stored as settings rows form_{key} and managed through the REST routes under /wp-json/wpmcf/v1/forms (administrator only, plan checked on every call).