- Do you want to request a feature or report a bug?
Request a feature
- What is the current behavior?
When emptying a field in the CMS, then re-publishing, it leaves the example: there
- If the current behavior is a bug, please provide the steps to reproduce.
- What is the expected behavior?
Delete it completely
- Please mention your CMS, node.js, and operating system version.
Netlify CMS 1.0, Node.js 6.12.3
- Please link or paste your config.yml below if applicable.
````yaml
backend:
name: git-gateway
branch: master # Branch to update (optional; defaults to master)
publish_mode: editorial_workflow
media_folder: "images"
collections:
@TristianK3604 What field were you wondering this about? Most fields seem to be removed automatically for me.
@tech4him1 It's for all the front matter fields, the one I specifically would like Netlify CMS to remove is "Documentation URL".
It looks like this is only for string widget fields, other fields are removed from a file if empty and optional.
Unfortunately, fixing this would represent a breaking change, since templates may be relying on an ever-present field with an empty string when empty.
@TristianK3604 honestly, I'm tempted to say removing vs. not removing is a horse a piece. The inconsistency isn't good if other widget fields are removed when empty, true, but can't you just check for the empty string value for your use case?
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This issue best explains #2848, #2007, #1449, and #2017 - closing those in favor of this.
When a widget returns a falsey value that should not be persisted (often an empty string), the widget should instead pass null to onChange, which results in the key being removed in the output. We can't enforce this from the core because the Widget API should support persisting an empty string if that's what's desired, but the in-repo widgets should be doing this.
Because many Gatsby sites are likely depending on the current behavior, we should introduce this as off-by-default until 3.0, but enough users have brought up this issue that it seems worth addressing sooner rather than later.
Here's another use case and why this is relevant for me:
When you have an editable slug field that will be used by Jekyll in a permalink like /blog/{{slug}}/.
By default Jekyll will get the slug from the file name, which comes from the title.
title: 'Oh hai there' # URL would be: /blog/oh-hai-there/
But that can be overwritten with the slug property.
title: 'Oh hai there'
slug: 'hai' # URL is now /blog/hai/
What's sad is that if you change your mind and remove the value in slug through the CMS _after_ creating the file, the slug property will still be in the frontmatter as an empty string鈥攚hich will effectively ruin the URL.
title: 'Oh hai there'
slug: '' # URL is now ruined /blog//
In case anyone's looking for how to deal with this for frontmatter images Gatsby.
You can work around this for now by explicitly typing the field in your GraphQL schema with File @fileByRelativePath
In gatsby-node.js:
exports.createSchemaCustomization = ({ actions }) => {
const { createTypes } = actions
// Explicitly define the Markdown frontmatter object
// This way those will always be defined as file even if CMS leaves a blank string
// This way the queries will return `null` even when a blank string is left
createTypes(`
{ ... }
type MarkdownRemark implements Node {
frontmatter: Frontmatter
fields: Fields
}
type Frontmatter {
{ ... }
imagePath: File @fileByRelativePath // this is the important bit
{ ... }
}
{ ... }
`)
}
Most helpful comment
This issue best explains #2848, #2007, #1449, and #2017 - closing those in favor of this.
When a widget returns a falsey value that should not be persisted (often an empty string), the widget should instead pass
nulltoonChange, which results in the key being removed in the output. We can't enforce this from the core because the Widget API should support persisting an empty string if that's what's desired, but the in-repo widgets should be doing this.Because many Gatsby sites are likely depending on the current behavior, we should introduce this as off-by-default until 3.0, but enough users have brought up this issue that it seems worth addressing sooner rather than later.