| Project: | Panels |
| Version: | 7.x-3.x-dev |
| Component: | Documentation |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | postponed |
Issue Summary
Hello everybody,
I found a bug in form api on building the $form_state['values'] for checkbox that persist in the form array but it isn't exists in POST.
I have the following scenario:
I have a node form build with panels. We do not render the publish checkbox and some additional checkbox fields that are available on other form. On submit of this form the form api try to get the default values of the elements that doesn't exists in the POST but exists in form array. On submit we get a strange behavior that all checkboxes are reset to 0. After a small investigation we found the problem.
It is in function form_type_checkbox_value($element, $input = FALSE). The $input parameter in our case is NULL and we always get 0 as value. We build a workaround for this (see the attached file) until we have it fixed in core.
I hope this can help somebody :).
| Attachment | Size |
|---|---|
| form.inc_.patch | 525 bytes |
Comments
#1
Hi there, thanks for your report, but this is not a bug. Checkboxes that are not checked are not submitted at all by the browser, as described, in length, in the precise same function you hacked.
If a checkbox is in the form array (and is accessible), it has to be rendered or it is going to be submitted unchecked.
#2
Hi,
Yes, I agree with you.
This issues should be related to panels node form plugin with not rendered checkboxes.
Thanks for the fast response.
#3
Hi Team,
This is a tricky issue that I think we should think for a solution.
The core team is absolutely correct regarding their comment and the core function is correct.
#4
I don't see anything about a node form here.
What are you talking about?
#5
If you see my comment above read the scenario (I hope it is clear :) ):
The issue is the following:
If we are using the panels functionality to overwrite or create a new node edit form and for example we want to hide the status checkbox. Everything is great until you save the form and you received the status "Not published". This is because (as Damien Tournoud explain above) by default the browser do not send the unchecked checkboxes in POST. However in Drupal handle this by checking if the element is in the form array and if it is NOT in POST. If the element is in the array and it is not in POST then it seems that the user unchecked it and they add a 0 value to it.
However by enabling the users to add only specific node form elements in panel if you don't render the checkboxes you will reset them on submit.
I hope it is more clear now. Please if you cannot understand me please write me and I will try to explain it with other words.
#6
@skek So what you mean is that if, for example, the "Published" checkbox is not part of a custom node_edit form, then the node will be saved as "published === false", regardless of what it's previous state was?
#7
Yes, exactly.
#8
Meh, sounds nasty. I will try to confirm it myself.
#9
Panels doesn't allow you to *remove* elements from the node form. If elements are being removed there are two possibilities:
1) You have some code which is removing it yourself which is faulty
2) You did not put the "General form" pane in to render the rest of the form, which is needed for forms to work.
#10
@merlin As I understand it, the situation is number 2. Then I take it that this behaviour is simply not supported on the core level?
#11
@skek
My interpretation is that the behaviour comes from Core, and that Panels just does not alter it. What you should probably do instead, is set 'access' => 'false' on the fields you don't want to show up. Or this could be turned into a feature request, but that really seems to belong on the Core level.
#12
HI Guys,
I've made a module that fix this issue by extending the checkbox element.
I've test it and it works correctly.
I'm attaching the module to this issue but fill free to contribute it if you want.
It will be good if somebody can make some testing.
#13
Keeping it open an assigned to myself as it could be interesting in the future to take a look at.
Thanks skek :)
#14
I'm pretty sure that if you're using option #2 (not putting in the "general form") there are other things that will be wrong. You'll be missing form ids and form tokens and stuff. Panels is absolutely positively NOT means to be able to arbitrarily remove items from the form.
#15
I would honestly have thought it worked to do that. Will need to get that into docs. :)
#16
I believe a lot of people thought the same, @letharion, me included. Should we move this "bug report" into a "feature request"?
#17
@hiphip, perhaps it should be a feature request, but not against Panels. It's Core's Form API that doesn't support taking the form apart in this way.
Panels unfortunately makes it possible to break the form through the UI, and maybe that should be handled better, but we're not going to implement this in Panels, when it belongs in Core.
#18
It's ok with me that Core's Form API doesn't support taking the form apart in this way. But the fact is that Panels allows this. So, it seems desirable to me that Panels allow us to do it also in a safe way.
If you agree this is a "nice to have" request, the solution, within Panels, wouldn't be a problem. I'm thinking in a very straight forward way which, I believe, would resolve the situation: Give an additional option (plugin) such as "general form with default/pre-saved values" and whatever form's fields that aren't shown, define their #access = false . Would that be nice?
#19
Please post that as a separate feature request, and I'll ask merlin to take a look at it :)
#20
Great, thanks! The Feature request is now here!