forms
forms copied to clipboard
Future forms configuration
Hi all
Here's a suggested configuration for a future major release of bolt/forms. Please provide any feedback that you may have!
## This is default, all forms inherit from here.
default:
csrf: true
honeypot: true
spam-action: mark-as-spam
template: '@boltforms/form.html.twig'
layout: 'form_div_layout.html.twig'
captcha:
repatcha: ...
hcaptcha: ...
contact:
csrf: false # here you can override any of the default config
attr: ?? # Add attributes to form itself?
content:
step: 1
fields: ... # Same as current form
on_submit:
save:
contenttype:
name: ..
field_map: ...
table:
name: ...
field_map: ...
email: # the email is a list, allowing you to send as many emails to as many recipients as you like
- subject_template: ...
body_template: ...
recipients: [ [email protected], {FROM_FIELD} ]
cc_recipients: ...
bcc_recipients: ...
attach: [ name of file fields to attach ]
action:
redirect: ...
messages:
success: ...
error: ...
Some other pitfalls we'll need to avoid if we're going to refactor this and introduce breaking changes:
- the fields configuration (and primarily the "options" and its "attr" flags) are clearly designed for people who write code, and are not user friendly for end-users who merely want to implement a form. To a large extent this is unavoidable, but we can document it better
- We should be able to add attributes to the form itself. Like being able to influence the class/id of the form, without having to override the complex Symfony form templates.
Some other things to at least consider:
- should there be a standardised way to select forms that belong to a page?
- from builder?
Also: https://wpforms.com/features/
- It should be easier, or at the very least documented, how to override the HTML rendering of a specific field, of a field type, etc. Symfony allows that by extending templates and overriding blocks, but given the extra layer of abstraction that is
bolt/forms, it is difficult.
@I-Valchev as we discussed, it might be good to have it in the list as well:
- Easy way to override default Boltforms CSS.
- Make the
type: date,type: datetimeandtype: dateintervaleasier to configure in terms of how it is rendered... Right now, to render a date with the standard datepicker, it looks like this:
date_of_birth:
type: date
options:
widget: single_text
Would be much better to have something that is human comprehendable, for example:
date_of_birth:
type: date
variant: datepicker
- More generally, see if we can provide "shortcuts" to common symfony/forms options (radio buttons, checkboxes, etc.) rather than asking people to set stuff like
multiple: falseetc..
Id like a speedlimit key for forms as an antispam countermeasure. Most spam messages are sent within 100ms. I'd like to set individual limits for each form for the minimal interval between page request and form submission. speed violations should result in a block.
On top of this i would prefer a more granular spam protection rather than none/block/mark-as-spam as a global result for all . For example we can be pretty sure, a filled honeypot must be a robot and should be blocked. broken csrf tokens are also garbage and should be blocked. a v2 recaptcha produces a boolean which should be blocked a v3 recaptcha produces a float which should likely have a minimal threshold resulting in a block (ie: 0.3) and also a minimal value resulting in mark-as-spam threshold (ie:<0.7)
lumping csrf, honeypots together with the v3captcha is far too crude in my humble opinion.
on a less related sidenote spam protection may warrant its own key in the config:
spamfilter:
csrf: block #block/mark/none/false
honeypot: block #block/mark/none/false
speedlimit:
time: 100 #minimal required wait in milliseconds between page request and form submission
action: block #block/mark/none/false
captcha:
privatekey: #YOUR_PRIVATE_KEY
sitekey: #YOUR_SITE_KEY
hcaptcha: block #block/mark/none/false
recaptcha_v2: block #block/mark/none/false
recaptcha_v3:
blockbelow: .3 #float between 0-1 inclusive
markbelow: .7 #float between 0-1 inclusive