Forms
Audience: Editor.
PageCraft builds forms visually and posts them to its own endpoint, which emails the submission. No third-party form service, and no EE channel-form template code.
The short version: insert a Form block, edit the fields with Edit Form, and set who gets the email with the Form Delivery button on the section toolbar — not in the form's own Settings tab.
Adding a form
Click the + between sections and choose FORM. You get a starter form — name, email, message — that you then edit.
The form is written into the page's HTML, so visitors see it immediately and search engines can read it.
Editing the fields
Select the form and click Edit Form. The form builder opens with four tabs:
| Tab | What you set |
|---|---|
| Edit Form | the fields themselves — labels, types, order, required |
| Settings | the success and error messages, and the reCAPTCHA site key |
| Designer | the form's colours and typography |
| Workflow | AI steps on submit — not enabled in PageCraft |
Field types include short and long text, email, phone, number, dropdown, select, multi-select, switch, slider, date, time, URL, colour and file upload.
Where the submission goes — the Form Delivery button
This is the one that is easy to miss. Notification Email and Redirect URL are not in the form's Settings tab. They live on a Form Delivery button — the blue envelope icon at the bottom of the section toolbar, the vertical strip of buttons on the right edge of the section.
It appears on any section containing a form. Two fields:
- Notification Email — who receives this form's submissions. Leave blank to use the site-wide default.
- Redirect URL — where the visitor lands after a successful submit. Leave blank to show the success message on the page instead.
They are deliberately not in the vendor's Settings tab: keeping PageCraft's additions outside the form plugin's own files is what lets that plugin be replaced wholesale on every ContentBox upgrade without a merge conflict. The trade is that the two settings live one panel away from the others.
Who actually receives the email
Resolved in this order, first match wins:
- The form's own Notification Email (Form Delivery button)
- Global Settings → Default Form Notification Email
- The site's
webmaster_emailfrom EE's own settings
The per-form address is encrypted server-side before it reaches the page, so it never appears in page source and a crafted submission cannot redirect a site's form mail somewhere else.
What the redirect does
Setting a Redirect URL switches the form to a standard browser submit, and the server answers with a redirect — so the visitor leaves the page and the success message never appears. That is usually what you want: send them to a thank-you page.
Leave it blank and the form submits in the background, staying on the page and showing the success message from the Settings tab.
Redirects are restricted to your own site. An off-site URL is rejected.
Spam protection
Two layers, both on by default:
- A honeypot field. Every form renders a decoy field that real people never fill in. A submission that fills it is discarded silently.
- reCAPTCHA v2, optional. Put the secret key in Global Settings → reCAPTCHA v2 Secret and the site key in the form's own Settings tab. Both are needed — one without the other does nothing.
Two form blocks, and which to use
Sites upgraded from PageCraft 1.x may contain forms built with the older Form Builder block. Both still work, but they keep their settings in different places, which is the usual source of confusion:
| Where fields are edited | Where delivery is set | --- | | --- | --- | Form (current) | | Edit Form button | Form Delivery button on the section toolbar | Form Builder (classic) |
The classic block is no longer offered in the picker. Use Form for anything new.
Converting an old form
Existing classic forms are migrated with a script rather than rebuilt by hand — fields, labels, types, validation, the notification address and the redirect all carry across:
php system/user/addons/page_craft/scripts/convert-classic-forms.php <ee-root>
That is a dry run and writes nothing; it reports what it would change. Add --apply to convert, which backs up every original value first and prints the backup location.
Afterwards, open each converted entry once and save it. That regenerates the copy of the form that visitors see before JavaScript runs — a server-side script cannot produce it. The form works either way; without that save it is simply missing from the page source.
Troubleshooting
The Form Delivery button isn't there. It only appears on sections containing a current-style Form. On a classic Form Builder block, the settings are in the block's own Settings tab instead.
No email arrives. Check the resolution order above — with no per-form address and no global default, it falls back to EE's webmaster_email, which may not be a mailbox anyone reads. Check EE's own email settings and the Developer Log.
Submissions stopped after an upgrade. Submit the form yourself and watch for the redirect. A form that silently stops emailing looks completely normal from the outside, so test it rather than assume it.
The form shows briefly then disappears, or appears empty. The form is rendered by the ContentBox runtime; make sure {pagecraft_scripts} is present in your template.