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

Issue: Uppercase/lowercase of content filenames. #212

New Issue
Closed
opened 2026-10-05 02:33:49 +02:00 by adam · 11 comments
adam commented 2026-10-05 02:33:49 +02:00
Owner
Copy link
Copy source

Describe the bug (Part 1)

Maybe more a feature request than a bug?

  • Open dashboard.
  • Create new content file via button Create content.
  • Enter a title FormControlGroup.
  • The created file is: formcontrolgroup.md (lowercase).
  • Because we use camel-case naming in some HUGO projects for delibarate reasons (before-rendering processing):
    • Close editing view of file formcontrolgroup.md.
    • Close dashboard. (Because I couldn't find a refresh button or so and thought it could be the trick).
    • Rename file in VSCode explorer to formControlGroup.md (camel-case).
  • Open FM dashboard and click entry with title FormControlGroup for editing.
  • Save file.
  • The file is opened and saved as formcontrolgroup.md (lowercase).

Expected behavior (Part 1)
The file is opened and saved as formControlGroup.md (camel-case).

Describe the bug (Part 2)
I don't know if it's related.

  • Close all FM views. Open VSCode explorer.
  • Open the file formControlGroup.md (camel-case) by double-click.
  • Click FM-Button in left sidebar.
  • See the three loading dots for several minutes. Even after 1/2h nothing has happened.
  • (Addendum: Opening the FM dashboard in parallel seems to speed up the process.)

Expected behavior (Part 2)

  • FM edit panel opens for the opened file formControlGroup.md (camel-case).

Desktop (please complete the following information):

  • OS: Win10
  • Current VScode version.
  • Because we thought the reason for endless waiting could be "Git talks by VSCode" we've disabled it but no change.

Additional context
We have to close and reopen VSCode before FM accepts the camel-case file, but then we have to wait before FM has scanned all files in dashboard which goes really slow for just 15 files in just one configured frontMatter.content.pageFolders. Just for the record: It's not only FM that is annoying slow immediately after VSCode initialisation.

Maybe a refresh button or something like that in dashboard would be nice.

Or highest happiness: Possibility to save or rename files camel-cased so that FM is aware of it without the need to rescan everything.

Thank you!

**Describe the bug (Part 1)** Maybe more a feature request than a bug? - Open dashboard. - Create new content file via button `Create content`. - Enter a title `FormControlGroup`. - The created file is: `formcontrolgroup.md` (lowercase). - Because we use camel-case naming in some HUGO projects for delibarate reasons (before-rendering processing): - - Close editing view of file `formcontrolgroup.md`. - - Close dashboard. (Because I couldn't find a refresh button or so and thought it could be the trick). - - Rename file in VSCode explorer to `formControlGroup.md` (camel-case). - Open FM dashboard and click entry with title `FormControlGroup` for editing. - Save file. - The file is opened and saved as `formcontrolgroup.md` (lowercase). **Expected behavior (Part 1)** The file is opened and saved as `formControlGroup.md` (camel-case). **Describe the bug (Part 2)** I don't know if it's related. - Close all FM views. Open VSCode explorer. - Open the file `formControlGroup.md` (camel-case) by double-click. - Click `FM`-Button in left sidebar. - See the three loading dots for several minutes. Even after 1/2h nothing has happened. - (Addendum: Opening the FM dashboard in parallel seems to speed up the process.) **Expected behavior (Part 2)** - `FM` edit panel opens for the opened file `formControlGroup.md` (camel-case). **Desktop (please complete the following information):** - OS: Win10 - Current VScode version. - Because we thought the reason for endless waiting could be "Git talks by VSCode" we've disabled it but no change. **Additional context** We have to close and reopen VSCode before FM accepts the camel-case file, but then we have to wait before FM has scanned all files in dashboard which goes really slow for just 15 files in just one configured `frontMatter.content.pageFolders`. Just for the record: It's not only FM that is annoying slow immediately after VSCode initialisation. Maybe a refresh button or something like that in dashboard would be nice. Or highest happiness: Possibility to save or rename files camel-cased so that FM is aware of it without the need to rescan everything. Thank you! <!-- github-sync-id:1149289715 -->
adam closed this issue 2026-10-05 02:33:50 +02:00
adam commented 2026-10-05 02:33:50 +02:00
Author
Owner
Copy link
Copy source

@ReLater thanks for opening the issue. I will handle part 1 and part 2 (https://github.com/estruyf/vscode-front-matter/issues/269) in two separate issues, as they should not have any effect on each other. There is no functionality to exclude certain files.

@ReLater thanks for opening the issue. I will handle part 1 and part 2 (https://github.com/estruyf/vscode-front-matter/issues/269) in two separate issues, as they should not have any effect on each other. There is no functionality to exclude certain files. <!-- github-comment-id:1049980311 -->
adam commented 2026-10-05 02:33:51 +02:00
Author
Owner
Copy link
Copy source

About the first part, there is indeed some sanitization going on when creating the file which eventually leads to this kind of lowercased output. It is by design. We can create a new setting to preserve the casing for your filename.

That said, there seems to be indeed an issue with the data that VS Code provides to the panel/dashboard. There is no refresh button (at some point there was one), as the data will automatically be updated when a page in your content folders got created/updated/deleted. Here it seems that we get still the old name back, which eventually leads to the panel not being able to load your data.

About the first part, there is indeed some sanitization going on when creating the file which eventually leads to this kind of lowercased output. It is by design. We can create a new setting to preserve the casing for your filename. That said, there seems to be indeed an issue with the data that VS Code provides to the panel/dashboard. There is no refresh button (at some point there was one), as the data will automatically be updated when a page in your content folders got created/updated/deleted. Here it seems that we get still the old name back, which eventually leads to the panel not being able to load your data. <!-- github-comment-id:1049989216 -->
adam commented 2026-10-05 02:33:52 +02:00
Author
Owner
Copy link
Copy source

Thanks, @ReLater with the help of your detailed guide, I was able to reproduce the panel-loading issue. Unexpectedly, part 1 and part 2 were somehow related. 😁

One issue I saw coming from VS Code itself is that it has the name cached, so if you rename the file, it keeps using the old casing. To show you, I've added the filename to the dashboard, where it gets correctly reflected after a change.

Screenshot 2022-02-24 at 16 48 35

What I haven't been able to reproduce is that the filename gets changed again to the old casing on save. If this still happens, we might need to open a bug in the VS Code GitHub repository, as the extension only writes the initial file, but save actions are performed by VS Code itself.

About the filename, I will continue to develop a setting in which you can specify if you want to preserve the casing of your title.

Thanks, @ReLater with the help of your detailed guide, I was able to reproduce the panel-loading issue. Unexpectedly, part 1 and part 2 were somehow related. 😁 One issue I saw coming from VS Code itself is that it has the name cached, so if you rename the file, it keeps using the old casing. To show you, I've added the filename to the dashboard, where it gets correctly reflected after a change. <img width="754" alt="Screenshot 2022-02-24 at 16 48 35" src="https://user-images.githubusercontent.com/2900833/155563202-541e8b6a-4889-4725-a458-fd01ef8e17cb.png"> What I haven't been able to reproduce is that the filename gets changed again to the old casing on save. If this still happens, we might need to open a bug in the VS Code GitHub repository, as the extension only writes the initial file, but save actions are performed by VS Code itself. About the filename, I will continue to develop a setting in which you can specify if you want to preserve the casing of your title. <!-- github-comment-id:1050039113 -->
adam commented 2026-10-05 02:33:53 +02:00
Author
Owner
Copy link
Copy source

A new setting frontMatter.file.preserveCasing is available to do exactly what it says. It preserves the casing on file creation based on the title you enter during the creation process.

A new setting `frontMatter.file.preserveCasing` is available to do exactly what it says. It preserves the casing on file creation based on the title you enter during the creation process. <!-- github-comment-id:1050067178 -->
adam commented 2026-10-05 02:33:53 +02:00
Author
Owner
Copy link
Copy source

Thank you for your investigations!

Only as a supplement. Maybe nice to know for some:

... but then we have to wait before FM has scanned all files in dashboard which goes really slow for just 15 files in just one configured frontMatter.content.pageFolders.

We have a multi-multi-multiple folder workspace. And in one of these folders /git-things/, that contains the frontmatter configuration files, are also a lot of GitHub projects in subfolders. One is the Hugo project.

When I create a new workspace with just one folder with the Hugo project then frontmatter file scanning isn't an issue anymore.

Thank you for your investigations! Only as a supplement. Maybe nice to know for some: > ... but then we have to wait before FM has scanned all files in dashboard which goes really slow for just 15 files in just one configured frontMatter.content.pageFolders. We have a multi-multi-multiple folder workspace. And in one of these folders `/git-things/`, that contains the frontmatter configuration files, are also a lot of GitHub projects in subfolders. One is the Hugo project. When I create a new workspace with just one folder with the Hugo project then frontmatter file scanning isn't an issue anymore. <!-- github-comment-id:1054424010 -->
adam commented 2026-10-05 02:33:54 +02:00
Author
Owner
Copy link
Copy source

@ReLater have you checked this: https://frontmatter.codes/docs/getting-started#workspaces-with-multiple-folders

Depending on the term "workspace", it is best to create the frontmatter.json file in the folder of the site. Otherwise, it might indeed slow things down, as it tries to look/guess where your site content is located.

@ReLater have you checked this: https://frontmatter.codes/docs/getting-started#workspaces-with-multiple-folders Depending on the term "workspace", it is best to create the `frontmatter.json` file in the folder of the site. Otherwise, it might indeed slow things down, as it tries to look/guess where your site content is located. <!-- github-comment-id:1054428773 -->
adam commented 2026-10-05 02:33:55 +02:00
Author
Owner
Copy link
Copy source

If you would put the frontmatter.json file at the root, it would still only use the provided paths in the frontMatter.content.pageFolders setting.

If you would put the `frontmatter.json` file at the root, it would still only use the provided paths in the `frontMatter.content.pageFolders` setting. <!-- github-comment-id:1054432829 -->
adam commented 2026-10-05 02:33:55 +02:00
Author
Owner
Copy link
Copy source

Thanks! Yes, I've read the docs several times ;-)

After installing frontmatter you are asked which VSCode-workspace folder you want to use. The dropdown just displays first level folders of the multiple-wokspace. Therefore we selected git-things (is it the one you mean by "root"?). Initialising by click puts the files in that folder.

Thanks! Yes, I've read the docs several times ;-) After installing frontmatter you are asked which VSCode-workspace folder you want to use. The dropdown just displays first level folders of the multiple-wokspace. Therefore we selected `git-things` (is it the one you mean by "root"?). Initialising by click puts the files in that folder. <!-- github-comment-id:1054446283 -->
adam commented 2026-10-05 02:33:56 +02:00
Author
Owner
Copy link
Copy source

Thanks @ReLater that is great to hear 🤓. If you have feedback on the structure, let me know, today I made an issue to come up with a new and improved structure to simplify things: https://github.com/FrontMatter/web-documentation-nextjs/issues/5

If you have recommendations, feel free to add these.

Thanks @ReLater that is great to hear 🤓. If you have feedback on the structure, let me know, today I made an issue to come up with a new and improved structure to simplify things: https://github.com/FrontMatter/web-documentation-nextjs/issues/5 If you have recommendations, feel free to add these. <!-- github-comment-id:1054448516 -->
adam commented 2026-10-05 02:33:57 +02:00
Author
Owner
Copy link
Copy source

After installing frontmatter you are asked which VSCode-workspace folder you want to use. The dropdown just displays first level folders of the multiple-wokspace.

Ciorrect, as for VS Code a workspace is a couple of root folders that the extension retrieves.

> After installing frontmatter you are asked which VSCode-workspace folder you want to use. The dropdown just displays first level folders of the multiple-wokspace. Ciorrect, as for VS Code a workspace is a couple of root folders that the extension retrieves. <!-- github-comment-id:1054450279 -->
adam commented 2026-10-05 02:33:57 +02:00
Author
Owner
Copy link
Copy source

But then scanning is extremly slow in our environment. But it's no problem for me to use smaller VSCode-workspaces in the future to speed the thing up.

But then scanning is extremly slow in our environment. But it's no problem for me to use smaller VSCode-workspaces in the future to speed the thing up. <!-- github-comment-id:1054454225 -->
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#212