Issue: Uppercase/lowercase of content filenames.

[ReLater]

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!

[estruyf]

@ReLater thanks for opening the issue. I will handle part 1 and part 2 (#269) in two separate issues, as they should not have any effect on each other. There is no functionality to exclude certain files.

[estruyf]

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.

[estruyf]

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.

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.

[estruyf]

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.

[ReLater]

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.

[estruyf]

@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.

[estruyf]

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.

[ReLater]

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.

[estruyf]

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: FrontMatter/web-documentation-nextjs#5

If you have recommendations, feel free to add these.

[estruyf]

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.

[ReLater]

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.