Custom Fields
Support General Readonly Date Input Still Shows Datepicker

This topic contains 5 replies, has 3 voices, and was last updated by  Anh Tran 1 week, 4 days ago.

  • Creator
  • #16711

    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)

Viewing 5 replies - 1 through 5 (of 5 total)
  • Author
  • #16721

    Anh Tran

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


    Ryan Lauritsen

    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.


    Ryan Lauritsen

    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.



    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!

    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: ) to ensure the field doesn’t pass validation unless the format is mm/dd/yyyy. 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:

    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).


    Anh Tran

    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.

Viewing 5 replies - 1 through 5 (of 5 total)

You must be logged in to reply to this topic.