Hugo: Add 'unlisted' option for content?

[mcdee]

I have content that I wish to add to my website but not be linked from my articles/categories/tags lists (but can be accessed by direct link). It seems to me the best way of doing this would be to add an 'unlisted' item to the front matter: f this were present then the content would still be processed and generated, but would not show up in any of the aggregate and iterator items such as content count, list of content, _etc._

Does this sound like something that might be useful to add? If so, some pointers to the pieces you think I need to change would be appreciated and I can see if I can put together a PR that implements this functionality.

[bep]

We have headless which is, I suspect, similar but not what you want.

I'll put the proposal label on it. If enough people somehow shows an interest and can tell about some real use cases for this, then we can consider implementing it.

[bep]

/cc @regisphilibert @budparr etc.

[Brixy]

If enough people somehow shows an interest and can tell about some real use cases for this, then we can consider implementing it.

Yepp, very interested ;-)

I do this manually, but it can be tricky as you have to respect quite a few things:

• robots meta tags (noindex, follow)
• robots.txt
• sitemaps (for each language)
• feeds
• all section lists
• archives
• landing page
• taxonomy
• …

Moreover, there were quite a few related questions in the forums.

An unlisted: true param would be just great!

[bep]

I do this manually, but it can be tricky as you have to respect quite a few things:

That is true, but what do you use it for? Why do you need pages to be unlisted?

[Brixy]

That is true, but what do you use it for? Why do you need pages to be unlisted?

Yes, I read your question. Yet, my use case is probably not representative:

I frequently publish internal stuff on my pages—for clients, family … As Hugo is so extremely flexible this is a lot more convenient and quicker than choosing various cloud sharing services, and clients have access to all the public stuff, as well.

Of course this is not sensitive data. For sensitive data I would probably use another e.g. .htpasswd protected Hugo site.

Thank you!

[mcdee]

@bep according to the docs headless doesn't create the HTML so that wouldn't work.

To clarify my particular use case: I have an article that is in first draft and on which I require feedback from select individuals. I would like to be able to publish this article on my website so they can access it directly, but it not show up in the various lists (front page, category, RSS, and the rest). Once the review is complete I can remove the unlisted status and it will show up in the list as usual, allowing it to be found by users.

[regisphilibert]

@mcdee. Seems like all you need a special environment to deploy and give the URL to your clients. Have hugo -D run on this one, and your draft will be published. For your usecase, even though Hugo won't "list" the items, they'll be still indexed by google, shareable via social services etc... So that unlist reserved key might not fully solve your problem.

I for myself never had a use case matching your requirement. I usually won't publish something in production if it's private.

[thewebmastercom]

I also use unlisted pages, but do it by keeping them in draft so I can view them in local only. My use case is an SEO section where I list each page, and run various tests (date last modified, content length, title length, title same as h1, and many more other tests). I also have various data studio charts embedded bringing in data from the search console and Google analytics.

I also have a styleguide so I can check visually any changes, see styles in one place.

I guess if I had unlisted functionality, I could publish it and password protect it, but to be honest the local dev environment is fine for me.

[Brixy]

I for myself never had a use case matching your requirement. I usually won't publish something in production if it's private.

That is a point, of course, @regisphilibert

Just one last pro argument from my point of view: I have seen quite a lot of templates using something like sitemap_exclude or hidden. So I guess there seems to be a demand.

[regisphilibert]

So I guess there seems to be a demand.

I'm sure there is. There is also a lot of demands for publishing steps each validated by a different person, until, the last step is ✅ and article goes live.

Again, if a maintainer wants to take it on I won't oppose it, but I would think, in the future, some one else will need another built-in way of "filtering" pages not addressed here and we'll wonder again if we should add yet another reserved parameter.

Here's what I think we should all do with this kind of predicament:

With returning partials, anywhere on your site you can call the same partial in charge of filtering your pages. In your case:

{{/* partials/func/FilterPages.html */}}
{{ $pages := where . ".Params.unlisted" nill }}
{{ return $pages }}

{{/* list.html */}}
{{ range partial "func/FilterPages" .Pages }}
  [ ... ]
{{ end }}

{{/* partial/recent-posts.html */}}
<h3>Recent Posts</h3>
{{ $posts := where (partial "func/FilterPages" site.RegularPages) "Type" "posts" }}
{{ range first 5 $posts }}
  [ ... ]
{{ end }}

Then as your filtering requirements evolves, just edit your func/FilterPages partial, and you're good.

[karamme]

I'm sure there is. There is also a lot of demands for publishing steps each validated by a different person, until, the last step is ✅ and article goes live.

I totally agree, however then it needs some kind of CMS functionality to manage the reviewers.

As a workaround, we use hugo to publish the development environment including drafts and publish it to a separate netlify-url. I also use the method described by matteobrusa to do some password protection (of course you have to adjust the robots.txt and html-meta-section to not be indexed by google etc). This way we get a secret online version of our website including drafts.

The review part of the articles is done in an issue for each article.

[bep]

@regisphilibert this filtering approach is incredibly hard to get right considering all the places you need to apply it.

That said, I think we need to "wait a little" before we jump on this wagon. I have consolidated a lot of code in this department lately, but the above, while not super-hard, is a little bit more clumsy to apply than I would like.

I plan to add the first edition of "Pages from data" in Hugo 0.49, and it would be cool if someone bumbed this thread once that is out (should not be tooooo long), and see how to apply this to the code base as it looks then.

[regisphilibert]

Hugo 0.49

I assume .59 which is awesome!

[bep]

I assume .59 which is awesome!

No, it will also enable a Hugo Time Machine Mode; if you want you can dial it in to a time where Jekyll was the hippest kid in town.

[nancym]

Here's what I use unlisted pages for: I've started using Hugo for my online tagged bookmarks. Most of these bookmarks and tags are not mentioned anywhere on my site, but I can get to them because I know the secret URLs. It's fine if someone stumbles upon them because there's nothing private there. I hide them mainly because I want my site to be apolitical and I bookmark some political things. The way I currently hide these is by including this in front matter:

weight: 88888888

And things like this in layout files:

    {{ range .Site.Taxonomies.tag }}
      {{ if ne .Count 1 }}
        {{ if ne .Page.Weight 88888888 }}

This feels incredibly hacky and I'm always thinking there must be a better way to do this!

It would be great if "unlisted" were built into Hugo. Thank you!

[felicianotech]

I support this feature.

A scenario which we've done in documentation sites a lot is when there is a page for a deprecated feature. You'd want that page to still be built and available directly for people who have it bookmarked already and direct links from blog posts, etc.

You don't want it "listed" though because you don't want new users in "research" mode to accidentally stumble upon it.

[bep]

@felicianotech I support this feature too. I have created this, more practical issue, to track it:

https://github.com/gohugoio/hugo/issues/6412

I'm closing this. Let's take further discussions there.