Shopware built-in
The core's "form" CMS element, read in the source: three types, five settings, fixed fields in the template, no storage.
Shopware 6 forms compared
Four columns, six tables. Six rows do not go our way - that is not an oversight, it is why a comparison is worth anything at all.
What you can ask for
The core has seven fixed fields. The other three columns build their own.
| Feature | Shopware built-in | Paid plan | Form Manager |
|---|---|---|---|
| Number of input types | no: seven fixed fields | no: seven fixed fields | yes: 23 types |
| Text, multi-line, email, phone | yes: exactly these, fixed | yes: exactly these, fixed | yes: all four |
| Dropdown, single choice, multiple choice | no: no choice fields | no: no choice fields | yes: all three, with a default |
| Number and slider | no: not provided for | no: not provided for | yes: both, with minimum, maximum, step |
| Date, time, date + time | no: not provided for | no: not provided for | yes: all three, with range and grid |
| File and image upload | no: no upload field | no: no upload field | yes: both, into the media manager |
| Colour picker | no: not provided for | no: not provided for | yes: with a default colour |
| Password field | no: not provided for | no: not provided for | no: not available here |
| Salutation and country from Shopware master data | partly: salutation yes, country no | partly: salutation yes, country no | yes: both, without a second list |
| Consent as its own type | partly: a fixed privacy notice | partly: a fixed privacy notice | yes: its own type, named for the purpose |
| Content elements: heading, free text, messages | no: only the element's own headline | no: only the element's own headline | yes: eight, four of them message kinds |
Structure and layout
Here the difference is not yes or no, but what the width hangs on.
| Feature | Shopware built-in | Paid plan | Form Manager |
|---|---|---|---|
| Groups with their own heading | no: not provided for | no: not provided for | yes: become a fieldset and a legend |
| Several fields side by side | partly: a fixed split in the template | partly: a fixed split in the template | yes: width per field |
| Different widths within one row | no: not provided for | no: not provided for | yes: twelve-column grid, e.g. 3 + 3 + 6 |
| Number of columns per screen size | no: not provided for | no: not provided for | partly: one width; when narrow the storefront wraps |
| Changing the order | no: fixed order | no: fixed order | yes: sort arrows in the tree |
| Your own CSS class per field | no: not provided for | no: not provided for | no: not available here |
| Labels per language | yes: through the snippets | yes: through the snippets | yes: label, placeholder and options |
Fields that listen to fields
The point at which a form differs from a list of fields.
| Feature | Shopware built-in | Paid plan | Form Manager |
|---|---|---|---|
| One field depends on another | no: not provided for | no: not provided for | yes: on every element |
| A condition on a whole row or group | no: not provided for | no: not provided for | yes: takes everything inside along |
| Operators | no: not provided for | no: not provided for | yes: twelve, depending on the source type |
| Without reloading, and the server checks again | no: not provided for | no: not provided for | yes: in the browser and again before validation |
Where the form may appear
All of them can do shopping experiences. After that it thins out.
| Feature | Shopware built-in | Paid plan | Form Manager |
|---|---|---|---|
| Shopping experiences | yes: one element, three fixed types | yes: one element, three fixed types | yes: block and element |
| As a popup or in a new window | no: not provided for | no: not provided for | no: not available here |
| Product detail page | no: only through the page's shopping experience | no: only through the page's shopping experience | yes: three positions, three display modes |
| Order in the customer account | no: not provided for | no: not provided for | yes: order list and order detail |
| Different forms per product | no: not provided for | no: not provided for | yes: assignment with priority and rule |
After submitting
Two columns send an email and are done.
| Feature | Shopware built-in | Paid plan | Form Manager |
|---|---|---|---|
| The submission is stored | no: event and email, no table | no: event and email, no table | yes: with values and labels |
| History with context in the admin | no: nothing to see | no: nothing to see | yes: form, context, customer, channel, date |
| Export | no: nothing to export | no: nothing to export | yes: CSV, deleted forms included |
| Email to a fixed address | yes: through a flow | yes: through a flow | yes: a switch and an address on the form |
| Setting the sender as reply-to | depends on the flow's mail template | depends on the flow's mail template | no: not available here |
| Email blacklist against spam | no: not provided for | no: not provided for | no: not available here |
| CAPTCHA | yes: honeypot, basic, reCAPTCHA v3 | yes: plus Friendly Captcha | partly: the three from the core, not Friendly Captcha |
What it costs
Prices read from the store listing. The store is what counts.
| Feature | Shopware built-in | Paid plan | Form Manager |
|---|---|---|---|
| Base price | included in the shop | from the paid plan up | basic function free |
| What costs more | nothing, there is nothing more | the whole plan | more forms and elements |
Where the four columns come from
Paid plan
The same core plus Shopware's paid extension. Its list of licensed features is readable in the source and contains not one form-related entry. It adds a fourth CAPTCHA.
Form Manager
This extension. Every entry in this column appears on one of the pages of this site and is evidenced there against the plugin's source.
When the built-in tools are enough
Three cases in which an extension adds nothing.
One contact page, nothing more
Whoever needs one contact page and gets by with salutation, name, email, phone, subject and message is done with the built-in element. It costs nothing and is placed in two minutes.
Newsletter sign-up
The newsletter type leads into the recipient list including double opt-in. That is a process of its own, not a form - and rebuilding it would be a mistake.
The revocation form
The third type covers the case the law provides for. Nothing further is needed for that either.
The core contact form
A form you built yourself
On the left seven fields that sit in the template. On the right eight somebody chose - two of them produce two inputs each. The same storefront, the same building blocks.
The element stays where it is. An extension does not replace it - it stands next to it, for the cases that fixed fields do not cover.
Three questions for any form extension
The Shopware Store holds more than eighty extensions on the subject of forms. One of them is in the table above; the rest differ widely, up to builders that come with separately paid add-ons for product enquiries, order fields and multi-step forms. Rather than listing them all, here are the three questions you can put to any of them. This one included.
- 01 Can a field listen to another? Without conditions every form grows as long as the sum of all cases. Ask: which elements may carry a condition, a whole row included? And does the server check them again?
- 02 Where may the form appear? A shopping experience is within reach for many. It gets interesting on the product page and on the order: does the reference come along automatically, and can you control which product gets which form?
- 03 What happens after submitting? An email is not an archive. Ask: is the submission stored, can it be exported - and what becomes of old submissions when the form changes or disappears?
And if you want to build it yourself
Your own form in Shopware is no black art: a template, a route, some validation, a mailer. For a form that is built once and never changed, that is an honest route.
The effort starts with the second form, and starts over with the third. On top comes everything that happens after submitting: storing, listing, filtering, exporting, translating.
The question is not whether you can build it, but who changes it in two years. A form in the administration is changed by the person who writes the text. A form in the source code is changed by the person who maintains the source code.
How you notice that the time has come
The reply starts with a question
If every request is first met with "which order is this about?", the form is missing a field - or the context.
There are already three contact pages
One for advice, one for complaints, one for resellers - because a form with fixed fields covers only one case.
Nobody knows how many there were
If "how many requests came in last month?" can only be answered by searching a mailbox, the history is missing.
One field is often left empty
A field half the people skip usually does not belong away, but behind a condition.