It appears that radio/checkboxe fields that are set to be 'required' in the CCK type are not being evaluated for input within this module's context. To reproduce:
1) Create a nodeprofile type containing both a required text field, and a required radio field,
2) Integrate it with registration.
3) Register a user, without filling in the required fields in the nodeprofile.
If reproduced properly, you should receive a validation error saying the text field is required - but notice there is no such validation performed for the radio field. Despite the required field not being filled in, the nodeprofile is saved, and the user is registered.
4) Go to Administer > Content and try to edit and save the profile that was just created
(Note, this is now *outside* of the context of the nodeprofile module) If reproduced properly, you will find that here, in the regular content edit form returns a validation error (as expected) for the required radio field.
My suspicion is that the issue really lies in subform_element, but I haven't looked deeply into it yet.
Comment | File | Size | Author |
---|---|---|---|
#127 | form_checkboxes_0.patch | 2.8 KB | yched |
#123 | drupal.checkbox-required.123.patch | 2.42 KB | sun |
#120 | D6_export-field_option_0.txt | 2.51 KB | yched |
#112 | drupal.checkbox-required.112.patch | 12.67 KB | sun |
#108 | form-179932-107.patch | 11.13 KB | mgifford |
Comments
Comment #1
smooshy CreditAttribution: smooshy commentedI have this same problem. Has anyone come up with a solution?
Comment #2
riverfr0zen CreditAttribution: riverfr0zen commentedUntil this gets fixed, my quick solution (and sucky) solution was to change radios/checkboxes to select fields.
Comment #3
fagohm, I can reproduce the problem. It's a bug of the subform element module. Unfortunately, it's quite time intensive to go after this, and currently I've not much time for it - so I'll look at it when I find the time for it..
Perhaps, you could help me a bit with this and test if things change with other versions of the subform element module.
Comment #4
qingdao CreditAttribution: qingdao commentedim having the same problem, will this bug be fixed soon ? (next some weeks)
Comment #5
bjacob CreditAttribution: bjacob commentedSubscribing... Any updates yet?
Comment #6
qingdao CreditAttribution: qingdao commentedto realize "required check" open the file "optionwidgets.module" (modules/cck) and replace line 117
'#required' => FALSE,
with
'#required' => $field['required'],
after this it will work
unfortunatelly the checkboxes are not marked with the red dot, which tells the user that this input is required, but at least the validation is working ...
Comment #7
rlnorthcuttI made the change to the "optionwidgets.module" above, and now the required radio button DOES show the red *... but it doesn't require the radio to be selected...
It seems like its not validating.
ron
Comment #8
idmacdonald CreditAttribution: idmacdonald commentedI can confirm this bug. It seems to occur when using the integer field type and either of the checkbox widgets (single or multiple). It does seem to be a subform problem, because when editing the node normally, everything works as expected. However, when editing the node via nodeprofile (and subform element), this bug crops up. The value in the database is not changed when I uncheck a box that was previously checked. So, somehow '0' or null input values are not being passed correctly by the subform module.
If I set the 'off' value for the checkbox to a non-zero integer value, then the bug doesn't occur. So, it would seem to be a form of the PHP zero problem.
-Ian
Comment #9
qingdao CreditAttribution: qingdao commentedthis code changes affect only for the checkbox and not the radio box
Comment #10
rjleigh CreditAttribution: rjleigh commentedOK, after some painful hours of tracing and examination, I figured out why this is happening.
This all happens in form.inc.
Right at the top of 'drupal_prepare_form' is the following code:
The actual error code should be set in the '_form_validate' function, but it won't get set if there's no '#needs_validation' element.
The '#needs_validation' element should get set in the 'form_builder' function towards the bottom, but it won't happen because it's in a conditional statement that tests for $form['#programmed'], which is TRUE because subform set the post.
Now, HOW do we fix it? Easy to do with a patch to form.inc, but that's lame.
I was looking at adding a $form['#after_build'] function, since I don't see a hook that will work, but haven't gotten it to work yet.
Any ideas?
Comment #11
rconstantine CreditAttribution: rconstantine commentedsubscribing
Comment #12
ellen-dlma CreditAttribution: ellen-dlma commentedsubscribing
Comment #13
tanjerine CreditAttribution: tanjerine commentedsubscribing
Comment #14
bjacob CreditAttribution: bjacob commentedchanged title ;)
Comment #15
izmeez CreditAttribution: izmeez commentedI have noticed the same problem in the Drupal 6.x Profile module where I have one check box that is required. When the user first creates an account if they ignore this field they are not reminded that it needs to be completed. When the user later returns to edit their profile they do receive a reminder that the field must be completed. Is there a patch that would work for this? Thanks,
Izzy
Comment #16
kenorb CreditAttribution: kenorb commentedThe same problem.
subscribing
Tested on Drupal 5.7 + CCK 1.6
Comment #17
kenorb CreditAttribution: kenorb commentedMade a simple patch.
Problem was that #value wasn't empty() after nothing was selected.
Comment #18
izmeez CreditAttribution: izmeez commentedIs this patch also for Drupal v6.2 ?
Thanks,
Izzy
Comment #19
bcn CreditAttribution: bcn commentedsubscribing
Comment #20
xxparanormalxx CreditAttribution: xxparanormalxx commentedsubscribing
Comment #21
smooshy CreditAttribution: smooshy commentedthe patch doesn't appear to work for my situation. When I edit it through the pageroute page, the value never gets set to 'off'
Comment #22
TyraelTLK CreditAttribution: TyraelTLK commentedIs the same problem that affects Profile core module in drupal 6.2?
http://drupal.org/node/259292
Comment #23
Chill35 CreditAttribution: Chill35 commentedIs this a problem in form.inc ? The patch is for form.inc.
If so, this should not be associated with the module Subform Element anymore.
This problem is in Drupal 6.
Comment #24
ejakila19 CreditAttribution: ejakila19 commentedI had this problem with radio buttons and I was surprised to find out that there is no validation function in optionwidgets.module for required fields.
My solution was to add the case for 'validate' in the optionwidgets_widget function:
then I added the following function to optionwidgets.module:
This should fix the case for radio buttons, but it doesn't address checkboxes. To do so, you must add "case 'checkboxes' : ...code..." to the validation function just as I have done for 'options_buttons'
I hope this helps somebody
Comment #25
Robert Castelo CreditAttribution: Robert Castelo commentedI've created a generic solution here:
http://drupal.org/project/checkbox_validate
Just install the module and all checkboxes in every form display and behave the way they should.
I like this solution because it means developers don't need to add any extra validation code to their modules to make up for the bug in core, and once core is fixed this module can be uninstalled.
If your module relies on required checkbox fields be sure to make this module a dependency.
Comment #26
webchickSee also #259292: Required radios/checkboxes are not validated (D6) which I marked a duplicate of this bug.
Comment #27
Chill35 CreditAttribution: Chill35 commentedWonderful, Robert, thank you :-)
Comment #28
bjacob CreditAttribution: bjacob commentedHi Robert,
thanks for your patch. Can you provide a patch for Drupal 5.x as well?
@ejakila19: I've applied your solution. Here's the code for a single on/off checkbox:
Thanks a lot, Bjoern
Comment #29
Robert Castelo CreditAttribution: Robert Castelo commentedHi bjacob, I think the module should also work on Drupal 5, maybe .info file might need adjusting to install properly.
Comment #30
deviantintegral CreditAttribution: deviantintegral commented#17 doesn't work for me either. This even effects simple forms with a required checkbox for me.
--Andrew
Comment #31
Dave ReidDoes anyone know if this been fixed in D7?
Comment #32
Antinoo CreditAttribution: Antinoo commented-12 days, and this bug will be 1 year old :-)
:-(
Comment #33
webchickThen someone better get on reviewing the patch and providing results, and then marking it RTBC. :P
Comment #34
Dave ReidMarked #224012: required fields don't work correctly as a duplicate of this issue.
Comment #35
misiu9 CreditAttribution: misiu9 commentedIs this problem fixed in any recent version of drupal???
Im using drupal 6.3 and the problem still exists with radio buttons and check boxes which are marked as required.
During registration the required check boxes are being ignored.
Thanks for any help
Michael
Comment #36
Dave ReidNo, this has not been fixed yet and for all I know, is still present in 7.x where it will need to be fixed first, and then backported to 6.x and 5.x. This is also not a critical patch because it does not need to be fixed immediately because the software is not usable at all.
Comment #37
sunI am not able to replicate this bug in 7.x. Setting #required => TRUE on radios and checkboxes properly returns a validation error.
Comment #38
Dave ReidThanks for checking sun!
Comment #39
deviantintegral CreditAttribution: deviantintegral commentedActually, I can replicate this on HEAD. It only happens with the checkbox type - in fact, I've never had a problem with checkboxes / radios. The #259292: Required radios/checkboxes are not validated (D6) is actually a better title for this issue.
Here is a pre-made module to easily test this. I will try and come up with a simpletest for this issue after lunch :)
Comment #40
deviantintegral CreditAttribution: deviantintegral commentedI have a patch for it which came about working on how to test this issue. I'll post both when I'm done the test.
Comment #41
deviantintegral CreditAttribution: deviantintegral commentedHere is the patch along with the test. The patch does two things;
This passes all tests currently.
Comment #42
Gábor HojtsyJust marked #259337: Mandatory Profile's field is not mandatory as a duplicate.
Comment #43
Dries CreditAttribution: Dries commentedThe code looks good to me, although that check in form.inc is getting a little nasty.
The change to theme_checkbox I'm not 100% sure about.
Thanks for adding a test!
I'll let some more people review this patch.
Comment #45
deviantintegral CreditAttribution: deviantintegral commentedI was just able to install HEAD with this patch applied, so flipping back to CNR.
Comment #46
Damien Tournoud CreditAttribution: Damien Tournoud commentedPlease leave this poor check alone, it totally makes sense. The issue is in
form_type_checkbox_value()
... but there could be more than one bug there.Comment #47
Damien Tournoud CreditAttribution: Damien Tournoud commentedform_type_checkbox_value() had a bug, that #229129: System module page *seriously* broken tried to fix totally the wrong way.
The bug is that
should be:
Because a non-checked checkbox should not return any value, not the '0' value. This breaks both the logic that is triggered later on to "set the default value if no value was found" (which #229129: System module page *seriously* broken tried to fix) and the "a required checkbox is not validated because even a non-checked checkbox has a value of '0'" (which this patch tried to fix the wrong way).
The attached patch:
- makes the correct fix,
- reverts the silly unit tests that have been committed in #314283: TestingParty08: Disabled checkboxes need tests, in an effort to make sure that the crappy fix was working,
- adds a new test,
- add the fix to theme_checkbox, that IMHO makes sense (there is a big of redundant code with theme_form_item(), but we can't really do anything else because we need to output the checkbox *inside* the label tag)
Comment #49
webchickI can confirm the results of the testing bot. This still needs work.
Comment #50
Damien Tournoud CreditAttribution: Damien Tournoud commentedNow that I think about it at a non-crazy hour, we really do need that special #disabled handling because there is no way to differentiate between a "non-checked checkbox" and a "disabled checkbox".
So I rewrote and documented form_type_checkbox_value this way:
I also added a unit test of checkboxes, which could be extended at a later stage to test other widget types.
100% on my development environment, let's see what the bot thinks.
Comment #52
Damien Tournoud CreditAttribution: Damien Tournoud commentedReroll.
Comment #54
Damien Tournoud CreditAttribution: Damien Tournoud commentedI can't reproduce the testing failures.
Comment #55
geerlingguy CreditAttribution: geerlingguy commentedD'oh! Just ran into this problem in Drupal 6. Kind of annoying bug, as I'd like to have an "I read the Privacy Policy blah blah" checkbox on the user registration form, but without this validation, it doesn't have to be checked...
Comment #56
kenorb CreditAttribution: kenorb commented#55 -> #25
Comment #57
geerlingguy CreditAttribution: geerlingguy commented@ kenorb - ah, thanks. I saw that, but my brain must've been turned to 'stupid' mode and I didn't regard it as useful to me. Installing now!
Comment #58
bcn CreditAttribution: bcn commentedRe-roll of the patch from #52.
Comment #60
Jhef.Vicedo CreditAttribution: Jhef.Vicedo commentedsubscribing
Comment #61
Damien Tournoud CreditAttribution: Damien Tournoud commentedLet's try again.
Comment #63
seanrWhy are we considering this to be a normal bug instead of critical? This effects every module that uses the checkbox field, and as geerlingguy noted, it represents a serious liability in certain cases.
In my particular case, it is actually causing a LEGALLY REQUIRED (as in federal election law!) checkbox not to validate properly. I now have to write extra code into my module that I would never have expected to need because Drupal core isn't performing the validation as advertised.
Let's please agree that this bug is a little more serious than your run of the mill display issue.
Comment #64
webchickSo how about re-rolling and testing the patch, rather than re-iterating how much this needs to be fixed? :)
Comment #65
Antinoo CreditAttribution: Antinoo commented@seanr: also check http://drupal.org/project/checkbox_validate
Comment #66
seanrWebchick - I could do that for D6, but not D7 as I don't currently have PHP 5.2. Also, the testing errors give far too little information for me to successfully re-roll the patch. Why can we not see exactly which assertions failed? Failed 2 out of 50 tests is useless because I have no idea which the 2 are. BTW, my comment was largely a response to the person who previously downgraded this issue to normal - they seem not to understand the potential impact of this issue.
Antinoo - that is helpful, but it's a bad precedent to have to rely on a contributed module to fix a big bug in core. ;-) Besides, how many users will never even be aware this bug exists until after they've already gotten a ton of bad form submissions?
Comment #67
geerlingguy CreditAttribution: geerlingguy commented@ seanr / #66: can you set up a local LAMP/MAMP/WAMP environment, install D7 on top of PHP 5.2.x, then run the tests locally using the testing module? If you do that, you can see precisely which tests are failing.
Comment #68
andypostsubscribe
Comment #69
WiredEscape CreditAttribution: WiredEscape commentedsubscribe
Comment #70
netron CreditAttribution: netron commentedcame across this bug on a D6 install i'm building for the client.
had to install the checkbox validate module
http://drupal.org/project/checkbox_validate
just something to be aware of if your client requires a legal "i agree to these terms and conditions" or a "i am over 16 years old" user register checkbox.
Comment #71
davea CreditAttribution: davea commentedsubscribe
Comment #72
webchickI'm inventing a tag for this. Would really appreciate even one, just one! of the people here having this bug taking a few minutes to re-roll and review this patch rather than repeatedly saying you have the same problem. We know. We need people to work on the patch to get it fixed.
Comment #73
mgiffordAck. This isn't a hard thing to do. Doesn't take 2-3 weeks to re-roll a patch.
Subscribe.
Comment #74
luxx CreditAttribution: luxx commentedsubscribing
Comment #75
bcn CreditAttribution: bcn commentedhere's a re-roll...
Comment #76
bcn CreditAttribution: bcn commentedComment #78
joep.hendrix CreditAttribution: joep.hendrix commentedsubscribing
Comment #79
andypostA lot of tests broken, patch needs re-roll
Comment #80
halloffame CreditAttribution: halloffame commentedSubscribing... I gotta stick with checkbox_validate module for the meantime.
Comment #81
jromine CreditAttribution: jromine commentedre-rolling this patch.
Comment #82
geerlingguy CreditAttribution: geerlingguy commentedSetting status for the testbot.
Comment #84
jromine CreditAttribution: jromine commentedtry again
Comment #86
jromine CreditAttribution: jromine commentedUpdated patch
Comment #87
jcmarco CreditAttribution: jcmarco commentedWow! That's great! Congratulations!
This is one of the historic bugs in drupal for long time!
I have backported it to D6.13 and it works also great.
I was testing it with forms and even with the legal module without the checkbox_validate module that was patching this bug for long time.
Now, you always see the required field asterisk and stop you to send the form without the required field.
Comment #89
jcmarco CreditAttribution: jcmarco commentedUmm! something wrong with the bot, that is a backporting to D6.13 to ease testing it.
Sorry, I didn't read the insurance contract letter size in the attachment form.
Comment #90
jcmarco CreditAttribution: jcmarco commentedComment #91
mgiffordPatch needs to be built from root not from the includes directory. Patch #90 is going to fail too unfortunately.
But the code also doesn't work against core:
bash-3.2$ cvs update includes/form.inc
cvs update: warning: `includes/form.inc' was lost
U includes/form.inc
bash-3.2$ patch -p0 < form_checkbox_validate-D6.patch
can't find file to patch at input line 3
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|--- form.inc.orig 2009-07-22 14:21:19.328125000 +0200
|+++ form.inc 2009-09-03 11:15:20.234375000 +0200
--------------------------
File to patch: includes/form.inc
patching file includes/form.inc
Hunk #1 succeeded at 787 (offset 112 lines).
Hunk #2 FAILED at 1285.
Hunk #3 FAILED at 1990.
Hunk #4 succeeded at 2064 with fuzz 2 (offset 127 lines).
2 out of 4 hunks FAILED -- saving rejects to file includes/form.inc.rej
Comment #92
jcmarco CreditAttribution: jcmarco commentedYes, it was wrong. First core patch rookie.
Once again, this is just a backporting to D6 from #86
Comment #93
mgiffordOk, patch in #86 applies nicely.
What's stopping this from becoming RTBC?
What testing should be done? I'm running Simpletest now, I'm assuming it's all under the Form API
Comment #94
AndraeRay CreditAttribution: AndraeRay commentedThis is great, It's awesome that this finally came together. I used the patch in post 92 For my Drupal 6 and it works great. Special thanks are definitely due for all the hard work.
Comment #95
mgiffordThe patch in #92 is for Drupal 6.
The patch in #86 is for Drupal 7.
We need more folks to review the patch for D7 before we can get it into core. At that point we can consider bringing this back to D6.
So who is going to do the final review of the D7 patch and mark it RTBC?
Comment #96
seanrI tested the patch in #86 and can confirm it works as expected. I created a simple module to test it and have attached it for anyone else who'd like to give it a try. The same module should work for Drupal 6 with an edit to the .info file.
Comment #98
seanrBot appears screwed up because of #87. Should the patch from #86 be resubmitted?
Comment #99
mgiffordI think it will be clear when the patch is being reviewed.
Comment #100
chx CreditAttribution: chx commentedThe patch reuses the integer 0 which already is unsupported as a checkboxes key. Good trick.
Comment #101
webchickYay! Sign-off from the Form API maintainer! This is really close. I have some minor nits, mostly related to comments. Since this part of the code has been broken for eons, it'd be nice to document the way it's supposed to work once and for all.
"for now"? I don't understand what that means. Please clarify.
Here again, I don't understand what that means. Successful? Meaning it's not validated, or..?
Let's clean up these comments. They sound wishy-washy. Either we are returning zero or we're not, and we should explain why.
This is really weird. None of the other element theme functions do this, no? Why are we doing it here?
Wait. NULL? I thought we returned 0? Why has this treatment not been given to other checkbox fields?
Great tests! Awesome to have this in code so Drupal 7 is hopefully the /last/ release where we break checkboxes. :)
-9 days to code freeze. Better review yourself.
Comment #102
jromine CreditAttribution: jromine commentedI'll cleanup the comments, and re-roll the patch if needed.
An unchecked checkbox value should be represented by NULL, but I ran into issues elsewhere with this. Returning numeric 0 as the value of an unchecked checkbox is a compromise that fixes the issue at hand, and also doesn't break things elsewhere.
In form_process_checkboxes() and form_process_tableselect():
We're looking at a set of related checkboxes, and iterating through #options. $key could be (numeric) 0 for the first item. NULL for #default value represents the checkbox being unchecked. This matches how this is handled in form_process_radios().
I think the special theme handling is because checkboxes don't have a label above the form control.
Comment #103
jromine CreditAttribution: jromine commentedpatch attached
Comment #104
chx CreditAttribution: chx commentedI think I like this :)
Comment #106
mgiffordThink this brings this patch up to the CVS.
Comment #108
mgiffordHmm.. Rolled that patch wrong (more coffee in me now). Hopefully that's the problem, but these are the 9 fails.
Comment #109
mgiffordnot quite enough coffee to change status to needs review.
Comment #111
elarifr CreditAttribution: elarifr commentedHello
In drupal 6.14 i tried also checkbox #element_validate in author_contact module and it seems the function is not called while working with textfiled
it seems not only #required is buggy in checkbox
or maybe it is me :(
here are some code i played with just to see if it will display form_set_error
and
Comment #112
sunRe-rolled #103 against HEAD + cleaned up the code.
Comment #113
bcn CreditAttribution: bcn commentedrtbc?
Comment #114
webchickYAY! Latest patch addresses all of my previous comments. It's with extreme excitement that I have Committed to HEAD!
This needs to be back-ported to D6 (and I think D5) now.
Comment #115
yched CreditAttribution: yched commentedThis broke option widgets, which I'm currently cleaning and rewriting tests for.
Steps to reproduce:
- Create a field of type 'List (numeric)', with widget 'Radios / Checkboxes'
Allowed values:
Number of values: illimited
- Create a new node: the 'Zero' checkbox comes out as checked (should be unchecked like the others, we're creating a new node)
- Save the node with 'Zero' and 'One' checked. On node view, you see that both values were saved.
- Edit the node: only 'One' comes back as checked ('Zero' should be checked too)
Is there some special tricks to apply to get '0' recognized as a valid value in checkboxes #options now ?
Comment #116
webchickBleh. :(
Looks like we need even more test coverage to be assured this is working. Could someone please work yched's reproduction steps into a test case?
Comment #117
chx CreditAttribution: chx commented0 was never a valid checkboxes value. That's documented:
that stands for four years now. That's not new.
Comment #118
yched CreditAttribution: yched commented"0 was never a valid checkboxes value"
CCK optionwidgets have been making use of this from 4.7 until current core's options.module - and, er, maybe it was not supported, but it worked until yesterday.
This mention in the FAPI reference has been added somewhere during D6 dev cycle, but not mentioned in http://drupal.org/update/modules/5/6. So I guess we just missed that fact, and kept a working but 'invalid' feature for 3 years.
OK, I guess options.module will need to hack a translation of '0' options into '_0' or something...
Comment #119
chx CreditAttribution: chx commentedThat worked? No way. Really, that's not possible, can you show me a Drupal page with checkboxes page that has 0 among the indexes and you can save with 0 ticked off?
Comment #120
yched CreditAttribution: yched commentedNo example online, sorry. But you can see this working in CCK D6 by importing the attached field export.
+ I had my 'checkboxes' widgets tests for D7 (for the patch I'm working on and was about to post) work with yesterday's core and the field described in #115.
Comment #121
sunThe option keys should be strings.
In http://api.drupal.org/api/function/list_allowed_values_list/7, $key is a string until
so PHP seems to auto-convert "0", "1", etc into an integer. Is there any way to prevent this?
Comment #122
yched CreditAttribution: yched commentedre sun: Yes, I tried that as well, but PHP does seem to auto cast numeric strings in array keys into actual ints.
No way to keep string '0' as an array key.
Comment #123
sunThis works in manual testing.
Comment #124
yched CreditAttribution: yched commentedNo test bot right now, it seems, but locally this gives errors on single checkbox in "Form element validation" tests:
Checkbox 'checkbox_off' returns expected value (expected: '', got: 'checkbox_on') in form.test line 150
Checkbox 'zero_checkbox_off' returns expected value (expected: '', got: '1') in form.test line 150
Comment #125
yched CreditAttribution: yched commented(forgot to say that it does fixes 'checkboxes' widgets using 0 as one of the options, though)
Comment #126
yched CreditAttribution: yched commentedThe failures boil down to: with patch #123, the $form_state['values'] for an unchecked checkbox end up as the #default_value instead of 0.
Comment #127
yched CreditAttribution: yched commentedDunno why it didn't get reported here, but test report for #123 is at http://qa.drupal.org/pifr/test/19142
14,684 pass(es), 281 fail(s), and 149 exception(es).
Attached patch uses '' instead of NULL for empty checkbox value. Solves the errors mentioned in #125-126, but still has the drawback of breaking many code, for instance code that inserts the checkbox form value directly in an int column in a table (I would have expected FALSE would work better, but turns out it's also rejected for int columns).
Comment #129
yched CreditAttribution: yched commentedI posted #635202: Remove #process pattern from option widgets (refactors + truly tests option widgets).
The patch uses a '_0' placeholder for '0' options. We can remove it if/when this gets sorted out, but for now it unbreaks option widgets.
Comment #130
webchickI guess we need to roll this back then? :\
Comment #131
jlain CreditAttribution: jlain commentedsubscribing
Comment #134
mgiffordWhat happened from #112 to #127 to get so many failed tests?
I thought this was basically a done deal!
Comment #135
yched CreditAttribution: yched commentedmgifford: #112 or similar has already been committed. The followup patches are attempts to make checkboxes support '0' as a valid option again.
Comment #136
mgiffordAhh.. Ok. That's god to know.
Comment #137
c960657 CreditAttribution: c960657 commentedI just created #654796: Identify fix bugs with checkbox element. Not sure if that is a duplicate of this.
Comment #138
Reg CreditAttribution: Reg commentedsubscribe
Comment #139
Shai CreditAttribution: Shai commentedsubscribe
Comment #140
sunSo do we mark this as fixed in favor of #654796: Identify fix bugs with checkbox element ?
Comment #141
andypostI think that issue should be backported because it's a bug
Comment #142
yched CreditAttribution: yched commentedAs a D7 issue, yes, the followup should be fixed by #654796: Identify fix bugs with checkbox element.
Not sure if a D6 backport is possible.
Comment #143
tstoecklerLet's see.
Comment #144
webchickWell, you don't want a back-port of this, because it's still buggy.
Comment #147
Bilmar CreditAttribution: Bilmar commentedsubscribing
Comment #148
dman CreditAttribution: dman commented#127: form_checkboxes_0.patch queued for re-testing.
Comment #150
sun.core CreditAttribution: sun.core commentedThis patch was actually committed, we just don't want the same patch to be backported to D6. Please create a new issue for D6. Or not.
Comment #151
josepvalls CreditAttribution: josepvalls commentedSo, where is the D6 issue?
I can only find issued marked as duplicate.
Comment #152
Cyberwolf CreditAttribution: Cyberwolf commentedSubscribing.
Comment #153
ginc CreditAttribution: ginc commentedissue for D6 #259292: Required radios/checkboxes are not validated (D6)
Comment #154
riverfr0zen CreditAttribution: riverfr0zen commentedthanks, guys
Comment #156
markosaurus CreditAttribution: markosaurus commentedI know this has been closed for a while now, but I thought people who had been working on this might be interested and I didn't know where else to post. This relates more to the "Checkbox Validate" module than to the actual bug, but since some people (including myself) have used this as a potential fix, I thought it relevant.
I had encountered this problem in D6.16 as other people have when creating a checkbox for T&C's on a site I'm developing.
Well I followed lots of advice and installed the "Checkbox Validate" module, ran it, and then the issue was miraculously fixed.
Now when I create a test user, no verification email is sent out to the user, where it did before installing the module. The option to "Require e-mail verification when a visitor creates an account" is still checked in Administer > User Management > User Settings and it is still set in the DB.
Now I don't know how to roll back this module, I can't verify users and have no idea how to fix?
Any thoughts?
TIA
UPDATE - I went through and disabled the module and tried to register, which didn't issue the email. I thought it was this module which had caused this, but on further testing, I had applied an action which redirects the user to a "thanks for registering" page after registration. Only the trigger seems to have over-ridden the default action of sending the registration email. So in actual fact this was entirely my fault for enabling an action and a trigger, and nothing to do with this module.
Sorry [embarassed smile]
Comment #157
sunThis issue is about Drupal 7 core, not about a contributed module.
See #259292: Required radios/checkboxes are not validated (D6) for D6. (although your issue doesn't sound related to Drupal core at all)
Comment #158
tim.plunkettComment #159
acbramley CreditAttribution: acbramley commentedTried applying patch in #112 to 7.8 with no luck. Can a patch be rolled against it please?
Comment #160
mgiffordSorry @Zombienaute but patches are rolled against HEAD, which is Drupal 8 in git and not a 7.x release. @Sun built that patch in November 13, 2009 and Drupal 7's changed a lot since then. It might be able to be back-ported, but first it needs to get into Core.
One could probably build a patch for this for D7 as a hack or look at extending the validation with a module.
Comment #161
acbramley CreditAttribution: acbramley commentedMakes sense, I might have a crack at doing it myself if I have the time.
Comment #162
mgifford@acbramley - any chance you'll be joining us at the sprint this weekend?
Wanted to link to these related issues - #1493324: Inline form errors for accessibility and UX & #504962: Provide a compound form element with accessible labels