Disable URL paths

Is it possible to somehow disable specific URL paths?

I think it would be useful in some scenarios. For example a site has a blog and there are authors. The directory structure on the disk looks like this: content/author/[author name].md Now, each author has an own page (/author/[author name]) but it doesn’t really make sense to serve something on the /author page, however Hugo really want to do that. The /authors page could be also used as a listing page of authors, but lets assume it doesn’t fit into the picture.

A quick fix would be to set that as an alias for another page.

A small suggestion for that specific case, why not use that as an opportunity to show a list of authors and increase the cross linking of the site?

Well, I think an /authors or /our-team or something similar page could be useful for company’s or in those cases where there is a “dedicated team” or group of people behind the site. But think about a site like Medium where no one cares about the list of authors. The authors are interesting as an individual, but why would you list them? It wouldn’t really make sense. But this is more likely content organization related “problem” and not something which is Hugo related. I just wanted to show an example.

1 Like

Wondering this as well. Each type ends up with my index page since I had to use _default/list.html for that, creating duplicate content. Seems like if Hugo supported a templated home page it would be fine.

Not seeing any sign of disabling in the repo / docs.

In a case like this I would suggest to store the author-data in the /data/-Folder and access them by .Site.Data (Documentation)

There you can use JSON, TOML or YAML, whatever you prefer.

A quick example to illustrate how to organize and access the data:

content/my-article.md

+++
date = "2017-03-07T01:57:46.448Z"
title = "My awesome Article"

author = "johndoe"
+++

The data-folder could look like this:

|-- data
|  |-- authors
|  |  |--johndoe.json
|  |  |--janedoe.json

data/authors/johndoe.json

{
  "name" : "John Doe",
  "bio" : "Lorem ipsum dolor sit amet.",
  "website" : "https://example.com",
  "twitter" : "@jdoe"
}

in the template you can access the data referenced by the front matter’s “author”-Param like this:

< section-name >/single.html

<h1>{{ .Title }}</h1>
{{ .Content }}
<hr>
{{ $author := index .Site.Data.authors .Params.author }}
{{ with $author }}
  <h4>{{ .name }}</h4>
  <p>{{ .bio }}</p>
  <a href="{{ .website }}">Website</a>
  <a href="https://twitter.com/{{ .twitter }}">Twitter: {{ .twitter }}<a>
{{ end }}

Hope this was illustrative and helpful how you can store and access data from the Data-Folder without generating uneccessary pages :slightly_smiling:

Medium uses the user’s name at the root–or sometimes with the @ and a Twitter handle that then resolves to the URL structure of mediumsite.tld/:author/:title OR mediumsite.tld/:title.

You can do this in Hugo as well given your example directory structure of:

content/authors/*<AUTHOR-FILE>.md

In your config, set the following:

[permalinks]
    authors = "/:filename/"

Of course, I think this will still create a list page since I haven’t tried anything like this since v16.

Or if you only have a few pages where you don’t want to create a list and you want them at the root (the classic example being an /about page), you can just create individual .md at the root of the content directory.

What I just wrote above should take care of that.

If you’re talking about keeping the URL structure of /author/author-name but not having /author actually do anything, I’m politely asking you to not break the mental model of the web :smile:

home is a specific kind with a specific template (i.e., layouts/index.html) that acts like a list but has a few more benefits (e.g. .Data.Pages points to all pages in the entire Hugo site, whereas .Data.Pages only points to pages within a specific section when used in, for example, layouts/_default/section.html or layouts/section/posts.html, etc). But I think you’re asking for something else, @tjholowaychuk Would you mind expanding on that?

I wouldn’t recommend this for anything content related, especially since you’re detracting from the benefits of simple syntax for content (i.e., markdown).

Besides, I always felt like “data” was a bit of a misnomer for Hugo, Jekyll, etc, since really,everything we’re talking about here is just serialized data in my mind; i.e.—

This…

# my-post.md
---
title: My Post
date: 2017-03-04
description: This is a description of my post.
---

Here is some content for my post.

…is really no different than this:

#my-post.yml
---
title: My Post
date: 2017-03-04
description: This is a description of my post.
content: Here is some content for my post.
---

I think the real issue here is Hugo’s automatic generation of pages, which makes perfect sense in the model of “sane defaults,” which I think is a good model to abide by to keep things DRY. That said, an option really isn’t a “default” if it’s the only option; some might argue it’s not even an “option.”

FWIW, this was tangentially touched upon here, although I ask you not to comment on anything but the specific topic delimited in the pull request title since I already got way too ranty in my comments as it is :smile: :

Oh I thought layouts/index.html had to strictly be static HTML, no partials or “base” etc. At least that’s what I had read, I can’t remember now if I tried it or not. I’ll give it another go.

No worries. Maybe this will give you an idea of what I would do for the most basic Hugo site:

layouts/_default/baseof.html

<!DOCTYPE html>
<html lang="en">
<head>
	{{ partial "head.html" . }}
</head>
<body>
	{{ partial "site-header.html" . }}
	{{ block "main" . }}
	
	{{ end }}
	{{ partial "site-footer.html" . }}
	{{ partial "site-scripts.html" . }}
</body>
</html>

layouts/index.html

{{ define "main" }}
<main class="main">
	<header>
		<!-- Whatever -->
	</header>
	{{ range .Site.Pages }}
	<section>
		<header>
			<h1>{{.Title}}</h1>
			<p>{{.Description}}</p>
		</header>
		{{.Summary}}
	</section>
	{{ end }}
</main>
{{ end }}