Struggling to get taxonomy list/single pages to show

Support
1

I feel like I’ve followed the instructions outlined in the taxonomy pages of the content and template sections, but when I navigate to http://localhost/categories I see nothing, as well as in public/ after a build. I have no. idea. what I’m missing and would really appreciate some guidance.

In my config.toml I added:

taxonomies = [
  { name = "categories", feed = true }
]

and in content/blog/example/index.md I added

+++
[taxonomies]
categories = ["example"]
+++

Then in templates/categories/list.html as well as templates/categories/single.html I extended my base template and added some dummy content between my {% block content %}

… but still I see nothing. Is there something else that I need to do?

2

take a look to zola’s themes and examples of list and singe templates (like mine here ).

3

Hi Roman, thanks for the reply and the concise example. I was able to figure out the problem: my taxonomies key in config.toml was accidentally a field of another toml table. I thought that linebreaks were good enough to separate keys from one table, with the root document… but now I know that. Very frustrating yet simple to fix.

It would be a great feature to throw an exception during build if there are disallowed/unreachable config keys. Since you can’t use your own config keys unless they’re sort of ‘namespaces’ under [extra] anyway, I don’t see why this wouldn’t be a problem and can only be helpful.

In retrospect the TOML rule is obvious, now that I know it, but in case you don’t, Zola should warn you about unusable config keys.

4

The worst part of TOML by far…
I don’t think we can warn because people can have whatever structure they want. It might not be reachable in Zola but it might be used by something else.

5

It might not be reachable in Zola but it might be used by something else.

Yeah, that’s a good point. I guess once you get past any configuration issues like that, you don’t really run into them again, so it’s probably not worth adding any additional complexity to the app, like a doctor command that could help audit potential errors.

One thing I like about the app is simplicity, with the complexity put into the a good design of the commenting/templating system.