I’m currently in the process of building my personal website, which will contain a blog section. Within that blog section, I want to allow people to comment using Disqus, which is fairly easy to achieve with Zola.
The problem is that because of the way Disqus works, you only want it to be on the released site, not on local test builds. (I assume it is similar for things like Google Analytics, but I don’t really know.) For this reason, it’d be great, if one could tell the zola build command whether or not it is building the release or the development version.
This could be implemented similarly to the base_url as an option in the config.toml with an optional --release flag to override the value from the file. The value could be a bool or a string. The former would be a fairly simple system while the later would allow users much more flexibility (perhaps a company internal and a public version). As default values, I’d suggest false or something like “test” or “debug”.
A notable workaround to this feature, that works with the current version is setting an environment variable and checking it with teras get_env() built-in function.
If you are open to a feature like this, I’d be willing to implement it myself. However, I currently don’t have the time to do so, I could start in about two months.
I also thought of that but forgot to mention it in the original post.
The problem you have using this approach is that then you have hardcoded the base_url in multiple positions. If you want to move the site to another base_url you have to update every single occurrence, so basically a violation of the dry principle.
Alternatively, you could store the release base_url in the extra section of the configuration, but you’d still have the value in two spots.
One other option I forgot to mention is to store the information on whether the build is a release in the configuration. However, this approach has another problem: if you want to build the site using CI, you’d have to manipulate the config before running Zola, which in my opinion is worse than using environment variables.
However, I think this is still worse than environment variables, because then you have to remember to update both files, which is a new source of possible errors.
It’s in zola --help because it’s a parameter of the program, not the subcommand (hence the importance of the position of the argument).
While this might work, it’s way easier for me to use environment variables. This approach would require me to add an extra build step, which is not really better than adding an environment variable. (And in my opinion, the solution with the environment variable is way more readable in the CI config.)
Hugo has a --environment option. in serve mode, it default to ‘development’ and in build mode, default to ‘production’. It would be convenient if zola has this feature.
