Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

.GetTerms returns empty set for pages with _build: render: never in 0.123 #12044

Closed
TiGR opened this issue Feb 15, 2024 · 6 comments
Closed

.GetTerms returns empty set for pages with _build: render: never in 0.123 #12044

TiGR opened this issue Feb 15, 2024 · 6 comments

Comments

@TiGR
Copy link

TiGR commented Feb 15, 2024

Say, you have some pages with this code:

_build:
  list: local
  render: never

That is, you don't need separate files for these files, but you render these pages elsewhere. However, when you get that page, you get weird results. First up, .GetTerms "tags" for example returns empty set.

Example site. In hugo 0.122 this site shows the following:

WARN  Test Page file tags:
WARN  -- Tag One (Test Page)

In hugo 0.123:

WARN  Test Page file tags:

So, it can't list tags. Also, in some a bit more complex environment (can't yet reproduce in simple site), when I dump subpage from a variable I get not Page(/path/to/page), but Page(nil) for pages having _build: render: never.

@TiGR TiGR changed the title .GetTerms for pages with _build: render: never in 0.123 .GetTerms returns empty set for pages with _build: render: never in 0.123 Feb 15, 2024
@jmooring
Copy link
Member

jmooring commented Feb 15, 2024

I'm not sure about this; it's a complex question involving many use cases. For discussion...

Build options: when should a page's terms contribute to a taxonomy object?


RENDER
always link never
LIST always ✔️ ? ?
local ✔️ ? ?
never ✔️

The cells that I've filled in are, to me, obvious choices.

If we were starting from scratch, I'd say do this:

RENDER
always link never
LIST always ✔️
local ✔️
never ✔️

The behavior with v0.123.0 is different than v0.122.0, but I think it might be better. For example, v0.123.0 fixed #10694 which (obviously) leaked information.

@TiGR
Copy link
Author

TiGR commented Feb 16, 2024

I think that there should be an option to make it work as I describe it: that is, no separate pages are generated, but you can work with these pages, use tags, etc. In our case, we have lists of updates (which usually are just a sentence, and there is no need to make it into a page, but we list them on some pages, and we need them as separate instances, so that we could do various lists, depending on some sort of filters). So, we need an ability to render it, but not in separate pages (as it would create about a one hundred thousand unneeded pages).

@bep bep added this to the v0.124.0 milestone Feb 16, 2024
@jmooring
Copy link
Member

jmooring commented Feb 16, 2024

Rethinking my "if we we'e starting from scratch" scenario, I think it should look like this instead:

RENDER
always link never
LIST always ✔️ ✔️
local ✔️ ✔️
never ✔️ ✔️

EDIT: And that's how it works in v0.123.0, so I think we got it right. The behavior in v0.122.0 is below, which was not great:

RENDER
always link never
LIST always ✔️ ✔️ ✔️
local ✔️ ✔️ ✔️
never ✔️ ✔️ ✔️

@TiGR

I think that there should be an option to make it work as I describe it

I think you already have that with:

[build]
render = 'link'
list = 'local'

The documentation for render = "link" states:

Do not render the page to disk, but assign Permalink and RelPermalink values.

Perhaps we could clarify this, something like:

Render page and assign Permalink and RelPermalink values, but do not render to disk.

@jmooring
Copy link
Member

@TiGR Given my previous comment, I think we should close this.

@TiGR
Copy link
Author

TiGR commented Feb 18, 2024

Yes, I think it works

Copy link

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 11, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants