Edit entries lacking frontmatter

[PEZ]

I would like to be able to edit Jekyll/Liquid page fragments (that you include or include_relative), but those can't contain frontmatter and the CMS requires frontmatter for me to edit the text. If frontmatter was not required I could edit these fragments.

I'm working with a site that is mostly a one pager and the sections of the page are stored in fragments. The only way I can let the content managers of the site work with this content is to let them use git/github, which sort of defeats the CMS idea.

If I am missing some option to get this managed in Netlify CMS, I'm eager to learn

[erquhart]

Hmm...good point, we do require frontmatter. Fair request 👍

The challenge is that we rely on at least one field to serve as the identifier field, both for UI purposes and for creating the entry slug. If we can find a way around that, the rest of the fix for this request should be straightforward.

[Benaiah]

Presumably the identifier field for a page fragment could just be the fragment file's path within the repo - that's how it's typically consumed in include statements as well. Since there's no way to store other fields without frontmatter available, any human-readable labels would need to be explicitly added in the config.yml.

[verythorough]

Bumping this as it came up with multiple docs projects at Write the Docs. Some popular docs generators (including VuePress and MkDocs) don't require frontmatter, which means they may not be able to work with Netlify CMS.

[verythorough]

Could also be semi-related to https://github.com/netlify/netlify-cms/issues/445, in that filenames may be identifiers for files with no frontmatter. Also worth thinking about how slugs might be generated from the first line of a file when no frontmatter is present. (Without such a provision, you can't create new files in a collection with no frontmatter.)

[Ir1d]

Hi, any update on this? really looking forward to using mkdocs with netlify-cms :smile:

[verythorough]

Being reminded of this issue just gave me an idea. In the same way that a widget named body is given special handling (added to the body of a file rather than as a frontmatter field), maybe the same could be done for a widget named something like filename or slug: instead of saving the value in frontmatter, it applies it to the file name.

For collections that don't have frontmatter, filename (or slug, or whatever) would be a required field, and would solve the problems above of a) determining filenames for new items in collections and b) having a field to key off and display in collection listings. For collections that already have frontmatter fields, folks could add the widget as an optional override to the built-in slug generation that's already in place.

[stale[bot]]

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.

[Semiotikal]

any update or workaround on this? I'd love to use decap cms but i'd prefer to make use of it in mkdocs or other python-based docs framework.

[martinjagodic]

@Semiotikal the best way to move this forward is to submit a contribution.