I added a field to the User Accounts, of type HTML 5 Date widget.

However after this trying to register a new account fails, as the widget is unavailable, but the system expects it, so it fails with a 500 error, and Datetime requirements for form.inc.

Removing the field enables registrations to happen.

Accepted answer

I was able to reproduce!!!

It happens when you have a default value for the date. I'll look into this tonight and will create an issue in the main issue queue.

Thanks!

Most helpful answers

I created an issue: https://github.com/backdrop/backdrop-issues/issues/6027

 

Hopefully this will be tackled soon.

Onyx, thanks for the followup.

I'm not able to reproduce, but this sounds like a really serious issue that needs to be fixed. Would you help me try to reproduce? Give me as much detail as possible about your Date field:

- In field type, did you pick Date, Date (ISO format) or Date (Unix timestamp)?

- Go to configure for your field and post a snapshot of all configurations, including the "Global" fieldset at the bottom

- Let me know when this is happening. Since the field is not displayed in the user registration form, I assume this is happening when you edit a user? Is this happening only to admin? authenticated? other?

- What theme are you using?

- Is this field wrapped in any container provided by contrib? (E.g. Paragraphs or Field Group, etc)

Comments

I'm unable to reproduce this issue. It's working fine for me.

Did you check the "Display on user registration form." box when adding the field to the account entity?

This is what the account registration looks like with the new field.

Is this a multilingual site? Any contrib modules installed?

And a couple of more questions:

- Browser? HTML5 widgets asre dependent on the browser

- PHP version?

Hmmm, working for me now, and I did the delete/reinstall twice... Thanks anyway

PHP8.0-fpm, Vivaldi + Firefox

Further to this, if the HTML5 Date widget is attched to User Account, but not required on the User Registration form, it does break, and this is why:

Snippet from a fixed form.inc (3298):

/**
 * Validate a date string.
 */
function html_date_validate($element, &$form_state) {
  $date = $element['#value'];
  if (!empty($date)) {
    $valid_date = FALSE;
    //TypeError: DateTime::createFromFormat(): Argument #2 ($datetime) must be of type string, array given in DateTime::createFromFormat() (line 3298 of /var/www/clients/client1/web1/web/core/includes/form.inc).
   // dpm($date);
    //... (Array, 1 element)
//date (String, 10 characters ) 2023-03-12
    if(is_array($date)){$date=$date['date'];}
    $created_date = DateTime::createFromFormat(DATE_FORMAT_DATE, $date);

As you can see, the HTML5 Date widget sends an array, but it wants to validate a string. PHP 8 barfs, throwing 500 error.

Onyx, thanks for the followup.

I'm not able to reproduce, but this sounds like a really serious issue that needs to be fixed. Would you help me try to reproduce? Give me as much detail as possible about your Date field:

- In field type, did you pick Date, Date (ISO format) or Date (Unix timestamp)?

- Go to configure for your field and post a snapshot of all configurations, including the "Global" fieldset at the bottom

- Let me know when this is happening. Since the field is not displayed in the user registration form, I assume this is happening when you edit a user? Is this happening only to admin? authenticated? other?

- What theme are you using?

- Is this field wrapped in any container provided by contrib? (E.g. Paragraphs or Field Group, etc)

Thanks. Here we go:

-Just Date.

This is actually happening when manually registering a user. Which suggests that there is data both auto-filling and required for that form field despite it being unnecessary, otherwise it would not be hitting the Validate function of form.inc. It has only happened as Admin and unauth (trying to sign up to site), because that's all that's been tested thus far.

Themes: bootstrap lite and bootstrap lite 5 have both had the issue, haven't tested with another.

The field is not wrapped in anything else, but is merely connected directly to the User accounts as a way for back-end admin noting when the user has been internally 'confirmed'.

I was able to reproduce!!!

It happens when you have a default value for the date. I'll look into this tonight and will create an issue in the main issue queue.

Thanks!