After upgrading to Backpack 6 datepicker field always has readonly attribute.

[Uteev]

After upgrading to Backpack 6 datepicker field always has readonly attribute. That makes readonly field colored into a gray color and confuses users as they think that field is disabled though it works as always.

I researched the code and in the date_picker.blade.php the following code on row 12

$field['attributes']['readonly'] = $field['attributes']['readonly'] ?? 'readonly';

deliberately makes the field readonly.

So I tried pass another options through crudcontroller. For example

[
    'name'  => 'date_needed',
    'type'  => 'date_picker',
    'label' => 'Date Needed',
    // optional:
    'date_picker_options' => [
        'todayBtn' => 'linked',
    ],
    'attributes' => [
        'readonly'=> false,
    ],
    'wrapper' => [
        'class' => 'form-group col-md-4',
    ],
    'tab' => 'Main',
],

And the false is applied but the browser still makes the field readonly. At least Safari.

So I don't understand why we need to make the field readonly by default? It misleads users and brings no benefit. The fix for this is very easy. Just totally remove the code on the row 12 of date_picker.blade.php that is

$field['attributes']['readonly'] = $field['attributes']['readonly'] ?? 'readonly';

Could you please help with this fix?

[jcastroa87]

Hello @Uteev we will check about this line, because as i check is exists for more than a year, so need to go deeper to understand the reason, i will back to you with and answer soon.

In any case meanwhile you can delete the line for your project or handle with css like:

background-color: #fff!important;

Cheers.

[Uteev]

Hi @jorgetwgroup! I have upgraded from backpack 4.1 so it may very well exist for more than a year. I know I can just modify this type of field for my project but it seems there is no reason to make the field look like disabled. So I hope it will be fixed in the backpack.

[pxpm]

Hey @Uteev long story short, I will copy paste here what we did in a PR that's currently in review to fix this issue:

This started as a report in https://github.com/Laravel-Backpack/CRUD/issues/1910 that we fixed in https://github.com/Laravel-Backpack/CRUD/pull/1962 sometime ago.

The original problem was that we were preventing keyboard navigation because the field wouldn't accept a user provided date (need to be picked from the calendar).

Adding the readonly partially solved this issue, but raised other issues like the fact that a readonly field has a slight color variance to distinguish it from regular fields as reported in https://github.com/Laravel-Backpack/community-forum/issues/695

In this PR I went back to kind of the same approach we had at first, by intercepting the keyboard navigation, but instead of blocking the keyboard navigation at all, I just close the picker if any of the non-supported keys is pressed. https://bootstrap-datepicker.readthedocs.io/en/latest/keyboard.html#up-down-left-right-arrow-keys

That way you can still use the left, right, top, down arrows to navigate plus esc and enter for interaction and all other keys will just close the picker and move on, not blocking you from keyboard navigation in the form.

I used also inputmode https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/inputmode to avoid showing the keyboard on mobile.

Thanks for raising the issue and sorry for the bad experience 🙏

[Uteev]

Hi @pxpm! Thanks for the explanation. Now I see the reason for making the datepicker readonly though it lead to other issue. I think you came up with a great solution that enables us to eat the cake and have it! So waiting for your solution to be implemented.

[pxpm]

Hey @Uteev sorry I think we made some mistake here. We merged the PR but didn't tagged a new version 😞

I've just noticed that today when I tagged a new version with a fix to other unrelated issue.

So ... the fix for this is in backpack\pro 2.0.19 🤷

Cheers