You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I know this is far out because every SSG has a different system of adding settings, but in the end, those settings are in TOML, YAML, JSON, or INI-kind files. It would be nice to have some form of configurable option to load and edit items in the aforementioned formats and save them back.
This is a very un-thought-out idea and probably not easy to implement. But let's look for instance (selfishly) at GoHugo: We have a config directory with a _default subdirectory (or other "environment" subdirectories that are merged on top of _default when GoHugo runs). Then we have files like hugo.toml and module.toml in that _default directory. Those values are either key-value pairs or arrays and tables.
This principle could (in GoHugo) then later on even be adapted for the i18n folder that translates themes and modules.
I know this is a huge feature, so delete if it's a general "no thanks", or think about it :)
PS: there might be a general usefulness to have a TOML/YAML/JSON-to-form mechanism. Abstract without having to work on settings or translations.
PPS: Configuration option definitions could work based on a schemata file like the frontmatter schematas.
The text was updated successfully, but these errors were encountered:
I know this is far out because every SSG has a different system of adding settings, but in the end, those settings are in TOML, YAML, JSON, or INI-kind files. It would be nice to have some form of configurable option to load and edit items in the aforementioned formats and save them back.
This is a very un-thought-out idea and probably not easy to implement. But let's look for instance (selfishly) at GoHugo: We have a
config
directory with a_default
subdirectory (or other "environment" subdirectories that are merged on top of_default
when GoHugo runs). Then we have files likehugo.toml
andmodule.toml
in that_default
directory. Those values are either key-value pairs or arrays and tables.This principle could (in GoHugo) then later on even be adapted for the
i18n
folder that translates themes and modules.I know this is a huge feature, so delete if it's a general "no thanks", or think about it :)
PS: there might be a general usefulness to have a TOML/YAML/JSON-to-form mechanism. Abstract without having to work on settings or translations.
PPS: Configuration option definitions could work based on a schemata file like the frontmatter schematas.
The text was updated successfully, but these errors were encountered: