When adding custom fields in the Custom Type builder, add support for a default value in addition to the placeholder value.
Issue that it solves:
There are often scenarios where a default generic value will be appropriate most of the time, but the field still needs to be changable for when the user wants/needs to change it.
An example might be a Testimonials Slice. We want it so the user can change the title ("Hear from our customers"), but if not they can just leave it as the default ("Testimonials").
In practice once the design for a field included a Default Value, whenever this slice is first instantiated it should pre-fill with the default value.
Another example maybe where our founder "Tom Jones" writes most of the blog posts, its not the most refined solution, but he could be added as the default author for new posts, changable if the user desires to.
Having automatic or default values ​​is a feature that we have had in mind for some time now, it exists in the backlog of our product board, however there is still no estimated time for its development/launch.
For now I can recommend two variants:
Use a Select field. At the moment this is the only field to which a default value can be assigned. This can be a solution, with the disadvantage that the value cannot be modified from the writing room, and only when editing the field within the Custom type builder.
Use a Boolean field together with another field so that editors can know if it is mandatory to place the placeholder as a value or not. Of course this will require extra communication with the team, but it is another workaround.
I will keep this thread as an open feature request. And if there's ever any change for this, we'll communicate it here.
Let us know if you have any other questions or suggestions for us at any point.
Pau
closed , flag & select 'Something Else' to reopen.
4
What is the expected behavior when adding a new field (either to a slice or primary section) and default value? Is it possible to set the default value for all documents without having to save each one?
Our use case is we wanted to add a boolean toggle to control showing/hiding another field. We default to true to be backwards compatible, but we see existing docs return null.
We are not seeing the same behavior as this ticket where we have to toggle it, we just have to "publish", but we also have hundreds of documents, so it would be tedious to have to save each one.
Sorry about the delay in the reply. I moved your comment here as it's more relevant to this open feature request and also maybe this other bulk actions request:
The behaviour you're experiencing here is the expected behaviour, as adding a new default populated field and republishing already existing documents could cause breaking changes to user's applications. I'm not sure it's so dangerous with a boolean, but the problem might be how republishing affects other fields in the documents. I'm reaching out to the team to get more information about this.
The workaround for the moment in your case to trigger a default boolean value for hundreds of pre-existing documents would be to use the import/export feature (beginning on the medium plan). You would export all the documents, run a script to update all the boolean fields and re-import them, this would trigger the publish again on all these documents and the content would stay the same except for the boolean field.
I realise this is less than ideal and I think this is why something like this is a good candidate for bulk actions. I'm also going to reach out to the UX research team about this to get their input.
If/when anything changes for this we'll update you here.
OK, so I talked to the team and the issue with setting the default value in the existing documents is that basically we don’t have any data in the database for this specific field for an old document.
We could have chosen to have the field dynamically rendered as “default value” in the api but the problem is that when people would look for a document with the value “default value” in the API, the document would not have been returned because the field is actually empty in our database.
The team would like to find a solution at some point for that to better help situations like yours, but there is nothing in the works at the moment. I've passed your feedback on to the team though.
Thanks for confirming the behavior @Phil . We can handle these cases on our end for now. I am not sure if you would know, but our engineering team feels like this was changed in the last few months as we have used the default value before (at least for boolean), and it was OK.
However, I can not confirm if we previously defaulted to false, which may have masked this issue.
button to show your support for the feature and check out our