Special characters in keys of a page.header.form

1

Bonjour all,

I am creating a form that works as desired, but I wonder whether having the keys starting with a “&” might pose problems at some level (Grav, different browsers/environments…).

The form is redirecting to an url that includes data entered in the form by the visitor through a

            name: sort_choice
            type: radio
            label: 'Sort & filter'
            default: markdown
            options:
                &sort=distance: 'Nearest'
                &filter=date_lbl%253D90: 'Date'

(note that the keys start with “&”)

and the form action

redirect: 'https://example.com?test={{ form.value.sort_choice|e }}'

I wish the resulting url to be:

https://example.com?test=&sort=distance

but it comes out as:

https://example.com?test=&sort=distance

I also tested escaping the “&” in the Yaml with percent encoding “%26”:

            options:
                %26sort=distance: 'Nearest'
                %26filter=date_lbl%253D90: 'Date'

and the url comes out as:

https://example.com?test=%26sort=distance

Both work fine on my local site but it feels weird… Is this safe in all environments to have a “&” in the key?

Tks.

2

Having such field names is so wrong… :exploding_head:
I’m not even sure what to suggest here, but one thing I’m certain about - you definitely need to change that logic and change how form is processed on the submit endpoint

1 Like
3

You confirm my feeling…
I checked in grav/admin/tools/logs and there is no error on this.
Before redirection, the form is correctly saving the form content in my user/data folder and it contains the field content as shown in the url. So all works as intended on my local Mamp installation.

Is this going to break when in production, wreak havoc in my hosting company’s infrastructure??

Can the key be escaped or encoded to safen the process(es)?

4

As seen on Processing Twig in Page Frontmatter?, I tested:

options:
                '&sort=distance': 'Nearest'
                '&filter=date_lbl%253D90': 'Date'

It works as good. Would this be acceptable?

5

I honestly don’t know what implications it might have on different server configurations. Probably none, but this is still so wrong.

May I ask what’s the use case of such names? Why can’t it be something like this?

            options:
                sort-distance: 'Nearest'
                filter-date-lbl-3D90: 'Date'
6

@red,

The filter |e tells Twig to escape the string before outputting it (btw. escaping is already the default behaviour).

Hence your result:

https://example.com?test=&sort=distance

When using:

redirect: https://example.com?test={{ form.value.sort_choice | raw }}

The result is:

https://example.com/?test=&sort=distance

Note:

7

Thank you both for your answers.
@pamtbaau I simplified the url, a little too much :blush:, for the example. I am actually using an url as given by an external website which is formated as MDN.
I changed to |raw and result is as you explained.
I am keeping the keys as '&sort=distance'.

@Karmalakas The names I am using for the keys are the one I need to add inside the url of the external redirect website. When visitors select the “date” option, this will add &filter=date_lbl%253D90 inside the redirect url. This parameter is decided by the external website and twig operations cannot be done inside the redirect url. Visitors will arrive on the external website with some sorting and filtering of results already done.
I will check if the special characters will still work in production.