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 two columns build their own.
| Feature | Shopware built-in | Paid plan (Rise) | 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 (Rise) | 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 (Rise) | 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 (Rise) | 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 | yes: product page, below the buy box and collapsed |
| 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 (Rise) | 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 v2 and v3 | yes: plus Friendly Captcha | partly: honeypot, basic, reCAPTCHA v3 from the core; not reCAPTCHA v2, not Friendly Captcha |
What it costs
Prices read from the store listing. The store is what counts.
| Feature | Shopware built-in | Paid plan (Rise) | 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 three columns come from
Paid plan (Rise)
The same core plus Shopware's paid plugin, as in the Rise plan. Its list of licensed features is readable in the source and contains not one form-related entry. It adds a fifth CAPTCHA: Friendly Captcha.
Form Manager
This plugin. Every entry in this column appears on one of the pages of this site and is evidenced there against the plugin's source.
From Evolve: CMS extensions
From the Evolve plan on, the extension “CMS extensions” comes along, and with it a form builder: groups, field width, required fields, recipients and mail template, six field types. It has no column of its own here; what Shopware writes about it is below, with the sources.
When the built-in tools are enough
Three cases in which a plugin 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. A plugin does not replace it; it stands next to it, for the cases that fixed fields do not cover.
Three questions for any form plugin
The Shopware Store holds more than eighty plugins 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.
Sources: what Shopware itself writes, and what merchants ask
Quoted word for word, with the source. The table above rests on the source code; here is what Shopware says about it in public and what gets asked in the forum.
Shopware has custom forms from Evolve on
The Shopware documentation says: “For creating your own form, you need the extension "CMS extensions". This is part of the Shopware Evolve plan of Shopware 6.” The guide names six field types: text, email, number, selection field (a checkbox), selection and text area. File upload, fields that depend on others and a store of the submissions do not appear in it. Source: Shopware documentation, Create individual forms.
The core form goes out as an email
On the form block of the shopping experiences the documentation says: “The contact form is sent to the shop operator by e-mail after it has been filled in by a shop visitor.” That is the row “The submission is stored” in the table above: what sits only in an email cannot be listed or exported later. Source: Shopware documentation, Shopping Experiences.
What the core source code holds
The core ships four CAPTCHAs: honeypot, basic CAPTCHA, Google reCAPTCHA v2 and v3 (Framework/Captcha on GitHub). The plugin validates three of them, not reCAPTCHA v2. The form element knows three types: contact, newsletter and revocation (form-types). Salutation, email, subject and message are always required; first name, last name and phone become required through the basic information (ContactFormValidationFactory).
What gets asked in the Shopware forum
The thread “Kontaktformular anpassen” (customising the contact form), with more than 20,000 views, opens with the question (translated from German): “how can I customise the contact form? Remove fields or make them not required?” (Shopware forum, German). In another thread someone writes (translated): “The documentation does say that you can also add your own forms through the shopping experience, but I do not have that option.” One answer below it: “The form builder is probably only possible from Evolve on.” (Shopware forum, German).
And the law: § 356a BGB requires a withdrawal function for distance contracts concluded through an online interface, labelled “Vertrag widerrufen” (withdraw from contract) or an equivalent wording. That is what the third type of the core form is for; what it does and does not do is on the page about the withdrawal button.
Sources
- Shopware documentation: Create individual forms
- Shopware documentation: CMS extensions
- Shopware documentation: Shopping Experiences
- Shopware: pricing and features of the plans
- Shopware source code: the core CAPTCHAs
- Shopware source code: types of the form element
- Shopware source code: required fields of the contact form
- Shopware forum: Kontaktformular anpassen (German)
- Shopware forum: Eigene Formulare erstellen, Form-Builder (German)
- German Civil Code, § 356a BGB: electronic withdrawal function (German)