I have approximately 2,000 posts for a medium-traffic site that I’m considering migrating to Hugo. I name my posts according to the scheme: <id>-<slug>.<format>, e.g. 00391-example-post.markdown. This is so that:
My content is lexicographically sorted on the filesystem, so it’s easier to find a specific post.
The posts are ordered in the order they were written on the filesystem.
The slug is determined from the file name, so nothing needs to be updated in front-matter.
Hugo wants to pull the slug from the entire file name, whereas I want to supply my own slug-generation function to just pull it out directly. I’m assuming I can’t tell Hugo to use some external generator – I couldn’t find anything in the docs that seemed to indicate the availability of extensibility for this.
Is there a way to make this happen? Could I use data files, generate the slugs externally into a data file, and tell Hugo to look at the data files to infer the slug for a given post as if it were in the post’s frontmatter?
What would it take to get Hugo to associate content in a data file to (a) identify a piece of content in a datafile and (b) trump that content’s frontmatter? (I’d be willing to pay a feature bounty for this improvement if the maintainers think this feature is useful.)
I read your post about the “data files again” … if you are able to make a script that writes to data files, wouldn’t that script be able to write to front matter as well?
I want URLs of the form /<plural>/<slug>, where <slug> is extracted as I described in the original post.
wouldn’t that script be able to write to front matter as well
Sort of. That’s not desirable for two reasons:
Correctly parsing an individual YAML+markdown file and writing back to it is much more involved than writing to a new YAML file.
Touching 2,000 files is not ideal from a source-control perspective, when compared against generating one file which doesn’t need to live in source control.
I’m sorry if anything was unclear. Let me know how I can clarify.
It comes from the same place Hugo gets it now - the name of the content directory, unless I’m missing something.
There’s another reason to consider it: it means you can save metadata that’s different for different environments.
For example, you might generate one set of data for the staging version of your static site but another for production. Without this ability, everything has to go into your post front matter, which is awful from a version-control and clean-source-history perspective. You shouldn’t have to make a commit every time you want to switch environments.
This is a valuable addition for using Hugo on documentation sites for enterprises, which is one of the use cases I’m evaluating (though not for this site).
Unrelated question: is there a way to set the slug programmatically from inside a template? That would also do the trick, I think, because I could just define it in my data file and pull it in.
Right – I was asking asking whether something like setting the slug in a template or layout is possible (in the same way that one can set it in frontmatter).