forms icon indicating copy to clipboard operation
forms copied to clipboard

Future forms configuration

Open I-Valchev opened this issue 4 years ago • 7 comments

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: ...

I-Valchev avatar Jan 15 '21 10:01 I-Valchev

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.

bobdenotter avatar Jan 15 '21 10:01 bobdenotter

Some other things to at least consider:

  • should there be a standardised way to select forms that belong to a page?
  • from builder?

I-Valchev avatar Feb 01 '21 14:02 I-Valchev

Also: https://wpforms.com/features/

I-Valchev avatar Feb 08 '21 13:02 I-Valchev

  • 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 avatar Feb 11 '21 08:02 I-Valchev

@I-Valchev as we discussed, it might be good to have it in the list as well:

  • Easy way to override default Boltforms CSS.

nestordedios avatar Feb 17 '21 10:02 nestordedios

  • Make the type: date, type: datetime and type: dateinterval easier 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: false etc..

I-Valchev avatar Feb 23 '21 09:02 I-Valchev

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

ghost avatar May 05 '22 10:05 ghost