getkirby.com
getkirby.com copied to clipboard
Date field saving format issue in blueprint
With a blueprint like this:
fields:
releaseYear:
min: "1800/01/01"
max: "2022/01/01"
type: date
display: YYYY
format: "Y"
Expectation
What I expect to see is only the year part of the date being saved.
Actual result
It saves correctly to the page's content file but when the page is re-opened in the panel, the date is not the saved year.
If format is simply changed to Y
(without quotes), the digit 1
is stored in the content file.
If the format is Ymd
, it works. It saves the year, month, and date.
If format is simply changed to
Y
(without quotes), the digit1
is stored in the content file.
This is because the YAML syntax treats the Y as a boolean ("yes") and converts it to true
. And the true
value is then converted to 1
. So it can only work quoted.
[With
format: "Y"
] It saves correctly to the page's content file but when the page is re-opened in the panel, the date is not the saved year.
I can reproduce this part. If I use the field configuration you posted, the Panel cannot parse the value. For example if I store 2020
, the Panel parses and displays that value as 2022
. I believe that's because the Vue part of the date field doesn't have a parsing format for just the year.
@distantnative Back when you worked on the refactoring, we discussed deprecating the format
option entirely. What is the state of that? I feel that we should always go for the "ISO 8601 without T
in the middle" format. There are just too many issues with custom storage formats.
@ment4list There are two possible solutions for your use case:
- Either store the full date and then use the
->toDate()
field method to just print the year. - Or use a number field that stores just the four-digit year.
We talked about deprecating format
but it would be just too big of breaking change as there is a lot of content out there stored with a custom format. I am surprised though that 2020
reaches the Panel as value - cause there we did say communication between Panel and backend must always happen in "ISO 8601 without T in the middle" format. So if that's the case, then the bug is with the backend not transforming the value from the content file correctly based on the format
option before sending it to the Panel.
YYYY-
actually is in the list that the Panel uses for interpreting dates
Ah, right. I remember the decision to use the communication format.
I haven't actually checked what the backend sends to be honest. I can only see the Panel displays 2022
with an unsaved changes bar.
@ment4list There are two possible solutions for your use case:
I have chosen to use the number field for my use case which is sufficient.
Thanks for the help.
Thanks for your feedback, good to hear the workaround works for you.
I'm still reopening this issue because of the bug in the date field.