Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Standard CCK with Drupal 6.4 (fresh install, not upgrade) seems to have an issue where if you add a numeric field, any value that you enter is deemed too short. E.g.
distance cannot be longer than but is currently 4 characters long.
This can be worked around with a code edit in includes/form.inc, changing line 684:
if (isset($elements['#maxlength']) && drupal_strlen($elements['#value']) > $elements['#maxlength']) {
to
if (isset($elements['#maxlength']) && $elements['#maxlength'] != "" && drupal_strlen($elements['#value']) > $elements['#maxlength']) {
Comment | File | Size | Author |
---|---|---|---|
#9 | cck-Problem-with-max-length-on-decimal-308250-9.patch | 1.58 KB | nickl |
#6 | numbers.patch | 1.06 KB | gabrielkpwong |
Comments
Comment #1
yched CreditAttribution: yched commentedThe fix is definitely *not* to hack core.
It seems your field has invalid settings - 'precision' = 0 or '(empty string)'.
Please visit this field's settings form and submit them again. Should fix the error.
Now, not sure what might have caused this. Where does this field come from ?
manually created in D6 ?
from a D5 site upgraded to D6 ?
Content copy import ?
Comment #2
willthames CreditAttribution: willthames commentedNo, obviously I'd rather not have hacked core!
It's a number field, so it doesn't have length - precision is set to default of 10, scale to 2. If you let me know what I can run against the DB for further information, I can definitely do that.
This field was created in a brand new fresh install of Drupal 6.4 with a brand new fresh CCK install.
Comment #3
yched CreditAttribution: yched commentedOK, 3 things :
- the error message you posted in you initial message doesn't seem accurate, please post the exact error message.
- what PHP version are you running ?
- please enable devel.module and add the following lines in form.inc :
just above the lines you mentioned
then try submitting the node form again, and report what you got.
Comment #4
ssiruguri CreditAttribution: ssiruguri commented@yched
I ran into the same problem. Not sure if you meant to ask for $element['#field_name'] in your request, because in form.inc at that point, there's no variable called $element, but an array called $elements. Here's the value:
["#field_name"]=>
string(23) "field_price_obtained_at"
This field is a Decimal Number, with precision and decimal values set to the defaults of 10 and 2. Hope that helps.
I am running PHP 5.2.6.
Comment #5
ssiruguri CreditAttribution: ssiruguri commentedOk, I fooled around a little bit more and realized that it's just that the Minimum and Maximum fields aren't set by default for Decimal type fields -- but they have to be for the form to work correctly. It's not a bug, more like a better implementation of the feature and some documentation.
Sameer.
Comment #6
gabrielkpwong CreditAttribution: gabrielkpwong commentedHere is a patch to change the default max length on floats from 10 to a more reasonable amount (20).
Comment #7
qasimzee CreditAttribution: qasimzee commentedFacing the similar error:
test_decimal_defaul cannot be longer than characters but is currently 1 characters long.
Comment #8
qasimzee CreditAttribution: qasimzee commentedSorry @gabrielkpwong, patch didn't work for me
Comment #9
nickl CreditAttribution: nickl commentedCome on guys? I didn't expect this from the cck project!
This even throws php warnings when trying to check length against an empty #maxlength I can't believe no one has fixed this since 2008, swak!
There has also been a workaround noted #392912: Bug Work Around For Entering a Default Value in Decimal Fields which mentions that this bug exists on 3.x as well, please port.
The problem occurs on decimal only when trying to set a default value on create.
Reason being that isset was used to check the presence of numbers in text values and this caused these numbers to be set as empty strings which therefor fails length checks.
The attached patch correctly checks against !empty else sets the default numerical values as was intended.
Comment #10
alexmoreno CreditAttribution: alexmoreno commentedthe solution works, but the patch does not apply correctly for the latest stable version: