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.
An attempt to save a form with a CCK number_decimal field with decimal separator set to "comma" and #access set to FALSE via hook_form_alter, results in a form validation error, message 'Only numbers and the decimal character (%decimal) are allowed in %field.'. The node being edited already contains a value in the field in question, which is displayed and editable properly when #access == TRUE.
Comment | File | Size | Author |
---|---|---|---|
#5 | cck_number_995846-5.patch | 1.05 KB | roderik |
#4 | cck_number_995846-4.patch | 882 bytes | roderik |
#2 | cck_number_995846.patch | 647 bytes | jpl-2 |
Comments
Comment #1
jpl-2 CreditAttribution: jpl-2 commentedWhen this error happens, I can see $start == '1000.00' and $value == '100000' in number_decimal_validate. When the node is saved without #access = FALSE, I see both start and value == '1000,00'.
Comment #2
jpl-2 CreditAttribution: jpl-2 commentedThe problem is that $element['#value'][$field_key] in number_process ends up with the default decimal separator when #access == FALSE, while it contains the user-entered decimal separator when #access == TRUE and a value was posted. The attached patch deals with this, while still keeping proper validation of the decimal separator in case of posted data.
Comment #3
JThan CreditAttribution: JThan commentedThx for the patch. The patch worked for me.
I had this problem without setting #access to false via hook_form_alter (but maybe because of using Content Permissions?)
Maybe someone else can review this also?
Comment #4
roderikI had a look at the patch. And my brain froze for a minute.
The patch is good, but I couldn't resist rolling one that's functionally equivalent (in practice), and has some comments. (For which I took a little peek at another CCK module's 'process' function.)
Comment #5
roderikMeh. That is not "functionally equivalent", in that I am filling $element['#value'][$field_key] also when it was unset.
This patch is unfortunately longer, but I think it still reads OK.
By the way: in other issues (like #283341: Illegal value in text field; field's array is being changed) I've seen references to 'drupal_execute() not working', which relate to incorrect internal values, just like this one. So it seems better to drop the explicit references to #access = FALSE, in the patch.