Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

'search_terms' in POST data #1049

Open
divan opened this issue Aug 5, 2022 · 11 comments
Open

'search_terms' in POST data #1049

divan opened this issue Aug 5, 2022 · 11 comments
Labels

Comments

@divan
Copy link

divan commented Aug 5, 2022

Describe the bug
When choices.js is used in the form, it submits also data for search_terms.

To Reproduce
Steps to reproduce the behavior:

  1. Create demo form with choices input (without disabling search)
  2. Submit data
  3. Check payload in Dev Tools or on server
  4. See search_terms in the post data

Expected behavior
No "search_terms" value got to the form.

@divan divan added the bug label Aug 5, 2022
@michaellatham
Copy link

This was particularly frustrating as the name of my input was previously 'search_terms', so was being overridden. Re-naming fixes it, but still the unwanted post data is there.

@masiorama
Copy link

I have an issue with search_terms naming too, but with GET.
In my scenario, I have 7 multiselect fields with choices.js which work as grid filters which has to work in GET (there are a few reasons to prefer this to POST).
This means that when I trigger the search via clicking the search button, I end up having 7 &search_terms= concatenated in the query string.

I tried to completely remove the name attribute from the compiled choice.js input, and this way the query string is obviously correct.
From what I can tell, the solution could be to do exactly that (although I know it would be "bad" html5; https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input#name), even if in my opinion those fields should not be included in the form since their job is merely to make the js code work (which does not rely on that attribute), from the point of view of the request.

Any considerations about this matter?

@masiorama
Copy link

Did anybody find a solution about this?

@masiorama
Copy link

Sorry to bother again but I would like to know if this could be fixed somehow (I could make a pull request but I would like to discuss which is the best way to solve it without breaking anything).

@Guzzii
Copy link

Guzzii commented Feb 26, 2023

I got the same issue. It looks like a regression since release 10. Downgrading to 9.1.0 fix the issue for me.

@boccoadam
Copy link

Also having this issue. For php name can be set to empty string and will be ignored:

callbackOnInit: () => {document.getElementsByName('search_terms')[0].name = '';}

Not very helpful if you already have one on the page though, config to disable this would be nice.

@joffreypersia
Copy link

Up please

@lavgl
Copy link

lavgl commented Jul 10, 2023

up

@natebeaty
Copy link

natebeaty commented Nov 26, 2023

Fwiw, this caused all sorts of problems on a few sites of mine after updating. It took me quite a while to figure out where this new search_terms POST/GET var was coming from. I also rolled back to version 9.

@bupy7
Copy link

bupy7 commented Jan 20, 2024

As another option:

callbackOnInit: function () {
  this.input.element.name = ''
}

@middaparka
Copy link

Definitely a +1 in terms of this being purged from the form data, or at least made optional.

It also breaks if there's multiple Choices.js instances active within the same form, as they each use search_terms, so the name should be configurable if it's enabled.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

10 participants