Give some love to terms listing

feature
1

I’m trying to see if improving taxonomy term listing (from pages) would get any traction here. Particularly the adding of a new Site/Page method. I know this subject has been discussed before, but the following approach may be better suited and avoid code breaking.

In short, it would involve a new method on both .Site and Page:

.Site.GetTerms "tags" > returns all the terms of the taxonomy “tags” as page objects.
.GetTerms "tags" > same as above but limited to the current page’s assigned terms.

Here’s why I think this feature is needed:

Currently there are two ways to list terms from outside the taxonomy landing page.
On the site level, retrieving all the terms:
.Site.Taxonomies.tags returns an array of terms from which you can only get two informations per term:

  • The term slug/id
  • The pages belonging to the term

On the page level:
One must use .Params.tags which will return a list of tags as added by the editor.

Both situation (site context and page context) leaves the coder in charge of building the proper permalink (and sometime name).

As per the doc:

<ul id="tags">
  {{ range .Params.tags }}
	<li><a href="{{ "/tags/" | relLangURL }}{{ . | urlize }}">{{ . }}</a> </li>
  {{ end }}
</ul>

On the site level, you need to get the tag slug from the $index.

If more information are needed from the term (dedicated Front Matter), coder must use .GetPage on each of them.

With a dedicated method like .GetTerms, listing terms on a page would be clearer and more error proof:

{{ with .GetTerms "tags" }}
   {{ range . }}
   	<li>
                       {{ with .Params.icon }}
   		{{ <i class="{{ . }}"></i>
                       {{ end }}
   		<a href="{{ .Permalink }}">{{ .Name }}</a>
   	</li>
   {{ end }}
{{ end }}

Adding a new method rather than changing something already in place avoids code breaking and limit the usage of the new feature to the people aware of it.

This is the thinking of me alone, so it this method and its one parameter may be flawed (or not needed by any one else but me). I’m merely trying to see if other people care join the conversation about the need for such a feature.

6 Likes
2

I would also like a way to have the .Permalink variable work in the context of taxonomies without further tweaking.

So +1 for your proposal.

3

If I understand correctly, this PR that fixes such “tags/” hard-coded examples in the doc should provide the updated examples to address your concern. (I hope to find time today to merge it.):

Here’s the terms.html template from my site that also prevents that “tags/” (and “categories/”) hard-coding.

4

That still hard-coded the “tags” term in the templates. May be the solution I posted using GetPage isn’t what you are looking for?

I might be the odd one out here. But I’m failing to see the value that the proposed GetTerms is bringing.

5

This doest not call one term but all of the terms of a taxonomy, here “tags”.

See it as .GetAllTermsFromTaxonomy "tag" maybe the plural tags is misleading here. So yes it’s hardcoded but for one taxonomy, which I don’t think is too much of a problem, considering you don’t call taxonomy terms this often in a page template. Then again, this could also be used in conjunction with .Site.Taxonomies. The keys being passed as .GetTerms params.

I can see your exemple on GitLab which falls in the following remark:

I wanted to avoid using .GetPage too many times on every pages. The GetTerms functions would have to be more efficient (build time wise) than multiple .GetPage if possible.

1 Like