Fix notice in Date::processDate

To reproduce, create a form with this element:

    $form['adate'] = array(
      '#type' => 'date',
      '#description' => $this->t('Enter a date.'),
      '#default_value' => '',
    );

Just visit the form, no need to submit. The notice will be shown in /admin/reports/dblog.

I think this actually fits the definition of a bug report - changing category from task ...

#2 To answer the idea of using $element['#attributes']['type'] == 'date'

What I was thinking was that doing it this way, would be more generic and make sure that we only effect actual date elements and not other date related elements (like time). I also figured that if there were other types of elements that also would produce date elements (contrib), then this code could more easily be reused.

So generally try to match all <input type="date ..> elements not caring about how they got created.

Perhaps a duplicate of #1972660: Add tests for the new HTML5 date elements 'date', 'datetime', 'datetime-local' and 'time', as adding tests for the elements should have caught this.

@mpdonadio: So you're saying that instead of fixing this regression introduced by the recent commit in #1835016: Polyfill date input type we should just ignore the PHP errors and put it off for how long? A year? Maybe we should revert #1835016: Polyfill date input type instead, since it breaks previously working code.

Regardless, I don't see this as a duplicate of an issue (#2088383: Datetime FAPI DX) that has been stagnant for 2 years and is geared towards providing functional features, rather than fixing a recently-introduced bug. By marking this as duplicate you're basically saying this isn't going to get fixed (or at least not for years) and that's not an acceptable response. Plus you've also just postponed #2088383: Datetime FAPI DX, which means that's not going to get worked on either ...

Yes, that is what I've had to do - I changed everything to

'#type' => 'datetime,
'#date_date_element' => 'date',
'#date_time_element' => 'none',

(none of that is documented, btw - I got that from reading code).

But I really need only the date so I had to add a lot of code in my validate and submit functions to throw away the time part (can't compare two dates properly if the times are different ...). When I have to make compromises like this, I know I am going to hear shit down the road about how "Ubercart doesn't follow Drupal best practices" and the like, so I'd really rather not make compromises - I need a 'date' element and Drupal is supposed to support the 'date' element. (Google "site:drupal.org html5 date element" and you will see the many issues opened about the 'date' element and how I conclude that 'date' is claimed to be supported by Drupal.)

The larger problem is that there is ABSOLUTELY NO DOCUMENTATION on any D8 form elements. So technically I guess this isn't a bug because NONE of the expected behavior is documented. On the other hand, everyone keeps pointing me to https://api.drupal.org/api/drupal/core!lib!Drupal!Core!Render!theme.api.... as the "official" word on what elements are available, and that says: "...look for classes with the RenderElement or FormElement annotation to discover what render elements are available." If I do that, I find that the #type = 'date' should work.

And that's my main frustration: I'd be perfectly fine with a clear document that said 'date' was not permitted (or documentation that didn't list 'date' at all), but there is no documentation at all on what the allowed form elements are - you have to read LOTS of issues and LOTS of code and they all imply that 'date' is valid, so that's what I've been using in D8 for a year now. Then all of a sudden it starts throwing PHP notices and there are NO CHANGE NOTICES to explain this. I have to resort to git bisect and running my tests a dozen times to pinpoint which commit broke my code, then I'm told tough beans, you shouldn't have been doing that anyway.

I know you're the maintainer, so I will respect your decision on how to handle this - mark it as duplicate if you want, etc. But I think it's wrong to put this off - if it's known to be broken it shouldn't be in 8.0. If 'date' isn't allowed, then it shouldn't be allowed at all - recognizing 'date' as a valid '#type' yet delivering broken behavior is just not something that should happen.

As far as a true regression ... my code was working for a year until #1835016: Polyfill date input type. I consider that a step backwards.

+++ b/core/lib/Drupal/Core/Render/Element/Date.php
@@ -62,7 +62,7 @@ public function getInfo() {
     // Attach JS support for the date field, if we can determine which date
     // format should be used.
-    if ($element['#attributes']['type'] == 'date' && !empty($element['#date_date_format'])) {
+    if (!empty($element['#attributes']['type']) && $element['#attributes']['type'] == 'date' && !empty($element['#date_date_format'])) {

I think the common approach for this is to set up defaults in getInfo(), so that those default attributes and so on are always set, or set them up in process (because array defaults aren't merged).

I would expect to have this behavior as the default if I just use #type date, otherwise I won't get the polyfill?

For tests, there's just one place where any date from element is currently used and that is FormTestDisabledElementsForm. Not really the correct place to add test coverage for this I guess but it should actually be there anyway, so that might be enough ? ;)

Here's the test that we need to fix.

And here is the fix, setting the default values needed, like Berdir suggested in #10.

Updated issue summery and added beta evaluation.

I'm not sure if this being a regression makes it more important to fix or not, but since it's a non API changing bugfix to a regression, this should be fine to get in.

We have tests, so not needed anymore.

Nice find, nice fix and nice test. Committed 9f6d914 and pushed to 8.0.x. Thanks!

#8 is the correct one. To avoid the notice need to to define '#type' = 'datetime' and to remove the time field you can use below code.

'#date_date_element' => 'date',
'#date_time_element' => 'none',

Thanks,
Anoop Singh