I realized these two config items are dynamically updated on content changes. Others for frontmatter values I am not using probably too. If the use of this is to fill dropdowns and keep an index of content, wouldn't it be a better place for them to be either in their own files under .frontmatter/config/taxonomy or even within .frontmatter/content/taxonomyDb.json and categoryDb.json? Updating the config file on content changes feels counterintuitive for the concept of a CMS. Especially non-hierarchical taxonomies might get updated every single time new content is added.
```
"frontMatter.taxonomy.tags": ["lots", "of", "tags"],
"frontMatter.taxonomy.categories": ["some", "categories"]
```
I realized these two config items are dynamically updated on content changes. Others for frontmatter values I am not using probably too. If the use of this is to fill dropdowns and keep an index of content, wouldn't it be a better place for them to be either in their own files under `.frontmatter/config/taxonomy` or even within `.frontmatter/content/taxonomyDb.json` and `categoryDb.json`? Updating the _config_ file on _content_ changes feels counterintuitive for the concept of a CMS. Especially non-hierarchical taxonomies might get updated every single time new content is added.
<!-- github-sync-id:1651867779 -->
Are you reading my mind @davidsneighbour 😄. I was thinking about that last week, but I hadn't come up with a solution yet, but you just did.
I love the taxonomyDb.json idea. It makes sense now that I just moved the mediaDb.json to a database folder.
Are you reading my mind @davidsneighbour 😄. I was thinking about that last week, but I hadn't come up with a solution yet, but you just did.
I love the `taxonomyDb.json` idea. It makes sense now that I just moved the `mediaDb.json` to a `database` folder.
<!-- github-comment-id:1495476797 -->
The tags and categories are now moved to their own taxonomyDb.json file. When you open a project, it will check if tags or categories are present in the DB. If not, it will update it with the one from your settings.
The tags and categories are now moved to their own `taxonomyDb.json` file. When you open a project, it will check if tags or categories are present in the DB. If not, it will update it with the one from your settings.

<!-- github-comment-id:1508559840 -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
I realized these two config items are dynamically updated on content changes. Others for frontmatter values I am not using probably too. If the use of this is to fill dropdowns and keep an index of content, wouldn't it be a better place for them to be either in their own files under
.frontmatter/config/taxonomyor even within.frontmatter/content/taxonomyDb.jsonandcategoryDb.json? Updating the config file on content changes feels counterintuitive for the concept of a CMS. Especially non-hierarchical taxonomies might get updated every single time new content is added.Are you reading my mind @davidsneighbour 😄. I was thinking about that last week, but I hadn't come up with a solution yet, but you just did.
I love the
taxonomyDb.jsonidea. It makes sense now that I just moved themediaDb.jsonto adatabasefolder.The tags and categories are now moved to their own
taxonomyDb.jsonfile. When you open a project, it will check if tags or categories are present in the DB. If not, it will update it with the one from your settings.