Meta Box

Readonly Date Input Still Shows Datepicker

Support › General › Readonly Date Input Still Shows DatepickerResolved

Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
    Posts
  • October 26, 2019 at 5:45 AM #16711
    brandonjpbrandonjp
    Participant

    FYI - When I add a custom attribute of 'readonly'=>true to a date field, the datepicker still shows in the UI and allows me to change and update the value.

    Note: Setting 'disabled'=>true works as expected (prevents the datepicker)

    October 28, 2019 at 9:04 AM #16721
    Anh TranAnh Tran
    Keymaster

    Thanks for your feedback. Somehow readonly is ignored by jQueryUI datepicker. I fixed it here.

    November 1, 2019 at 11:26 PM #16771
    Ryan LauritsenRyan Lauritsen
    Participant

    Unfortunately, we were using the fact that it ignored readonly to get around the lack of format control for the date entered into the input. We had date fields set to readonly to force users to use the datepicker so that we forced the format of the date to be our preferred format. Otherwise, we had users entering years as 2 digits (e.g. 01/01/20 instead of 01/01/2020) which doesn't work for us.

    This fix has prevented the workaround we were utilizing so how can we now force the year to be 4 digits? We already have the dateFormat attribute set to mm/dd/yy but that doesn't prevent a user from typing a date with only 2 digits. We also have the save_format field setting set to Y-m-d and that doesn't help either. I've searched the jQueryUI documentation and not found a solution.

    November 1, 2019 at 11:42 PM #16772
    Ryan LauritsenRyan Lauritsen
    Participant

    Why was this "fix" even needed? If you don't want the datepicker, then don't use a date field. Use a text field instead. If it has to do with forcing a date format, then either use validation on a text field to force the format or maybe we need an option to turn the datepicker on/off for date fields.

    November 2, 2019 at 5:25 AM #16774
    brandonjpbrandonjp
    Participant

    @Anh
    I can understand both sides of this. But for me, this is not a major issue either way. So do what you think is best for MB, of course!

    @Ryan
    Regardless of what's done, I wonder if using a pattern attribute would help? Maybe something like (0[1-9]|1[012])[- /.](0[1-9]|[12][0-9]|3[01])[- /.](19|20)\d\d (I stole that one from: http://html5pattern.com/Dates ) to ensure the field doesn't pass validation unless the format is mm/dd/yyyy. https://i.imgur.com/tdHJXfT.png Then your users could still manually input a date (IF that's desired). Also, I tested setting the display values & save_format and they all seem to be working correctly for me based on the docs -- If those aren't working for you, that could be a separate issue to look into. Here are the values I was using in Builder to quickly test: https://i.imgur.com/ZJFvMX4.png

    I first came across this and posted it because we were having cases when the field was readonly but users were tabbing past the field and the datepicker was showing and they were submitting data. Basically, it just seemed incorrect that a 'readonly' field wasn't read-only. For us, the problem was that the field has different attributes based on conditions (beyond just MB conditions/logic). And while enabling/disabling the datepicker is an option, it wasn’t our approach because it seemed more accurate that a readonly field should not be allowed to change. (Of course, as Anh mentioned earlier, jQuery UI chooses to ignore readonly.)

    Our workaround was to use a disabled input, but that prevents the field from submitting (which was an issue because we still wanted the input to submit every time).

    November 4, 2019 at 9:03 AM #16780
    Anh TranAnh Tran
    Keymaster

    I think there are 2 issues here:

    • Read-only attribute, and
    • Validation for user input

    From MDN

    A Boolean attribute which, if present, indicates that the user should not be able to edit the value of the input.
    The difference between disabled and readonly is that read-only controls can still function, whereas disabled controls are not submitted with the form and generally do not function as controls until they are enabled.

    So, it's better to prevent user to change value from a read-only date picker (the 1st issue).

    The validation issue is quite different and I think can be solved with @brandonjp's solution with pattern attribute.

    Another issue with readonly is that it will ignore the required attribute (ref in the MDN docs above), which sometimes is a problem.

    December 3, 2019 at 4:46 AM #17305
    Ryan LauritsenRyan Lauritsen
    Participant

    @Anh
    What was your final decision on this?
    Going forward if 'readonly'=>true will the datepicker show or not?

    From your last post, it sounded like the datepicker will NOT show but I just want to confirm that since I'll have to make some changes on my end if that's true. Thanks!

    December 3, 2019 at 10:26 AM #17308
    Anh TranAnh Tran
    Keymaster

    Hi Ryan,

    Yes, I made the readonly doesn't show the datepicker. It was deployed in the latest version of Meta Box.

    December 3, 2019 at 5:34 PM #17328
    calpaqcalpaq
    Participant

    Hi Anh,
    Thanks for directing me to this topic.
    I am using date picker in readonly fields from last 3 years, in which user has only option to choose date in the format specified. Datepicker has dateformat option which solved defining patterns, change easily and which is less clumbersome than finding regex value for the different patterns we wanted, also you do not have to think for character length or size. I have 3-4 forms having number of date fields now I have to change all forms and I have less time to change & test it. Can you please give me some workaround like attributes readonly=true & { nodatepicker=true / nodatepicker=false}
    Thanks & Regards
    Calpaq

  • Author
    Posts
Viewing 9 posts - 1 through 9 (of 9 total)
  • You must be logged in to reply to this topic.