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

Fix Node vs Page #2297

Closed
bep opened this issue Jul 21, 2016 · 3 comments · Fixed by #2649
Closed

Fix Node vs Page #2297

bep opened this issue Jul 21, 2016 · 3 comments · Fixed by #2649

Comments

@bep
Copy link
Member

bep commented Jul 21, 2016

This issue tracks improvements as described in https://discuss.gohugo.io/t/node-improvements/1593

Related issues dangling around will be closed as they must be considered when fixing this.

bep added a commit that referenced this issue Jul 26, 2016
This commit also consolidates URLs on Node vs Page, so now .Permalink should be interoperable.

Note that this implementations should be fairly short-livded, waiting for #2297, but the API should be stable.
bep added a commit that referenced this issue Jul 30, 2016
This commit also consolidates URLs on Node vs Page, so now .Permalink should be interoperable.

Note that this implementations should be fairly short-livded, waiting for #2297, but the API should be stable.
bep added a commit that referenced this issue Aug 4, 2016
This commit also consolidates URLs on Node vs Page, so now .Permalink should be interoperable.

Note that this implementations should be fairly short-livded, waiting for #2297, but the API should be stable.
bep added a commit that referenced this issue Aug 8, 2016
This commit also consolidates URLs on Node vs Page, so now .Permalink should be interoperable.

Note that this implementations should be fairly short-livded, waiting for #2297, but the API should be stable.
bep added a commit that referenced this issue Aug 10, 2016
In a multi-language setup, before this commit the Node's Translations() method
would return some "dummy nodes" that would point to the correct page (Permalink),
but would not be the same as the node it points to -- it would not have the translated
title etc.

The node creation is, however, so mingled with rendering, whihc is too early to have any global state,
so the nodes has to be split in a prepare and a render phase. This commits does that with as small
a change as possible. This implementation is a temp solution until we fix #2297.

Updates #2309
bep added a commit that referenced this issue Aug 13, 2016
This commit also consolidates URLs on Node vs Page, so now .Permalink should be interoperable.

Note that this implementations should be fairly short-livded, waiting for #2297, but the API should be stable.
bep added a commit that referenced this issue Aug 13, 2016
In a multi-language setup, before this commit the Node's Translations() method
would return some "dummy nodes" that would point to the correct page (Permalink),
but would not be the same as the node it points to -- it would not have the translated
title etc.

The node creation is, however, so mingled with rendering, whihc is too early to have any global state,
so the nodes has to be split in a prepare and a render phase. This commits does that with as small
a change as possible. This implementation is a temp solution until we fix #2297.

Updates #2309
bep added a commit that referenced this issue Aug 15, 2016
This commit also consolidates URLs on Node vs Page, so now .Permalink should be interoperable.

Note that this implementations should be fairly short-livded, waiting for #2297, but the API should be stable.
bep added a commit that referenced this issue Aug 15, 2016
In a multi-language setup, before this commit the Node's Translations() method
would return some "dummy nodes" that would point to the correct page (Permalink),
but would not be the same as the node it points to -- it would not have the translated
title etc.

The node creation is, however, so mingled with rendering, whihc is too early to have any global state,
so the nodes has to be split in a prepare and a render phase. This commits does that with as small
a change as possible. This implementation is a temp solution until we fix #2297.

Updates #2309
bep added a commit that referenced this issue Aug 20, 2016
This commit also consolidates URLs on Node vs Page, so now .Permalink should be interoperable.

Note that this implementations should be fairly short-livded, waiting for #2297, but the API should be stable.
bep added a commit that referenced this issue Aug 20, 2016
In a multi-language setup, before this commit the Node's Translations() method
would return some "dummy nodes" that would point to the correct page (Permalink),
but would not be the same as the node it points to -- it would not have the translated
title etc.

The node creation is, however, so mingled with rendering, whihc is too early to have any global state,
so the nodes has to be split in a prepare and a render phase. This commits does that with as small
a change as possible. This implementation is a temp solution until we fix #2297.

Updates #2309
bep added a commit that referenced this issue Aug 20, 2016
This commit also consolidates URLs on Node vs Page, so now .Permalink should be interoperable.

Note that this implementations should be fairly short-livded, waiting for #2297, but the API should be stable.
bep added a commit that referenced this issue Aug 20, 2016
In a multi-language setup, before this commit the Node's Translations() method
would return some "dummy nodes" that would point to the correct page (Permalink),
but would not be the same as the node it points to -- it would not have the translated
title etc.

The node creation is, however, so mingled with rendering, whihc is too early to have any global state,
so the nodes has to be split in a prepare and a render phase. This commits does that with as small
a change as possible. This implementation is a temp solution until we fix #2297.

Updates #2309
bep added a commit that referenced this issue Sep 6, 2016
This commit also consolidates URLs on Node vs Page, so now .Permalink should be interoperable.

Note that this implementations should be fairly short-livded, waiting for #2297, but the API should be stable.
@bep bep closed this as completed in a07293c Sep 6, 2016
@VoidingWarranties
Copy link

Has this been resolved? Curious because in a07293c the commit message says

... This implementation is a temp solution until we fix #2297.

@bep
Copy link
Member Author

bep commented Sep 14, 2016

No it was closed by mistake.

bep added a commit that referenced this issue Nov 22, 2016
* `.Site.Pages` now contains all page types, including sections etc.
* `.Data.Pages` will also contain "node type" pages where relevant.

Updates #2297
bep added a commit that referenced this issue Nov 22, 2016
As an alias to .Data.Pages for home page etc.

Also renamte NodeType to PageType and make it a string so it can be used in `where`.

Updates #2297
bep added a commit that referenced this issue Nov 22, 2016
bep added a commit that referenced this issue Nov 22, 2016
bep added a commit that referenced this issue Nov 22, 2016
And embed that on Page.

Updates #2297
bep added a commit that referenced this issue Nov 22, 2016
Having a custom string type isn't worth it when it doesn't work
with `where`, `eq` etc.

Fixes #2689
Updates #2297
bep added a commit that referenced this issue Nov 22, 2016
And misc. TODO-fixes

Updates #2297
bep added a commit that referenced this issue Nov 22, 2016
This includes removing the error return value from Permalink and RelPermalink.

We ignore that error all over the place, so we might as well remove it.

Updates #2297
bep added a commit that referenced this issue Nov 22, 2016
bep added a commit that referenced this issue Nov 22, 2016
By embeding the init sync.Once var in a pointer so we can reset it when we copy the page.

Updates #2297
bep added a commit that referenced this issue Nov 22, 2016
bep added a commit that referenced this issue Nov 22, 2016
Returning all types is both confusing and too breaking.

All page types can be fetched in .Site.Pages.

Updates #2297
bep added a commit that referenced this issue Nov 22, 2016
bep added a commit that referenced this issue Nov 22, 2016
Some sites, Hugo docs included, have faulty alias definitions that point
to itself or another real page. These will be overwritten in the next step.

This is how it behaves in Hugo 0.17, too.

Updates #2297
bep added a commit that referenced this issue Nov 22, 2016
bep added a commit that referenced this issue Nov 22, 2016
Because it is the right solution and it the avoids naming conflict with section vs page.

Updates #2297
bep added a commit that referenced this issue Nov 22, 2016
bep added a commit that referenced this issue Nov 22, 2016
bep added a commit that referenced this issue Nov 22, 2016
bep added a commit that referenced this issue Nov 22, 2016
bep added a commit that referenced this issue Nov 22, 2016
bep added a commit that referenced this issue Nov 22, 2016
bep added a commit that referenced this issue Nov 22, 2016
And some other minor doc fixes.

Closes #2297
Closes #2649
tychoish pushed a commit to tychoish/hugo that referenced this issue Aug 13, 2017
This commit also consolidates URLs on Node vs Page, so now .Permalink should be interoperable.

Note that this implementations should be fairly short-livded, waiting for gohugoio#2297, but the API should be stable.
tychoish pushed a commit to tychoish/hugo that referenced this issue Aug 13, 2017
In a multi-language setup, before this commit the Node's Translations() method
would return some "dummy nodes" that would point to the correct page (Permalink),
but would not be the same as the node it points to -- it would not have the translated
title etc.

The node creation is, however, so mingled with rendering, whihc is too early to have any global state,
so the nodes has to be split in a prepare and a render phase. This commits does that with as small
a change as possible. This implementation is a temp solution until we fix gohugoio#2297.

Updates gohugoio#2309
@github-actions
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 31, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants