Hidden date field saves null values when editing an existing node, producing notices

[argiepiano]

Description of the bug

Editing an existing node with a date field that's hidden via '#access' => FALSE saves a null value to the database. This, in turn, produces notices when viewing the node: Warning: Trying to access array offset on value of type null in theme_date_display_combination() (line 219 of /Users/XXX/Sites/localhost/kmta/core/modules/date/date.theme.inc). This happens regardless of the widget [EDIT: the HTML5 widget handles this correctly].

Steps To Reproduce

In order to reproduce the problem, you have to alter the node_form to hide the date field.

1. Add a field called field_test_date to the Page content type. Use any widget [EDIT: OTHER THAN HTML5]
2. Set the Default Valuie in the field UI to "No default value"
3. In a custom module, implement hook_form_node_form_alter(&$form, &$form_state);
4. In that hook, set the access to false, as in $form['field_test_date'][LANGUAGE_NONE][0]['#access'] = FALSE;
5. Create a page node. Check the database table field_data_field_test_date. Nothing is saved for the new node. 👍🏽
6. Edit that same page node (no need to change anything). Click Save

You'll get the notices above. If you inspect the table for the field you'll see a NULL value being stored. 👎🏽

Actual behavior

Null value gets saved for the date. Notices are thrown when viewing the node.

Expected behavior

Nothing should get saved, since the field is hidden and its default value is none.

Additional information

Add any other information that could help, such as:

• PHP 8.1
• Backdrop 1.25.1

I've tested the same in Drupal 7. As expected, D7 does not save a null value for the date, and therefore the notices are not produced

---

PR backdrop/backdrop#4499

[argiepiano]

One correction to the above: if you use the HTML5 widget for the hidden date field, this problem is not present.

And one observation that may offer clues to the problem: when using widgets other than HTML5, the returned form value and type received by the submit hanmdler in $form_state['values'][MY_DATE_FIELD] for the field is inconsistent. The following shows those values for a date field that is not required,

Widget: Select list, Pop-up calendar or Text field widgets | field shown

• When creating a node, $form_state['values'][MY_DATE_FIELD]['und'][0] is an array with keys value, value2, timezone, offset and offset2 (all null)
• When editing, the submitted values are exactly the same 👍🏽

Widget: Select list, Pop-up calendar or Text field widgets | field hidden

• When creating a node, $form_state['values'][MY_DATE_FIELD]['und'][0] is an array with keys value, timezone, timezone_db, date_type and value2. The value and value2 are empty. Those two keys were present also in the case above. But the other keys were not... however, this inconsistency doesn't seem to affect the saving behavior in this case.
• When editing the node, $form_state['values'][MY_DATE_FIELD]['und'][0] contains an empty string 👎🏽 . And I think this may be causing the problem

I haven't tested the Text field widget. [EDIT: tested the Text field widget - same problem as the other 2 widgets]

A similar inconsistency (though not exactly the same) has been noted in the past: #3065

[argiepiano]

And another update, which adds to the messiness and weirdness of this issue. For a hidden, not-required date field that uses any of the widgets Text Field, Pop-up Calendar or Select (NB: the hidden date field has "No default value"):

1. When the node is created and saved, no entry is created in the field table 👍🏽
2. When editing the node for the first time, a null value entry is created in the table, and the notice shown above is thrown when viewing 👎🏽
3. If you edit the node a second time, the null value from the field table is removed, and the notice is gone
4. If you edit your node a third time, step 2 above happens again 👎🏽 😵
5. Etc etc etc ad infinitum

So, if you keep editing your node, the odd number of editings will get you the notice and null entry, and even number will remove the entry. What a mess!

This is quite complex to debug, and will require a lot of step-debugging and patience. My guess is that the inconsistency of the type of values included in $form_state['values'][MY_FIELD]['und'][0] has to do with this problem.

[argiepiano]

I'm attaching a small custom module to help people reproduce this problem:

1. Install the module. It will add a field called field_test_date_ to the page content type
2. Create a page normally. The module will hide that field from the node creation and editing forms

testing_hidden_date.zip

[argiepiano]

FOUND IT! This was fixed in D7's Date module. We even have a cross-port issue from 2019 that was never done.

#4060

The solution is issue listed as 2990189 in that list.

Although originally created to fix a related issue, this fix also works for this situation. It creates an array structure for the element's items when the entity is not new, but the values are empty. This solves to the problem of the differences in the form_state values array in the submit handler.

I'll submit a PR probably tonight.

[argiepiano]

PR backdrop/backdrop#4499 ready for testing and review.

[indigoxela]

I can confirm the really odd behavior of date fields with #access set to FALSE in a hook. Every second edit, a NULL value ends up in the database.

This happens with all three date field types ('date', 'datestamp', 'datetime') and all widget types other than the HTML5 widget, when no default value is set. Date only (without time) fields are also affected.

The field display setting plays a role, of course, as the "Date and time" display (which is the default), triggers the otherwise hidden problem of NULL values saved to the database. But the actual problem is, that those NULL values should never land in the db table.

I tested with hook_form_alter() and with hook_field_widget_form_alter(). As long as I don't also set '#date_items' to an array with the key "value", a bunch of warnings (and deprecation warnings on PHP 8.1) show up.

I can confirm, that the PR fixes the problem. 👍

[indigoxela]

Hm, but wait... the NULL value gets removed from the db, as soon as the node gets saved again. If the node doesn't get saved, the value stays in there. And as the display of these values causes warnings – don't we also need an update hook for those faulty values?

EDIT: yep, we need an update hook to fix that. Otherwise the nagging persists.