DateTimeComputed: Fatal error when Ajax call in form. (strlen() on array)

I am adding steps to reproduce the bug to the issue summary. I used the steps in 🐛 DateTime::createFromFormat() expects parameter 2 to be string Closed: duplicate and #3052608-8: DateTimeComputed tries to compute from an empty value → as a starting point.

I am pretty sure that this issue and 🐛 DateTime::createFromFormat() expects parameter 2 to be string Closed: duplicate are duplicates. The other issue was created first and has a better description of how to reproduce the bug. This issue has a better explanation of what goes wrong. Each issue has a patch, and they change different parts of the process.

Patch #2 works for me. Used with paragraphs in a custom block.

Implemented patch #2 and works great with latest Paragraphs 1.17 & Drupal core 10.2.7!

Confirming that patch #2 works cleanly on Drupal 10.3.2 with Paragraphs v1.18. Does this change need tests to be updated?

Tests are expected by default. Maybe a unit test will do.

I've created a MR with the patch applied, I'm new to test writing so I'm not sure where to start for this specific issue. If there is a specific guide page I would be happy to look at it!

That last commit was me. I did it through the web interface, so that's probably the reason it doesn't properly show up.

From my limited testing, I noticed that only when the field is empty, the value will indeed be an array. I think the solution from the previous patch is than in fact not quite appropriate; it just takes one of the empty values and passes it through the test of the code. Instead, I changed it to treat it similarly to a NULL value; just bail out when it is an array.

Still needs a test, of course :)

I was able to reproduce the bug in core in a FunctionalJavascript test using NestedEntityTestForm from the field_test module. That test has been pushed to the MR.

This bug will occur when the following conditions exist:

1. An ajax submission is triggered on a nested form that contains a datetime (or date range) field.
2. The submitted datetime field value is invalid and fails Datetime::validateDatetime which means the formState value for the element remains as an array.
3. The nested form calls EntityFormDisplayInterface::extractFormValues from a validate callback (e.g. NestedEntityTestForm::validateForm or ParagraphsWidget::elementValidate which results in DateTimeItem::setValue getting called and the item's values property gets set to the value array. Then when the nested form is rebuilt on ajax and DateTimeWidgetBase::formElement is called, the call to the date property on line 35 results in DateTimeComputed::getValue being called and because the value is an array, it throws an throwableerror which is not caught but the try/catch and Ajax fails.

Based on these findings I feel the current proposed solution both here and on issue 🐛 DateTimeComputed tries to compute from an empty value Needs work , while preventing the bug, is fixing a symptom rather than the cause. I propose instead that we modify DateTimeWidgetBase::massageFormValues and DateRangeWidgetBase::massageFormValues to ensure both valid and invalid values are handled correctly to match the expectations of DateTimeComputed::getValue. If $item['value'] is not a DrupalDateTime, it did not pass validation so it is still an array, we should set it to NULL.

I have pushed this change to the MR and updated the Issue Summary with my findings and the updated proposed resolution.

Patch file to work with Drupal 10.4.7