Build
Forms
Build contact forms, newsletter sign-ups and full account flows in the Elementor editor — no shortcodes, no field codes to memorise.
NovaSpark does not process form submissions. It lays them out. The actual work — validation, spam checks, sending mail, creating accounts — is done by software built for it, so every plugin and integration you already rely on keeps working.
| Form | Powered by | You need |
|---|---|---|
| Contact | Contact Form 7 | The Contact Form 7 plugin |
| Newsletter | Mailchimp | Mailchimp for WordPress, with your API key |
| Sign in, sign up, reset password | WordPress itself | Nothing extra |
Two ways to build one #
Both produce the same markup, so you can move between them later without restyling.
| The quick way | The flexible way | |
|---|---|---|
| What | One widget — NovaKit Contact Form, NovaKit Newsletter or NovaKit Auth | A Container turned into a form, with field widgets inside |
| Layout | Rows you reorder, each a full, half or third width | Anything a container can do — nested columns, a field beside an image |
| Best for | Most contact forms and sign-ups | Anything the row grid cannot express |
The rest of this page covers the flexible route, since it is the one with settings to explain. The quick widget exposes the same choices in one panel.
Turning a container into a form #
Select any Container and open Layout → NovaKit Form.
| Setting | Default | Accepts |
|---|---|---|
| Use as Form | Off | On or off |
| Powered By | — | Contact Form 7, Mailchimp Newsletter, WordPress Accounts |
| Form | — | Which form, audience or account flow receives this |
| Manage Fields Automatically | On | On or off — Contact Form 7 only |
| When Signed In | Hide this form | Hide it, or show it anyway — accounts only |
The form wraps the container from the outside, so everything you set on the container — direction, gap, alignment, width — still arranges the fields exactly as you laid them out.
Pick a form before you build. Until you do, the container renders its fields and submits nowhere. The panel says so in orange.
The field widgets #
Ordinary Elementor widgets. Arrange them however the layout needs.
| Widget | Renders |
|---|---|
| NovaKit Field: Text | Text, email, phone, URL or number |
| NovaKit Field: Textarea | A message box |
| NovaKit Field: Select | A dropdown |
| NovaKit Field: Choices | Radio buttons or checkboxes |
| NovaKit Field: Acceptance | A consent checkbox |
| NovaKit Field: Date | A date picker |
| NovaKit Field: Upload | A file attachment |
| NovaKit Field: Hidden | A value the visitor never sees. Takes a dynamic tag, so a submission can carry the page it came from |
| NovaKit Form: Submit | The button. Without it the form cannot be sent |
| NovaKit Form: Message | Where the success or error text appears |
Newsletter forms use NovaKit Newsletter Field instead, and account forms use NovaKit Account Field — both explained below.
Field names
Each field has a Field Name — what it is called in the submission and in your email. Leave it empty and it is taken from the label, which is usually right.
Two rules are enforced for you. Names must be unique within a form, so a
duplicate is renamed rather than silently overwriting the other field. And a few names
belong to WordPress — name, author, s —
so a field called name becomes your-name, exactly as Contact Form
7’s own default does, and for the same reason.
Contact forms #
- Create the form in Contact Form 7Contact → Add New. Name it, save, and leave the form template alone — NovaSpark fills it in.
- Set up the Mail tabRecipient, subject, reply-to. That stays yours; NovaSpark only writes the field list between two markers in the mail body.
- Build the layoutA container with Powered By set to Contact Form 7, your form selected, and field widgets inside.
- Save the pageThis writes your field list into the Contact Form 7 form, so it validates what you actually built.
Why saving matters. Contact Form 7 validates against the field list stored on its own form, not the HTML that arrives. Saving the page keeps the two in step. Without it, the form renders but is checked against an older list.
A form you built by hand is never overwritten. NovaSpark only manages a form whose template is still empty or still the stock default. If you had already written one, it is left alone and the panel tells you so — that is not a failure, it is refusing to throw away your work. Edit the list in Contact Form 7 to match, point at a fresh form, or turn Manage Fields Automatically off and maintain it yourself.
Newsletter sign-ups #
- Connect MailchimpMailchimp for WordPress → Settings, paste your API key, save. That is the whole setup.
- Build the layoutA container with Powered By set to Mailchimp Newsletter, then pick an audience.
- Add the fieldsNovaKit Newsletter Field widgets, then NovaKit Form: Submit.
- SaveThe form record is created and your required fields written into it.
You pick an audience, not a form. Mailchimp for WordPress needs a form record to hang the audience on, so NovaSpark creates and maintains one behind the scenes. You never open its form editor. A form you did build there yourself still appears in the dropdown under its own name, and is never rewritten.
Merge tags
NovaKit Newsletter Field has no Field Name control, deliberately — the merge
tag is the name. Its dropdown lists the tags your audience actually has, read from
Mailchimp rather than typed from memory: EMAIL, FNAME,
LNAME, PHONE and whatever else you have added.
Only EMAIL is required, and a wrong tag fails silently. A merge tag lives in your Mailchimp account, not on your site. Get one wrong and nothing errors — the value is simply dropped on the way, and nobody notices until someone asks where the first names went. That is why the list is read from the API.
Mailchimp collects an address as several values at once, so address-type merge fields are not in the dropdown. Collect them as separate text merge fields, or on a Mailchimp-hosted form.
Sign in, sign up and password reset #
These run on WordPress itself — no Contact Form 7 involved. Every
authenticate and registration_errors filter still runs, so a
security or two-factor plugin keeps working. What NovaSpark adds is that the visitor never
leaves the page you designed.
Turn registration on first if you are building a sign-up form: Settings → General → Membership → Anyone can register. Without it the form renders but cannot create accounts, and the visitor only finds out after filling it in. The panel warns you, with a link to the setting.
Set Powered By to WordPress Accounts, then choose which flow this container is:
| Flow | NovaKit Account Fields to add |
|---|---|
| Sign in | Username or Email · Password · Remember me |
| Register | Username or Email · Email · Password · Confirm Password |
| Reset password — send the link | |
| Reset password — set a new one | Password · Confirm Password |
The two reset forms are not interchangeable, and this is the easiest thing here to get wrong. Recovery is two steps, often days apart. Send the link is what sits behind “Forgot your password?” and asks for an email address. Set a new one is what the emailed link opens, and asks for a new password twice. Put the second one behind “Forgot your password?” and the visitor is asked to choose a password before anyone has checked they own the account — the form has no key to work with, so it can only refuse.
You never type field names. There is one set of fields, and the flow decides what each is called when it arrives. A field with no meaning in its flow — Remember me on a sign-up form — simply does not render, and says so in the editor.
The password field changes the behaviour
On a sign-up form the Password field is optional, and whether you include it decides what happens:
| With a Password field | The visitor chooses their own and is signed in immediately. |
| Without one | WordPress emails them a link to set a password. This is its default behaviour. |
Add Confirm Password alongside and the two must match. Turning on Show/Hide Button on any password field cuts failed sign-ins on phones considerably.
Where the new password is chosen
The second half of a reset happens after the visitor leaves and comes back from their email. Put the set a new one form in a container and set, in Advanced → NovaKit Display, the condition Visitor followed a password reset link with Show this element. Set the sign-in container to Hide on the same condition, and the page swaps cleanly.
That condition is a real check against WordPress, not a glance at the URL — an expired or forged link reports false and the form never appears.
Save the page, not just the block. That is what records where each form lives, and it is the step people miss. A Global Block on its own is a bare canvas with no address, so it can never be a destination. If no page carries a set a new one form, the emailed link is left as WordPress wrote it and lands on the default login screen.
The reset key never appears in the address bar. On arrival it is moved into a secure cookie and the URL is cleaned — a URL gets copied, shared, logged by the server and leaked through the referrer header, and that URL alone is enough to take over an account.
What signed-in visitors see
A sign-in form shown to someone already signed in is nonsense, so When Signed In defaults to hiding it. Give them something instead: a second container set to NovaKit Display → Visitor is signed in → Show, using the NovaKit User dynamic tags for their name, email and avatar.
Use Account URL → Sign out for the log-out link. A hand-typed logout URL is refused by WordPress, because it needs a security token only that tag can generate.
If the page has nothing else on it, use Page Settings → Signed-In Redirect instead and send them elsewhere entirely.
Test in a private window. As an editor you always see account forms, even when signed in — deliberately, since otherwise you could not see the form you are building.
Putting forms in tabs #
Sign in and sign up on one page, as two tabs, is the common arrangement. Build each form as a Global Block of type Generic, then use them as tab panels.
- Build each form as its own blockOne for sign in, one for sign up, one for the reset request.
- Add NovaKit Tabs to the pageWith Panels set to In This Widget.
- Add one item per formSet Panel Content to Custom Template and choose the block.
- Hide the reset tab from the navigationSet Show in Navigation to off on that item.
That last step is what keeps “Reset password” out of the tab row. Resetting is not a peer of signing in and signing up — it is where you go when you cannot get in — so the row shows two options and the third is reached from a link inside the sign-in panel. The panel is still fully present, just unlisted.
Linking between tabs
Two ways to point a “Forgot your password?” link, both fine:
| Method | Use it when |
|---|---|
| Account URL dynamic tag | Anywhere. It resolves on its own to whichever page carries that form, opening the right tab if it is in one. Move the form later and every link follows. |
A #slug link | From inside the same page. Type the item’s Deep-Link Slug with a # in front, and turn Deep Linking on. |
Display Conditions will not work for this. They are evaluated on the server from who the visitor is, so they cannot respond to a click — swapping two containers that way would need a page reload.
A tab switcher is one arrangement, not a requirement. Separate pages work identically, and the Account URL tag still resolves between them.
Where the message appears #
By default the response lands near the fields. To put it somewhere specific — above the form, beside the button — drop an NovaKit Form: Message widget there. It works for every engine.
The wording stays the engine’s own, so a translation or rewrite in Contact Form 7 or Mailchimp is what visitors see. Under Style → Colours there are separate Success and Error tabs for text, background and border — worth setting when the form sits on a dark section, since the defaults are tuned for light backgrounds.
Testing #
| Test | Expected |
|---|---|
| Submit a contact form empty | Each required field shows its own error, inline |
| Submit twice quickly | One set of errors, not two stacked copies |
| Add a field, save, submit empty | The new field is validated too |
| Newsletter, malformed address | “Please provide a valid email address.” |
| Newsletter, real address | Success, and the subscriber appears in Mailchimp — usually as pending, which is its double opt-in |
| Sign in, wrong password | Back on your page with an error, not the WordPress login screen |
| Sign up, mismatched passwords | An error, with the username and email still filled in |
| Reset link used twice | “That password reset link is not valid.” |
After a successful reset the visitor is not signed in automatically. That matches WordPress: possession of a mailbox is enough to change a password, and a deliberate sign-in is the moment the new one is confirmed to work.
Failed attempts hand back what was typed — except passwords, which are never stored anywhere that outlives the request.
What NovaSpark owns #
| NovaSpark | The engine |
|---|---|
| Layout and markup | Validation rules |
| The field list | Mail settings, recipients, subject |
| Where the message sits, and its colours | The message wording |
| Nothing else | Spam protection, integrations, stored submissions |