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

Page.Author and .Authors and Site.Authors do nothing #10551

Closed
willfaught opened this issue Dec 19, 2022 · 15 comments
Closed

Page.Author and .Authors and Site.Authors do nothing #10551

willfaught opened this issue Dec 19, 2022 · 15 comments

Comments

@willfaught
Copy link

I can't seem to be able to set Page.Author or .Authors. If I set author: and authors: in frontmatter, they appear in .Params, not .Author or .Authors.

Weirdly, if I set Page.Authors to a string or map instead of a string slice, then Hugo fails with an error:

execute of template failed at <.Authors>: error calling Authors: interface conversion: interface {} is maps.Params, not []string

Site.Authors seems to do nothing too.

With this site config:

author:
  email: example@example.com
  name: Michael Bluth
authors:
  will:
    givenname: will
  nick:
    given_name: nick

and with this page frontmatter:

author: Hugo Authors
authors: ["will", "nick"]

and this page template:

1 {{ printf "%#v" .Authors }}
2 {{ printf "%#v" .Author }}
3 {{ printf "%#v" .Params.author }}
4 {{ printf "%#v" .Params.authors }}
5 {{ printf "%#v" .Site.Author }}
6 {{ printf "%#v" .Site.Authors }}

This is printed:

1 page.AuthorList{}
2 page.Author{GivenName:"", FamilyName:"", DisplayName:"", Thumbnail:"", Image:"", ShortBio:"", LongBio:"", Email:"", Social:page.AuthorSocial(nil)}
3 "Hugo Authors"
4 []string{"will", "nick"}
5 map[string]interface {}{"email":"example@example.com", "name":"Michael Bluth"}
6 page.AuthorList(nil)

What version of Hugo are you using (hugo version)?

$ hugo version
hugo v0.108.0+extended darwin/amd64 BuildDate=unknown

Does this issue reproduce with the latest release?

Yes

@jmooring
Copy link
Member

@willfaught

Is there some documentation that lead you down this path? If so, it should be removed. See;
https://discourse.gohugo.io/t/site-author-usage/31459/8

@willfaught
Copy link
Author

https://gohugo.io/variables/site/:

.Site.Author

https://gohugo.io/variables/page/#access-nested-fields-in-front-matter:

---
author:
  given_name: John
  family_name: Feminella
  display_name: John Feminella
---

https://pkg.go.dev/github.com/gohugoio/hugo/hugolib#SiteInfo:

type SiteInfo struct {
	Authors page.AuthorList

https://pkg.go.dev/github.com/gohugoio/hugo@v0.108.0/resources/page#PageWithoutContent:

type PageWithoutContent interface {
...
	// TODO(bep)
	AuthorProvider

@willfaught
Copy link
Author

Also note that in https://discourse.gohugo.io/t/site-author-usage/31459/8, you suggest using Page.Params.author, not Page.Author:

{{ index .Site.Author .Params.author "name" }}

@willfaught
Copy link
Author

Sure, but deprecated doesn't mean broken or discontinued. Did they never work? That would be different.

@jmooring
Copy link
Member

To the best of my knowledge they were never implemented, but that's ancient history.

The documentation (https://gohugo.io/documentation/) should reference nothing but .Site.Author. If that is not the case, please create an issue in the docs repository.

@jmooring
Copy link
Member

Correction. See gohugoio/hugoDocs@2c0125b.

.Site.Author is no longer documented, and will be deprecated at some point.

@kilasuit
Copy link

@willfaught They did work as I had this working on a local build on a machine that died on me back in May & I am so annoyed that I hadn't managed to back up my working on the theme that I used it in

@kilasuit
Copy link

@jmooring is there a blog post explaining why these are being deprecated as right now this to me makes no sense without a better understanding of the though of the future direction of travel

@kilasuit
Copy link

@jmooring sorry but if people are reliant on prior versions of software that had features that they are using that are then being deprecated it is totally immoral for one to delete that documentation. mark it as not current/archived/not maintained by the project for sure, but don't be so damn cheap as to delete it entirely.

@willfaught
Copy link
Author

@kilasuit I can't speak for the project maintainers, but I think they're encouraging a new way going forward, where authors are represented as a taxonomy. You can see my first attempt at doing that here.

@kilasuit
Copy link

sure encourage but don't belittle those that aren't able to keep up with the pace of change and are set at a specific version for what ever reason that may be, mostly likely wanting stability and not instability

@willfaught
Copy link
Author

Perhaps you're unfamiliar with Go module versioning, which uses semver. Minor version 0 allows for breaking changes between minor versions. We shouldn't expect API stability until v1.0.0 is released. I would guess they try to minimize breaks, regardless.

@kilasuit
Copy link

nah i'm well versed with it, I just don't agree at deleting documentation ever when it should be pointed that this is out of date and not being maintained, which is the morally right thing to do and even if it is not the cheap thing to do

@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 Jan 20, 2023
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