Enhancement: Add alternative method for content type identification

[michaeltlombardi]

Is your feature request related to a problem? Please describe.

Currently, the only way to have Front Matter recognize a file as a particular content type is to define the type field in the file's frontmatter and have that value map to a known content type.

For some static site generators, like Hugo, the type field carries semantic meaning outside of Front Matter. This can (but doesn't always) cause conflicts or require work arounds for defining content types in Front Matter.

Describe the solution you'd like

I would like an alternative way to inform Front Matter about settings/behaviors specific to Front Matter, rather than the content/static site generator.

For example, adding the _frontMatter (or other name, this is just an example) field as a map of key-value pairs (type being one of them) and overriding other discoverable values with those would allow Front Matter to be used side-by-side with static site generators that have colliding field names.

If the _frontMatter field is an optional override, it won't require any additional changes from users who don't have to resolve the conflict.

Describe alternatives you've considered

Right now, the only alternative is to ensure my content types always match my Hugo types and try to account for the complexities of differing needs with the newly implemented #362 and conditional UI.

Additional context

If the _frontMatter field is implemented, the UI can be updated to have a foldable section in the side bar for altering settings specific to that file and Front Matter, if needed (though I think that's a separate feature request if this is implemented). This also opens the possibility of extending/overriding (a limited subset of) behaviors on a per-file basis. For example, defining an alternate preview path or metadata requirements. Again, I don't mean to bikeshed on that idea here, simply to remark that implementing this feature to resolve a field name collision opens the possibility for investigation and discussion.

[dennisl68-castra]

So what about supporting a field for what it actually is?

ContentType

[estruyf]

For this, we also need to think about how to remap older articles that already have the type defined, but contenttype can make sense.

[michaeltlombardi]

I think adding a limited set of convenient top-level keys is a good idea for ease-of-use (like contentType), but if this usage starts to expand it'll be best to keep it in a map of settings specific to Front Matter to avoid conflicts with other tooling.

I'd suggest that we add contentType and frontMatter.contentType with the following override logic:

# Old specifier
type: foo
# new convenience key
contentType: bar
# explicit setting
frontMatter:
  contentType: baz

1. If frontMatter.contentType is defined, don't check other keys to determine content type.
2. If frontMatter.contentType isn't defined, check contentType to see if there's a matching content type defined. If there is, use that.
3. If frontMatter.contentType isn't defined and contentType is undefined or doesn't resolve to a matching content type, check type. If type matches an existing content type, use that.
4. If frontMatter.contentType isn't defined and neither type nor contentType resolved to a defined content type, use the default content type.

That should be backwards compatible. Thinking more about the top-level keys, my main concern is that there's always a potential for conflict, especially if they don't have a prefix and use terms that are relatively common (like type, contentType, etc) because they're semantically useful.

[estruyf]

For the next release, I'll add support for a new field called fmContentType. As @michaeltlombardi highlighted, using type or contentType might create other conflicts. By prefixing it with fm, it would be less common that people would use it.

Also, think about a global setting to define the content type field.

Logic would be changed to:

• Get the fmContentType from the article
• If not present, it will check the type field
• If not present, it will use the default content type