#disabled date fields sends in an empty array for field value. mysqli_real_escape_string() errors.

This appears to still be an issue. I use the workflow_fields module to set view/edit permissions for each field by workflow state. When I have view permissions on a Date field, and I create a new node, everything works great. When I don't have permissions for the field (it is missing from the create node form), I get an error when I create the node. The text of the error message matches that above.

What is the status of this bug?

Thanks,

Jeff

I'm using the 6.x.2.2 version and it seems that the '#disabled' attribute is not even taken into consideration for a date field.
Instead if I assign it a '#false' attribute, and the default date is 'now' I get this behaviour: #403404: Default value set to 1000 years back when #access is FALSE.

Whatever is happening here is causing other problems as well. As I said before, when I use workflow_fields to remove edit permission of a Date field, I get this error. It also happens on subsequent edits.

It also seems to cause cck computed fields to not save their values into the database properly. I edited the node, checked the database, and no value was stored. After enabling edit permission for the date field and trying again 1) the warning went away, and 2) the computed field saved it's value properly.

I have the same problem with date fields. Yet a different cause / initiator. I'm building a custom multi-page form using the Form API. I have a bunch of dates that I'm creating with an array. The user basically chooses which date fields are relevant and sets them accordingly.

What's happening is the ones that are not explicitly set, are apparently being sent as an array. I hadn't noticed before that the arrays were empty.. but that sounds logical. I was thinking the bug was that the error reported was incorrect - saying "array was sent" rather than "no value provided."

So in this case, it's not a #disabled issue yet the effect is the same. No value was provided.. result was the same warning.

I think I got a different line number too: 323... but I'm sure it's the same thing.

So my fix was to explicitly set all the non-set dates to empty string "" before transferring the $form_state["storage"] to $form_state["values"]

Would love to see a fix as a more descriptive error would have saved me a LOT of time debugging.

I too have the same problem with date fields. I created a custom node type that I was loading into the database using drupal_execute(). When I did not explicitly set dates and empty array was set that threw back this error.

Many hours were spent trying to debug the issue. A more descriptive error would be good, or just some checking to see if a value had been provided and setting it to "" if not. This must be done somewhere on the form when editing the node manually. It must get bypassed somehow when using drupal_execute().

What is so confusing about this issue is that not all CCK fields throw the error when they are not explicitly defined. Date was the only one that did it to me. I thought I had a corrupt node_form or something.

Eventually I just recreated the node and started to add the fields one at a time until I got the error again and Date was the culprit. I'm not sure what Date does different than the other CCK fields, but it sure causes some tail chasing.

Still seeing $text = array('date'=>'') being passed to db_escape_string (line 321 in database.mysqli.inc) while using the October 26th -dev release. In my case, it may be caused by a DateTime object as opposed to a Date object ... I have 2 date objects and 1 Datetime object in the content type, but only see the error once.

Definitely still an outstanding issue, even with the latest dev.

I was also experiencing mangling of the first character when the field was disabled. This seems to have been fixed in the 6.x-2.x dev snapshot (2011-Jan-19). I had tried the previous snapshot with no success.

Definitely fixed in the current -dev release for my Date Popup fields.

I've rolled a patch against 6.x-2.7, which includes the -dev changes in date_popup.module for anyone who just wants to modify a few lines instead of going to the -dev release. Haven't tested the actual patch myself, but visually it looks good.

This patch just saved my life. Well, a part of it actually, but still.

Thanks a lot.

Unfortunately the Drupal 6 version of the Date module is no longer supported. That said, we appreciate that you took time to work on this issue. Should this request still be relevant for Drupal 7 please feel free to reopen it. Thank you.