adam/vscode-front-matter
1
0 Fork 0
mirror of https://github.com/estruyf/vscode-front-matter.git synced 2026-11-03 09:02:19 +01:00
Code Issues 77 Packages Projects Releases Wiki Activity

Enhancement: Default filter configuration for the Contents dashboard #772

New Issue
Closed
opened 2026-10-05 03:04:44 +02:00 by adam · 2 comments
adam commented 2026-10-05 03:04:44 +02:00
Owner
Copy link
Copy source

First of all - Front Matter CMS has become an essential part of my content workflow. The dashboard, the content management, the snippet support - it is a genuinely well-designed extension that makes working with static site generators a pleasure. Thank you for building and maintaining it.

Have you considered adding support for configuring the default view state of the Contents dashboard - filters, sorting, and grouping - in a single setting?

Currently, all filters reset to their unfiltered state, sorting defaults to whatever frontMatter.content.defaultSorting specifies (or the built-in default), and grouping resets to "none" every time the dashboard opens. For repositories where a specific combination represents the most common working context, it would be helpful to configure defaults so the dashboard opens ready to go.

Proposed solution

A new frontMatter.content.defaults setting that defines the dashboard's opening state in one place:

{
  "frontMatter.content.defaults": {
    "filters": {
      "contentFolders": "posts",
      "tags": "Microsoft Intune"
    },
    "sorting": "LastModifiedDesc",
    "grouping": "Year"
  }
}
  • filters - An object where each key matches a built-in filter identifier (contentFolders, tags, categories) or a custom filter's name property, and the value is the default selection
  • sorting - A string matching a built-in sorting option (LastModifiedAsc, LastModifiedDesc, FileNameAsc, FileNameDesc) or the ID of a custom sorting option defined in frontMatter.content.sorting
  • grouping - A string matching the title of a built-in or custom grouping option defined in frontMatter.content.grouping

When a property is set, the dashboard would open with that value pre-selected. When a property is omitted, the current default behavior would be preserved. When the entire setting is omitted, nothing changes.

Use case

My repository has two content folders - pages (a handful of static pages) and posts (dozens of blog posts). I work almost exclusively with posts from the dashboard, typically sorted by date and grouped by year. Manually selecting the same filter, sort, and group options every time I open the dashboard is a small thing, but it adds up over time.

A single defaults setting would make the dashboard open in the right context immediately - and because it covers filters, sorting, and grouping together, it gives users full control over their default working view.

Alternatives considered

  • Adding a default property inline on each filter, sorting, and grouping entry - this keeps defaults close to configuration but scatters them across multiple settings
  • A dedicated frontMatter.content.defaultFolder setting - this would solve the immediate need but only covers one filter type
  • Persisting the last selected view between sessions - this could also work but is less predictable than an explicit configuration

Thank you for considering this - and for all the work you put into Front Matter CMS. It is appreciated.

First of all - Front Matter CMS has become an essential part of my content workflow. The dashboard, the content management, the snippet support - it is a genuinely well-designed extension that makes working with static site generators a pleasure. Thank you for building and maintaining it. Have you considered adding support for configuring the default view state of the Contents dashboard - filters, sorting, and grouping - in a single setting? Currently, all filters reset to their unfiltered state, sorting defaults to whatever `frontMatter.content.defaultSorting` specifies (or the built-in default), and grouping resets to "none" every time the dashboard opens. For repositories where a specific combination represents the most common working context, it would be helpful to configure defaults so the dashboard opens ready to go. **Proposed solution** A new `frontMatter.content.defaults` setting that defines the dashboard's opening state in one place: ```yaml { "frontMatter.content.defaults": { "filters": { "contentFolders": "posts", "tags": "Microsoft Intune" }, "sorting": "LastModifiedDesc", "grouping": "Year" } } ``` - `filters` - An object where each key matches a built-in filter identifier (`contentFolders`, `tags`, `categories`) or a custom filter's `name` property, and the value is the default selection - `sorting` - A string matching a built-in sorting option (`LastModifiedAsc`, `LastModifiedDesc`, `FileNameAsc`, `FileNameDesc`) or the ID of a custom sorting option defined in `frontMatter.content.sorting` - `grouping` - A string matching the `title` of a built-in or custom grouping option defined in `frontMatter.content.grouping` When a property is set, the dashboard would open with that value pre-selected. When a property is omitted, the current default behavior would be preserved. When the entire setting is omitted, nothing changes. **Use case** My repository has two content folders - pages (a handful of static pages) and posts (dozens of blog posts). I work almost exclusively with posts from the dashboard, typically sorted by date and grouped by year. Manually selecting the same filter, sort, and group options every time I open the dashboard is a small thing, but it adds up over time. A single defaults setting would make the dashboard open in the right context immediately - and because it covers filters, sorting, and grouping together, it gives users full control over their default working view. **Alternatives considered** - Adding a `default` property inline on each filter, sorting, and grouping entry - this keeps defaults close to configuration but scatters them across multiple settings - A dedicated `frontMatter.content.defaultFolder` setting - this would solve the immediate need but only covers one filter type - Persisting the last selected view between sessions - this could also work but is less predictable than an explicit configuration Thank you for considering this - and for all the work you put into Front Matter CMS. It is appreciated. <!-- github-sync-id:4587956044 -->
adam closed this issue 2026-10-05 03:04:44 +02:00
adam commented 2026-10-05 03:04:45 +02:00
Author
Owner
Copy link
Copy source

Thanks for the kind words and the well-thought-out proposal, @dotjesper!

The idea makes a lot of sense. Rather than frontMatter.content.defaults, I think frontMatter.dashboard.content.defaults would be a better fit, it's consistent with the existing frontMatter.dashboard.content.* settings namespace (pagination, card fields, etc.) and makes it clear this is specifically about the dashboard's opening state.

The shape would look like you proposed:

{
  "frontMatter.dashboard.content.defaults": {
    "filters": {
      "contentFolders": "posts",
      "tags": "Microsoft Intune"
    },
    "sorting": "LastModifiedDesc",
    "grouping": "Year"
  }
}

This would sit alongside frontMatter.dashboard.content.pagination, frontMatter.dashboard.content.cardTags, etc., keeping all dashboard content view configuration in one place.

I'll look into adding this. Thanks again for the suggestion!

Thanks for the kind words and the well-thought-out proposal, @dotjesper! The idea makes a lot of sense. Rather than `frontMatter.content.defaults`, I think `frontMatter.dashboard.content.defaults` would be a better fit, it's consistent with the existing `frontMatter.dashboard.content.*` settings namespace (pagination, card fields, etc.) and makes it clear this is specifically about the dashboard's opening state. The shape would look like you proposed: ```json { "frontMatter.dashboard.content.defaults": { "filters": { "contentFolders": "posts", "tags": "Microsoft Intune" }, "sorting": "LastModifiedDesc", "grouping": "Year" } } ``` This would sit alongside `frontMatter.dashboard.content.pagination`, `frontMatter.dashboard.content.cardTags`, etc., keeping all dashboard content view configuration in one place. I'll look into adding this. Thanks again for the suggestion! <!-- github-comment-id:4621642558 -->
adam commented 2026-10-05 03:04:46 +02:00
Author
Owner
Copy link
Copy source

Deploying to the beta version of the extension. It should work like you mentioned.

Deploying to the beta version of the extension. It should work like you mentioned. <!-- github-comment-id:4622513646 -->
Sign in to join this conversation.
No Branch/Tag Specified
Labels
No items
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
adam (Adam Wojcieszonek)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: adam/vscode-front-matter#772