Single on/off checkbox and Check boxes/radio buttons CCK widgets
christopher_skauss - January 1, 2009 - 09:15
| Project: | editablefields |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
Description
Hello and thanks for the great module!
I am using drupal 6.8, and CKK current dev, and while Single on/off checkboxes appear editable(they gray out for an instance when you press the checkbox) they neither do change status nor is the change being stored. Any clues? Thanks!
#1
Looks like your using the 'dev' code - could you try using the 6.x.1.1 version, just to see if it's a bug I've just introduced, or not?
I assume you have permissions to edit the field etc? :-)
Cheers
Mark.
#2
Tried with 1.1 release, problem persists. Permissions are set ok.
The problem is both with Firefox and IE7. Internet explorer is just popping up these messages:
"an error occured at ?q=/editablefields_html/6/field_task_completed"
The same goes for radio buttons, as in "check boxes/radio buttons" cck widget. The only thing I've tested and works so far is the "select list" and the "textarea" widget .
#3
OK, I'll look into this again :-)
#4
Thank you for your quick response! i appreciate it!
#5
Thanks Christopher for finding this problem....
So, if the check box has only 1 value, then it seems - even for a normal field, you can's select the tick box and save, it just stays unselected....
So, you need two values... fair enough... whats the use otherwise :-)
With 2 values, everything seems to work fine.... or at least, when the node is saved with the checkbox unticked, everything is fine, and you can use editable fields to 'tick' the checkbox, and the node is saved... all is fine.
The interest comes when you try and untick a checkbox.
Seems like the serialized data from serialize() doesn't give any values for the unselected checkboxes!
You can see that here:
http://docs.jquery.com/Ajax/serialize
Now, interestingly, this means that for multiple checkboxes, so long as you are not unchecking the last checkbox, you will actually be OK, and radio's should work fine.... but...
I was relying on some data being sent, however, I've changed things a bit, and the CVS now has a working version I believe. - Again, feedback MUCH appreciated....
Again, I'd like feedback. Please not, the CVS head required the very latest CCK (from the CVS as well)....
Until CCK is released, I wont release editablefields, but this means others may find this bug in the released packages until then.
Cheers
Mark.
#6
Still happens, before and after applying the patch in #352884: Clean up and fixing coding standards
It also happens an issue when you have an optionwidgets element with unlimited number of multiple values, rendered as checkboxes. The problem is that the formatter is called for each option. If there is no option is enabled in the database, then no widget is generated. If one option is enabled, then you get one widget, but if you have more options enabled, then you have a lot of widgets rendered.
This kind of problems may also happen with CCK fields that manage their own multiple values. Being the more complex scenario when the multigroup module is involved.
I believe the problem is using a div in the formatter to trigger the element form generation. A second problem comes by the fact that using drupal_execute using the $_POST array is not equivalent to sending a form. There may be situations, like the one happening with checkboxes because the browser does not send them when unchecked. There may be other problems that the FormAPI solves using value callbacks. And again, the more complex situation when the multigroup module is involved.
#7
Markus, can you confirm that the code in the CVS fixes the problem - I think the problem was related to an assumption about hoe serialize worked.... I think it should be fixed now... please advise?
cheers
Mark.
#8
Nope. The code in CVS does not fix the problem, and so I did not fixed in the lastest patch in #352884: Clean up and fixing coding standards
If you apply that patch, then try this mini-patch on that:
<?phpif (node_access('update', $node)) {
+ if (!isset($_POST[$field_name])) {
+ $_POST[$field_name] = array('value' => NULL);
+ }
$form_state = array('values' => $_POST);
?>
That fixed the problem with on/off widgets on my system, but the other problems I mentioned in #6 above still remain.
I'm not really sure how to solve the heart of the issue. Maybe generating a form normally, rendering only the part that affects a particular field (probably using a different method to trigger this), and then sending the whole form as if it was from node edit.
#9
Committed
(See other thread as well, but, on this side, I'm not sure why this is necessary on your setup, I didn't seem to need it. It seems to be 'belt and braces' (more than we need), but - I can't see the harm in doing it, so - :-) )
THANKS for all the help with this module!
Cheers
Mark.
#10
#6 and...
I'm not really sure how to solve the heart of the issue. Maybe generating a form normally, rendering only the part that affects a particular field (probably using a different method to trigger this), and then sending the whole form as if it was from node edit.
I'm not sure what your getting at here?
Can you give me an example?
For sure, multigroups wont work quite right, but, I have an example where a multigroup at least shows all the groups that have been entered using an edit form - you can't add a new entry of course, but existing entries work....
I'm not sure I like your plan of building the whole form and then rendering only part of it. It feels to close to what I was doing for the D5 version, which ended up being a mess..... I'd rather use the cck hooks for the field...
Of course, because we are using this hook, the problem of not being able to handle multiple entries etc must also happen on the default-setting dialogue for a field. So, my view is, if/when somebody cares to fix that, then editable fields will benefit from that fix, but it shouldn't be fixed in editable fields.... do you agree?
(hopefully not, and hopefully you'll have already rolled a fantastic patch, given you work faster that the speed of light :-) :-) )
#11
Confirmed, latest release fixes the issue with on/off checkboxes! Thanks!
#12
I believe this is now fixed properly
First up, modules that opt out of cck CORE for 'multiple fields' are assumed to load and save the entire multiple set of values together. So, on the display side, only one form element will be generated for all elements. Likewise, on the submit side, the code will store the entire result of the submit, rather than just attempting to store one element.
The result of this is that non-CORE multi-fields will _NOT_ work within the context of a multigroup.
If there are modules that opt OUT of 'cck core' but use the 'delta' mechanism - I dont know if this is legal or possible - then they will be broken.
Comments?
#13
This is still broken for me using editablefields 6.x-1.x-dev and cck 6.x-2.x-dev (2009-Mar-15 version). I have a single on/off checkbox with 2 values:
no|Noyes|This person has been checked in.
When I view my node and check the field, it works fine; unchecking it does nothing. My checkbox is in a content type I've created, along with a lot of other fields. It's not in a fieldgroup.
Just to test, I've also added a new single on/off checkbox to my "Page" content type and after adding a "test" page node, checked and unchecked the checkbox. Same results: checking works, but unchecking doesn't.
Other people have got this right (#11) - what have I missed that I've done differently?
#14
just to see - could you give the thing a 3rd value - or make it optional - so this becomes a pull down - see if it works then?
Cheers
Mark.
#15
I hadn't marked the checkbox as "required" originally. It's a single on/off checkbox, so I guess giving it a 3rd option will give you some more information about my error? Ok, I've given it a 3rd option, set it to "editable" in my view, then check it in the view - and it saves as checked. When I uncheck it, the "processing" image turns a bit (like it's saving) and the checkbox greys out, then it becomes editable again, with the check still there.
If I change the widget type to "Check boxes/radio boxes" and give it 3 options, then when I edit it in my view it saves perfectly.
So I think it's just the single on/off checkbox which messes up. Is there anything else you'd like me to try?
#16
Mmm, ok - well thanks for that - I'm not sure when I'll get to look at this problem - I'll try sometime next week. Feel free to have a look yourself, or ping me next week if you hear nothing :-)
Cheers
Mark.
#17
I confirm the issue, on/off checkbox are still very bugged.
/subscribe
#18
I just updated from Drupal 5.x-1.10 to 6.x-2.2 following the update instructions and am also having a problem with checkboxes. They will display on a form, but cannot be edited (if I check one and save it, it will not save). Also, checkboxes that are stored in the database as checked are not displayed as checked (as if the query was broken and failed silently). I would be happy to provide more information if it would be helpful.
#19
Hi,
The issue is still here with CCK 2.4 stable. Tried with both 1.2 and dev version of editablefields.
Any news about it ?
#20
subscribing...
thanks
#21
subscribe
#22
I've experienced the same thing on a relatively new install with the recommended/supported versions of modules. I used taxonomy to work around this in the mean time.
#23
New install of Drupal 6.13, added three modules: cck, ajax_load, and the latest version of editablefields (March 23rd).
Experiencing exact same single checkbox issue of it not saving the unchecked mode.
subscribed.
#24
Hi,
I bump this bug because I tested it with the new 2.x dev version.
The problem changed a little, there is no display issue anymore. When you click on the checkbox, it check and uncheck correctly, but, it doesn't change the state of the field.
EDIT : I made a mistake, in my case, it works when I check the checkbox, but not when I uncheck.
#25
Confirming behavior of #24.
Works to check the checkbox, but not when unchecking one.
#26
Confirming behavior of #24 & #25
Subscribe
#27
We're also running into this with 6.13 and the latest everything else.. Hrm..
#28
I have the same problem, subscribing