Hugo frontmatter aliases do not get created for custom content types

#1

So, I’m essentially using Hugo as a JSON API for my content.

Hugo creates a folder (with an index.json) for each page that I create in my /content folder. However, I’ve noticed it won’t create any additional folders for any additional aliases that I define within the front matter.

How would I essentially go about doing this, so Hugo will generate those additional folders, since that’s really the only solution that would work in my case?

Any help would be greatly appreciated :slight_smile:

#2

Please see Requesting Help linked below and share your code so that we can help you troubleshoot this

#3

@zwbetz Thank you and apologises for not understanding the rules!

Source code: https://github.com/dottjt/nfd-api

I expected that when generating the files, it would create new JSON files for the alias slugs defined within the font-matter of content located within content/practices. However, it only creates files associated with the slug of the post.

My understanding is that it will generate separate html files for those alias slugs, however it does not seem to be doing the same for Json generated content.

I’m not 100% sure if this is relevant, but this is what I have defined in my config.toml for custom data types:

[outputs]
  home = ["HTML", "JSON"]
  section = ["HTML", "JSON"]
  page = ["HTML", "JSON"]
#4

Hi,

So according to How Hugo Aliases Work,

When aliases are specified, Hugo creates a directory to match the alias entry. Inside the directory, Hugo creates an .html file specifying the canonical URL for the page and the new redirect target.

So, the way I understand that is that it is primarily meant to serve as redirect, not as a mirror page. Perhaps that is why? I am not a Hugo dev though.

#5

Actually, I think I know what’s happening.

So what’s happening is that all the aliases are generated being at the root level. So for example in public/alias-slug as opposed to in the section level i.e. public/practices/alias-slug.

Furthermore, it’s not generating JSON for aliases.

I wonder how I could generate these aliases at a section level, as well as generate JSON for those aliases.

#6

When defining your alias, you must specify the full path. For example in file

content\practices\DONE--AOA--P--dissolve-your-visual-field.md

You currently have the alias defined as

aliases: [
  "dissolve-it-down"
]

But it needs to be

aliases: [
  "/practices/dissolve-it-down/"
]

Why should it? The alias is an HTTP redirect. So once the user is redirected to the new page, they will get the new JSON there.

I see what you’re saying now. Yeah

/practices/dissolve-it-down/index.json

Does not redirect to

/practices/dissolve-your-visual-field/index.json

Am not sure how to make this happen.


Well, you could do this…

aliases: [
  "/practices/dissolve-it-down/",
  "/practices/dissolve-it-down/index.json"
]

But then that redirects the JSON page to your new HTML page, not what you want


I see you’re using Netlify. You could use Netlify Redirects for your json

#7

The alias system in Hugo was not created for your use case; it is based on the web pattern of loading a web page with a redirect timer. That pattern isn’t great for handling redirects in an API.

Obviously when you look at how Netlify redirects work, you might be able to get creative, but if you are doing redirects, that means you are feeding a web server a list of URLs mapped to other URLs. What I mean is: how would you do this without Hugo? Work back from there.

At least this is how I think it works. I don’t know that much JSON stuff, so maybe I’m off on how redirecting API endpoints is…

#8

This is excellent and exactly what I needed. Thank you so much.

Actually, that is what I want! (I think, I’ll have to try it out)

Essentially I’ll have to have a redirect from “/practices/dissolve-it-down/index.json” to the proper index.json in Netlify, but I think that’s the right answer here :slight_smile:

Thank you so much for your help! It’s not perfect, but obviously I’m using Hugo outside of it’s use-case.

Definitely I’m liking the idea more and more of using static site generators as APIs. It’s a lot easier than setting up a database etc.