Form handleRequest() does not work properly. #8261
Comments
|
the doc does not say that |
|
Okay, but why handleRequest does not handle PUT method? Or it's normal? |
|
I have the same problem. handleRequest does not seem to work with PUT. After handleRequest($request), isSubmitted() is true but isValid() is false even though there are no errors. Same code works fine with a POST. |
|
Confirming the same issue with PUT method In my case isSubmitted() return false. I noticed that in: so handleRequest returns null in line 41. To solve temporarily there are many options:
$myForm = $this->createForm(new MyType(), $myEntity, array('method' => 'PUT'));
basically the value for the hidden input "_method" must match the form method. |
|
I'm having the same issue. The following PUT action controller does not save the new $object (and $form->isValid() incorrectly returns false): But by replacing $form = $this->createForm(new ObjectType(), $object); with $form = $this->createForm(new ObjectType(), $object, array('method' => 'PUT')); the method works as expected. |
|
If you use the |
|
If've the same Problem with PUT! The doc says to use and it should be ok. Hack: |
|
Thanks to the posts here, I don't think this is a bug although I have found it to be a bit confusing. @stof : I have this working okay with the method option but where is the I'm still a little confused about what is the recommended or best practice with |
|
@tetranz sorry, it is not on the Form but on the FormConfig (available through |
but this disallows you to set the method in the twig template (unless you also alter the controller part for every form and action). the method matching check really should be optional (perhaps enabled by default, but optional). |
|
@kor3k Using handleRequest is optional. If you want to do things manually, use |
|
i know, but i'd like to use handleRequest but without the method check. let's say i have three simple actions - put, post, patch - and all three share the same form creation and data persisting logic. then, i set the proper form method in twig. but because of that method check in handleRequest, i must either not use handleRequest, or set the method in the controller (unnecessary overhead). while |
|
@kor3k using a flag to change a behaviour of a method is a bad practice since the flag suggests that a method does more than one thing. As @stof suggested, just use the |
|
Same confusion on Symfony 2.4. Had to set the parameter |
|
Hi, I have some trouble with handleRequest: Here is my code: The problem is that form bind data correctly but form But |
|
@kozborn Could you open a new issue for your problem? Please also create a fork of symfony-standard which reproduces your problem, then we can help you to resolve it much faster. :) |
|
Same problem using
$form = $this
->get('form.factory')
->createNamedBuilder(null, 'my_search_form', new MySearch())
->setMethod('GET')
->getForm();
$form->handleRequest($request);
$form->isValid(); // FALSE
$form = $this
->get('form.factory')
->createNamedBuilder(null, 'my_search_form', new MySearch())
->setMethod('GET')
->getForm();
$form->submit($request);
$form->isValid(); // TRUE |
|
I've been having an issue when trying to update an entity. 1.Fill in form The Strange thing is it works fine in dev mode just not in production, and it's all my forms not just one. I've tried reverting all form views back to standard but has no effect and it's not just my local server it happens on I tried it on my production server also and it still fails. Could this be the same 'put' issue? Will changing put in the action to post solve my issue? I'd try it now but won't be at my pc for a while so searching for the answer now . Synfony2.5 EDIT Changing PUT to POST worked as far as Updating/Editing goes, but now I've moved onto DELETE and again nothing happens? EDIT As the above comment mentions $form->submit($request); instead of $form->handleRequest($request); fixes everything... |
|
@BonnieDoug I don't think you can pass the entire $request to the submit() method, instead of that just the $request->request->get('form_name') array should be submitted. |
|
3 years later and $form->handleRequest($request) followed by form->isValid() still returns false with no error message at all if you use PUT without also having created the form with PUT method. Nowhere to be seen in the docs. Wasted 2 hours on this. |
|
@mote0230 this is a closed issue. Please open a new one if you think there's a bug and you'd like to report it. Don't forget to explain how to reproduce it. Best if you provide code example (i.e. fork of the standard edition and modify it to demonstrate the problem). If you think there's anything we could improve in the docs, create an issue (or better a PR) for https://github.com/symfony/symfony-docs. Thanks. |
|
Agree with mote0230, nothing here has fixed my problem either. I found that for me, I had manually coded the form and my token was causing isValid() to fail. Using Symfony's built in twig form generator with the auto generated form type got everything working again. |
|
well IMHO the biggest problem here is it fails silently. users must spend time to investigate what went wrong and that's just a PITA. to solve this, the handleRequest should behave like this:
|
|
Hey @kor3k, fist from my point of view, saying that Handle request just call a It happens that the default handler just submit the form method matches the request one. If one needs a different behavior, no need to wait for a new feature, just use a custom handler. |
|
@HeahDude well, it does fail silently because it does not tell the reason why it did not submit the form. and the reason and behavior is hazily documented.
but it's not obvious, you have to investigate. the fact that it still bothers people means it's at least unintuitive. |
|
also, why does the form have default method set to POST? why not make it method agnostic (null)? the use case like using one specific form with different methods (controller actions) is IMHO quite common. but because of handleRequest's behavior, you cannot just set the form method and action in a view, you need to set the proper form method in a controller for each http method, which is a unnecessary overhead for no reason (from my POV). why cannot handleRequest/form be method-agnostic? where null means any method is accepted and valid? (or via some other way to achieve this) |
What about the possibility to do: public function someAction(Request $request)
{
$form = $this->createForm(SomeType::class, null, [
'method' => $request->getMethod(),
]);
}? |
|
Funny that this get bumped today, as earlier i read a somewhat similar bug and handling (or lack of handling) brianc/node-postgres#1200 Countless manhours continue to be wasted. |
|
The reason for me why the form is not submitted is because of this line: at vendor/symfony/symfony/src/Symfony/Component/Form/Extension/HttpFoundation/HttpFoundationRequestHandler.php:101 |
|
Compose email
…On Jul 12, 2017 12:12 PM, "Abdessamad Idrissi" ***@***.***> wrote:
The reason for me why the form is not submited is because of this line:
// Don't submit the form if it is not present in the request
return;
at vendor/symfony/symfony/src/Symfony/Component/Form/
Extension/HttpFoundation/HttpFoundationRequestHandler.php:101
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#8261 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AOXMGAzoE0N3v7r0RHwemynXtOq5rdArks5sNPB6gaJpZM4Auscn>
.
|
|
@HeahDude unnecessary overhead. consider this: you have CRUD controller and for every action you use the same form type and the same form options. so you create a function like MyController::createForm( $data ), which provides the form for every CRUD action. the only difference is the method, so you set the method in twig. but because of HttpFundationRequestHandler behaviour, you can't. only if you comment out the line @numediaweb mentioned or do overhead code as you proposed. as i said, instead of defaulting the method to POST, HttpFundationRequestHandler should default to null. and when the method is null, then every method is accepted (not checked). |
Sounds wrong to me. A built Form instance is strictly configured, so configuring it in a template only is a bad idea as it leads to such issue, the FormView is here to carry this out. Btw, this is also why I think buttons should always be part of the Form tree and not be hardcoded in templates (in addition of levering nice features for them: clicked state, theming ...).
This is not possible since the method defines the submission behavior (whether to ignore missing fields), so POST must remain a default value (which is also the default for the html attribute). |
but what is the use case for setting the form method in twig then?
good point. but i must admit, this would be confusing. the same way current fail-silently behavior is. so when this method-mismatch fail occurs, it should be at least logged at warning/error level. |
|
Upgraded from 2.8 to 3.4 and wasted some hours on this. Why is this not mentioned in the upgrade guide? It's definitely is a BC. |
|
Would you mind sending a PR against branch 2.8 doing so? |
|
I can do that! Problem is I'm still not quite sure why this is an issue exactly but I was able to fix it for my project. A small notice on how to fix this should be no problem. Correct me if I'm wrong, but shouldn't this be part of this file? https://github.com/symfony/symfony/blob/3.0/UPGRADE-3.0.md |
|
This file yes, it exists on branch 2.8 also. |
|
@nicolas-grekas Please see pending PR: #27500 |
…quests (fnagel) This PR was merged into the 2.8 branch. Discussion ---------- Add note about changed form processing when using PUT requests | Q | A | ------------- | --- | Branch? | 2.8 and up? | Bug fix? | no | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | License | MIT Added a note about changed form processing when using PUT requests as people still struggling with this change. Documenting it should help people to quickly fix this without struggling why some of their forms won't work any more after upgrading. See #8261 Commits ------- 140b6c2 Add note about changed form processing when using PUT requests
|
If you are using submit in as the second parameter in |
From symfony docs:
I'm confused with form binding. In docs says that submit method is deprecated, but when I generate CRUD with symfony generator, it puts bind method for form handling. In code above bind method placed comment that contains next:
So, two functions was deprecated? Okay, when I use handleRequest in my controllers it does not work with forms submitted with PUT method. What method will correctly use for form handling?
The text was updated successfully, but these errors were encountered: