The goal of this change is to deduplicate all custom templates that are in use for taxonomy pages.
This commit defines the entrypoint for any taxonomy list page to be the 'layouts/taxonomy.html' template,
and removes all taxonomy-specific templates (e.g. 'layouts/publications/taxonomy.html'). Per-taxonomy
page customization are now handled via new partials and with front matter configuration via 'params'.
Any given taxonomy list page can now be customized to do the following:
- show all terms vs only terms that have a metadata-generated '_index.md' page (via '.Params.title')
- list items in a grid vs list items vertically
- include vs exclude filtering functionality (inclusion assumes the vertical list layout)
- specify which filter fields to use (e.g. 'kind', 'topic', 'year'), if filtering functionality is active
- specify which fields to include in the text search functionality, if filtering functionality is active
Customization happens in the '_index.md' page of any given taxonomy content directory.
For example 'content/publications/_index.md':
---
title: Publications
params:
list_variant: vertical # grid (default) | vertical (if filter == true, list_variant is set to vertical)
items: generated # generated (default) | all
filter: true # false (default) | true
filter_fields: # no default
- kind
- topic
- year
search_fields: # default: kind, topic, year, author, title
- kind
- topic
- year
- author
- title
---
And partials are then rendered based on this configuration.
Main configuration introduced with this commit:
- persons: grid view (default)
- objectives: grid view (default)
- projects: grid view (default)
- publications: filter view
- datasets: filter view
- instruments: filter view
The main repo README is updated with a description of this configuration and template pattern
TODO:
- add some partials for the parts that are displayed on a list item (e.g. the list of authors, the topics,
the icon-links, etc); and perhaps also configuration variables for their inclusion/exclusion
- Improved logic for selecting depictions; the current depiction registration workflow registers files
with names derived from the depiction kind, e.g. 'logo.png' or 'portrait.webp'. These are generally for
different purposes, and the logic might want to prefer a specific kind for a specific taxonomy, e.g.
'portrait' for 'persons', or 'logo' for 'instrument'.
- Update filtering-related code to make better use of hugo templating functionality; some aspects are still
hardcoded, e.g. 'data-*' for setting the list-item data values.
- Apply similar improvements to the 'term.html' template as done above for 'taxonomy.html'
Stephan Heunis
73ae3cace6