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']) {
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

yched’s picture

The 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 ?

willthames’s picture

No, 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.

yched’s picture

Status: Active » Postponed (maintainer needs more info)

OK, 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 :

  if (isset($element['#field_name'])) {
    dvm($element);
  }

just above the lines you mentioned

  // Verify that the value is not longer than #maxlength.
  if (isset($elements['#maxlength']) && drupal_strlen($elements['#value']) > $elements['#maxlength']) {

then try submitting the node form again, and report what you got.

ssiruguri’s picture

@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.

ssiruguri’s picture

Ok, 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.

gabrielkpwong’s picture

FileSize
1.06 KB

Here is a patch to change the default max length on floats from 10 to a more reasonable amount (20).

qasimzee’s picture

Status: Postponed (maintainer needs more info) » Active

Facing the similar error:

test_decimal_defaul cannot be longer than characters but is currently 1 characters long.

qasimzee’s picture

Sorry @gabrielkpwong, patch didn't work for me

nickl’s picture

Version: 6.x-2.0-rc7 » 6.x-2.x-dev
Status: Active » Needs review
FileSize
1.58 KB

Come 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.

alexmoreno’s picture

the solution works, but the patch does not apply correctly for the latest stable version:

patching file modules/number/number.module
Hunk #1 FAILED at 444.
Hunk #2 FAILED at 482.
2 out of 2 hunks FAILED -- saving rejects to file modules/number/number.module.rej