Hidden widget fails to show up in front matter (Hugo)

[jonas-sk]

Describe the bug Using Hugo (specifically Victor Hugo), when setting a hidden widget, the key-value combination doesn't appear in the front matter of the generated document.

To Reproduce I haven't thoroughly tested the exact conditions. However, this is what I did:

1. Use "deploy to netlify" in the netlify cms docs (i.e. use the Victor Hugo template)
2. Add a hidden widget to the fields of one of the existing pages or create a new page with a hidden widget (i.e. in config.yml).
3. Edit the page (file collection) or create a new post (folder collection) in the netlify cms UI

In my case the problem manifested in both folder and file collections and in both new files created via the UI and old files edited in the UI.

Expected behavior The hidden widget should manifest in the front matter as a key-value combination. For example, when I have - {label: "Layout", name: "layout", widget: "hidden", default: "about"}, layout: about should appear in the front matter of that file.

Applicable Versions:

• Netlify CMS version: 2.9.1
• Git provider: GitHub
• OS: Windows 10
• Browser version: Firefox 66.0.3
• Node.JS version: 4.1.2

CMS configuration You can find it here: https://github.com/jonas-sk/pine-maastricht/blob/master/site/static/admin/config.yml. The problem specifically shows up in posts, projects, and conference-2019

[saenglert]

I'm having the same issue where I try to set a hidden field with a default value and it won't show up.

Applicable Versions:

• Netlify CMS version: 2.9.1
• Git provider: GitHub
• OS: Windows 10
• Browser version: Firefox 68.0.1
• Node.JS version: 10.15.3

I've noticed however that this issue only occurs inside file collections. Folder collections work as expected. Files have to be present at first edit while folder entries can be created on the fly. Might be related to the issue?

[androdel]

I have the same issue as well, but in combo with Gatsby. Can someone take a look at this? This issue is already a couple of months old.

[CRNRSTD]

+1, same issue with file collections.

PS. I find that any widget with 'default' option set won't work in file collection

[barthc]

PS. I find that any widget with 'default' option set won't work in file collection

Yup the default option only works for folder collections and more specifically while trying to create a new entry.

@jonas-sk are you still having issues with the default option on your folder collections?

[barthc]

Also, forgot to add that the default option now works on the list widget add + button.

[saenglert]

Yup the default option only works for folder collections and more specifically while trying to create a new entry.

Isn't that something that should be mentioned in the docs?

Also: Is there a specific reason for that? Adding default values seems really useful everywhere not just folder collections.

[erquhart]

A default value can only ever apply when creating a new entry. If you load an existing entry, it has to be loaded as-is, otherwise fields intentionally left blank would keep being populated with default values every time you edit the file.

File collection entries can't be created - they're one-offs and must already exist in your repo, so the concept of defaults simply doesn't apply. That said, if you want to open a PR to add a note about this in our docs, please do!

[saenglert]

otherwise fields intentionally left blank would keep being populated with default values every time you edit the file.

Thats kind of the point of a default value isnt it!? If no value is given and a value is required insert the defined default value. The field would stay blank if no default value was defined.

In case of further edits now there is a value set already (the previous default value) so the system should not overwrite that with the default again.

they're one-offs and must already exist in your repo, so the concept of defaults simply doesn't apply.

The file has to exist but it can be empty. The information which is the important part can be added at a later date through widgets.

So either the cms has to make sure that file collections contain the information according to the config from the moment the file is added/loaded or it has to deal with the fact that it can be added later through widgets and make use of all the options provided.

This current system seems like it has a design flaw because it expects the code to be written in a certain way while providing other options and silently ignoring those options.

[erquhart]

Thats kind of the point of a default value isnt it!?

I feel like we're missing each other here. Let me float a scenario:

1. User creates a new entry. Lots of optional fields with default values.
2. The user deletes a bunch of those fields so their values are blank.
3. The user saves the entry.
4. Later on, the user re-opens the entry to make a small change to a single field.

At this point, all of those fields that were intentionally made blank have been repopulated with default values again. The user would have to go and delete them all again before saving. And they would have to remember which ones they wanted deleted - if this is a different user than the creator, they may not know. Finally, this whole scenario replays every time the entry is changed.

This is why default values can't ever be used in existing entries, hope that makes sense.

The file has to exist but it can be empty. The information which is the important part can be added at a later date through widgets.

Same logic applies here - the CMS does not know if this existing entry is empty because it's waiting to be populated for the first time, or because it's intentionally empty. The above scenario applies here as well.

This really doesn't make sense for file collections - they're one off, so you have to create a distinct configuration object for each file and manually create the file. When you create the file, just add the default value in the file itself.

[saenglert]

the CMS does not know if this existing entry is empty because it's waiting to be populated for the first time

The cms can't differentiate between a widget having set required to true (by default *pun intended*) or false? Because if it is not required empty is a possible value and if it is required and empty the cms could throw an error like it does when trying to save a required field in the ui.

they're one off, so you have to create a distinct configuration object for each file and manually create the file

Sure but this file can contain for example list widgets whose entries can require default entries.

Edit:

[Example...] At this point, all of those fields that were intentionally made blank have been repopulated with default

Then the cms is not working correcly because if a widget is optional undefined is a correct value and should not be overwritten by defaults.

To build on my question above: I attached a grid how I'd expect defaults to work for file collections when trying to set an empty value

[erquhart]

You're looking at a lot of variables here, it isn't that complicated.

Required fields are not a part of this discussion, so we can simplify things by leaving those out of mind.

For optional fields that are blank but have a default value set in config, we can either:

1. Assume the field was not made intentionally blank and fill in the default value
2. Assume the field was made intentionally blank and don't fill in the default value

Either way we are making an assumption. We have no way of knowing whether the field is intentionally blank. This is the only issue being discussed here.

[saenglert]

Why are required widgets not part of the discussion? Any widget is required=true by default according to your docs?!

And if requiered it should not be able to be empty (except for when first initialized) because you per definition require a value to work with. I'm sorry but I really can't follow your train of thought here.

[erquhart]

So the single change you're looking for is for empty required fields to have default values applied. Is that right?

[saenglert]

Yes, I guess thats the most essential point.

Next up if this is applied consistently it would solve the issue of file collections and default values. Because then you could conclude by logic that a file collection with empty required fields is loaded for the first time and defaults should apply (-> throw error if no default present).

On a completly different note: Filtered collections. Currently filtering is limited to a simple field:value format via the "filter" field and value has to be a string. However fields can have all types of values and it should be possible to for example filter by multiple values in case of lists.

Use case: I'm currently working on a backend thats supposed to handle news based on tags. So for example a news article may have the tags domestic, politics. To limit user error I'd like to add a folder collection in which all news have those tags by default. Thats quite easy, I add a simple hidden list widget and set those values as default.

However if I want to only display articles with those tags when selecting this collection I can't pass multiple values to filter by. I haven't been able to find the exact spot in the code where this filtering happens. Could you please give me a pointer to where the filter field is processed so I can possibly propse a change?

Sidenote in a sidenote: Your jsonConfigSchema doesn't validate the filter field as far as I can tell.

[erquhart]

Agreed, a loaded entry should have empty required fields populated with default values, always.

[martinjagodic]

Closing as stale