-
Hi all, I have a collection of content that gets updated daily, and my plan was to set the title of the documents to the publishDate, perhaps with a prefix identifying the collection type. If I point useAsTitle at a date field, this error occurs because publishDate is a Date type, not a string: What I came up with to bypass is use a separate slug field and set its default to the current date:
... but then there's no guarantee that publishDate and slug will be consistent without a validation step. Can I do something with a field hook here? Payload rocks, enjoying digging in — thanks for making it open source!! Edit:
... which seem like what I need. Keeping up for viz on how useAsTitle breaks on non-string field types. Is there a validation step that could be built into the config to prevent non-string fields from being set as title? Can help write issue. Again, Payload rocks - these public examples are extensive. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
Hey @Andrew-Roca - good questions! I don't see why date-like fields couldn't be utilized for We could also certainly add validation rules to check and ensure that I'm not sure when the Payload team could get to the above features, but it's certainly interesting. We would happily merge a PR regarding these changes, but we might be able to get to it ourselves at some point too! |
Beta Was this translation helpful? Give feedback.
Hey @Andrew-Roca - good questions!
I don't see why date-like fields couldn't be utilized for
useAsTitle
- this could probably be enabled with a few checks on the frontend to make sure that the data is rendered properly if it is an incoming date. Might not be too tough.We could also certainly add validation rules to check and ensure that
useAsTitle
is set to a field that is able to be utilized properly. It would check to see if the field istext
,textarea
,email
,number
, and - if we ironed out a way to sanitize the incoming data, thedate
field could be added to that list.I'm not sure when the Payload team could get to the above features, but it's certainly interesting. We would happily …