Enhancement: Link a page folder to a content type

[estruyf]

In some cases, a content type will only be used for a specific page folder. For example: the blog content type will be used for posts page folders.

It would be helpful to link the page folder to the content type, that way, while creating new content, Front Matter will not require to ask where the content needs to be created.

[bwklein]

I had this exact same setup thought yesterday. My instinct was to try to set a list of content types per location. One or more options for what kind of content would go into a particular folder. Then when making new content, I would first choose the content location/path and from that choice which content type to put in there.

[estruyf]

@bwklein would you rather have the folder to define which content type to use in it? Or would you define the folder on content type?

Both are possible, maybe defining it on content type level is more straightforward.

[zivbk1]

I have a site where I have more than one content type in the same folder. So as long as I can specify what I want to make and where it should be placed, it doesn't really make a difference which order I do it in. Either way in terms of the configuration of the folders for a content type, or the content types for a folder, the entries will probably have to be an array. So that there can be more than one destination for a type or types for a destination.

[estruyf]

Just some use cases:

Setting the folder link to the content type

When the property would be set on the content type, the question to create content should be in the following order:

1. What type of content do you wish to create?
2. Where do you want to create it?

The second question is based on the property. If present, it will skip it, and create the content, if present, it will create it in the corresponding folder.

If you want to use the content type for multiple folders, you should not be setting the property on the content type. That way you have the same experience as to how it is right now.

Disadvantage: This might limit the content type. If you have multiple folders with similar content types. You'll have to recreate the content type for each folder or unset the value. Another solution would be to specify multiple folders.

Setting the content type for a page folder

When the property would be set on the page folder level, the order of questions stays the same as they are right now.

1. Where do you want to create the content?
2. Which type of content do you want to create?

In this case, the second question is yet again based on what is defined in the location setting of the previous question. If a content type link is set, the type of content does not need to be defined anymore.

When setting it on the folder level, you are still able to use the content type for any folder that is not using the content type link.

Disadvantage: Limits one type of content per folder. Although, this limitation is less impactful than setting it on the content type level. We could also allow setting one or more content types on the page folder level. That way, if one is defined, the type of content will not have to be asked. If multiple are present, the second question will be based on these values.

Advantage: As every content type already has an ID/name, they are easier to be mapped.

[gerwitz]

I really want this, as I have an existing site without explicit type fields because most files are typed via their path.

I'd prefer to set one default content type per path, because I have some file types that "float" across this structure. (Though, really, those are more data than post files, in the style of #406)

[estruyf]

Thanks @gerwitz, so you would go for option two. Setting a content type for a page folder.

[gerwitz]

Thanks @gerwitz, so you would go for option two. Setting a content type for a page folder.

Yes, but also allow it to be overridden.

Respecting metadata per file would be great, but FYI my ideal would be an ordered list of path matching patterns. E.g. (with pseudo patterns)

• blog/yyyy/yyyy-mm-dd/slug.md: article
• */photos/slug.md: photo

Probably this is better handled via page bundles, so feel free to ignore my rambling 😆

[estruyf]

Yes, but also allow it to be overridden.

There will always be the type property that can be set in your article's front matter, defining the content type to use. That property will allow you to override it per file.

Respecting metadata per file would be great, but FYI my ideal would be an ordered list of path matching patterns. E.g. (with pseudo patterns)

That would be option one. There are PRO's and CON's for both approaches. At the moment, I'm more in favor of implementing option two but wanted to hear the feedback first.

[estruyf]

Good news, you are now able to give it a try!

On the folder defined in the frontMatter.content.pageFolders setting, you can now set the content type(s) you want to use.

"frontMatter.content.pageFolders": [
  {
    "title": "blog",
    "path": "[[workspace]]/blog",
    "filePrefix": "yyyy-MM-dd",
    "contentTypes": ["blog"]
  },
  {
    "title": "docs",
    "path": "[[workspace]]/docs",
    "filePrefix": "",
    "contentTypes": ["doc", "page"]
  }
]

[michaeltlombardi]

@estruyf This works great! One thing I noticed while trying to define a content type mapping - there doesn't seem to be a way around requiring each page in the folder from setting the type metadata key to take advantage of non-default content type definitions.

This can be a problem for Hugo sites, where type carries its own semantics that may not be desirable for end users.

Thinking through this for a bit, I'm wondering if any of these ideas make sense:

1. If contentTypes is declared for a folder, use only the listed content types. This behavior could be opt-in, possibly with an exclusiveContentTypes key or similar? Or we could document that if you want the default content type applied, you need to specify it.

2. Use an additional metadata field that's always Front Matter specific. Instead of only checking type, it could check FrontMatter.type or similar. This would avoid munging a metadata key that has semantics specific to the static site generator.

   One advantage of pursuing this in general for page-specific Front Matter settings is we could schematize those settings and provide them as another entry in the side panel for pages, separate from the site-specific metadata, which might make them more discoverable and avoid requiring users to define those entries for themselves. Because FM is aware of all of the content types/etc available to it, those items could always present up-to-date options for the user.

[estruyf]

@michaeltlombardi, thanks for the feedback. You might be right about the type mapping, but this is how the content types have worked for a while in FM. If we want to change this, it would be best to do it in another issue/implementation as it would not be related to this enhancement.

[michaeltlombardi]

I'll file an issue for that as well! Just wanted to be sure there wasn't a way to work around option 2 in this implementation, since it's doing specific mapping for content types.