Default value in blueprint for site.yml doesn't populate the field

The CMS Questions
1

I’m trying out K3 for the first time and want to have some settings field in the site.yml blueprint with default values, but the default never show up in the panel.

My field in the blueprint looks like this

footer_headline_one:
        label: Rubrik 1
        type: text
        default: Om oss
        required: true
        width: 1/2
2

This might be intended behavior.

Compared to pages, default values are used to populate the field when the page is created, but the site is already there and so defaults will not be used.

Instead you could use the e() method in your template (untested):

<?php e($site->footer_headline_one()->isNotEmpty(), $site->footer_headline_one()->html(), "Om oss" ?>
3

That’s a bummer. It’s working fine in K2. And the problem is that I want the fields to be required also.

4

Not sure this is intended behavior. Yes, it does work like that, but for the site it doesn’t make sense.

@felixbridell Could you create an issue on GitHub?

5

Issue created on GitHub:

6

@flokosiol is right. In v3 the default values only apply when a page is created why it doesn’t work for the site. I think what we need instead is something like an additional fallback value that always fills form fields when they are empty. Doing that for the default value would be very confusing and not wanted in many scenarios.

1 Like
7

This behavior then also applies for the home page, because that page also exists right from the beginning and setting a default value will do nothing.

8

It’s already possible to add a fallback in the template with the or field method: $site->footer_headline_one()->or('Om oss')->html().

Maybe it doesn’t belong in the blueprint.

9

Yes, that’s true. I’d say that we could also inject the default value, when you hit save. But this is also not necessarily intended. Sometimes you want to leave a field empty instead and we couldn’t detect that case. Difficult! I think the behavior in v2 wasn’t correct.

10

But the problem is then that I want to use the default value as a hint for the panel user what to write inside the field, not just to use it on the template.

With the ->or() it would not be possible to use the default value as a starting point for a text where the user is suposed to change just some content:

For example:
This is a text for (put your name here) …

11

Instead of the default value, you can use a placeholder and/or help text?

This has the additional advantage that the default value is not stored.

12

That is of course possible. Still think it would be a good idea to have a default/fallback value for the field.

13

I’m not so sure that having a default value stored in the content file is always a good idea, depending on use case. If it is just for the user to know what to fill in, the help text/placeholder probably makes more sense.

14

True. I will go with the help text for now, thanks for the tip.
But I still think it could be a good option to have… In my case the fields are also required so it’s good to store the default value.

15

I do agree that the current behavior is the right way, because you can always set a missing default like @pedroborges mentioned (I always forget about or()) in template, but not the other way round.

16

I would like to define text boxes for a theme in which you can use color values ​​to change some colors of the theme. Here it would be good to have default values.

1 Like