Content adapters: Site.GetPage without fully qualified path cannot find page

support
1

The Content Adapter page is properly created, and listed with the other posts
But it’s not able to use GetPage to retrieve it.

dunno if this is kind of expected or a bug… please have a look

  • hugo new && hugo new theme

  • with this content adapter: themes\hugo\content\posts\_content.gotmpl

     {{ $content := dict
    "mediaType" "text/markdown"
    "value" "Before<!--more-->After"
 }}
 {{ $page := dict
    "content" $content
    "kind" "page"
    "path" "post-4"
    "title" "post-4"
 }}
 {{ $.AddPage $page }}

  • and this home block definition : themes\hugo\layouts_default\home.html

    {{ define "main" }}
{{ .Content }}
{{ range site.RegularPages }}
  <h2><a href="{{ .RelPermalink }}">{{ .LinkTitle }}</a></h2>
  {{.Summary}}
{{ end }}

 {{ range (slice "post-1" "post-2" "post-3" "post-4") }}
    {{ with site.GetPage "posts" . }}
       {{ warnf " found: %s" . }}
    {{ else }}
       {{warnf "not found: %s" . }}
    {{ end }}
 {{ end }}
{{ end }}

  • calling hugo produces

    WARN  found: Page(/posts/post-1)
WARN  found: Page(/posts/post-2)
WARN  found: Page(/posts/post-3)
WARN  not found: post-4
2

I do understand that we at some point took 2 arguments in GetPage (and kept that for backwards compability), but see

I’m not saying that this will “fix” your template, but this would be the correct way:

{{ range (slice "post-1" "post-2" "post-3" "post-4") }}
    {{ with site.GetPage (printf "/posts/%s" .) }}
       {{ warnf " found: %s" . }}
    {{ else }}
       {{warnf "not found: %s" . }}
    {{ end }}
 {{ end }}
{{ end }}
1 Like
3

Ok. Got it. Will check that out…

May be worth to be deprecated?

found that 2 argument style in examples in the docs when searching for site.getpage

They use Page method not the global function. But someone told in Page context they behave identically. Ir is this a subtile difference.

Would be good to update the examples to the correct way. Or maybe comment that

Want me to create a docs issue or/and file a PR?

4

retiried with the one argument form with both $.Site.GetPage and site.GetPage

  • behaviour is consitent
  • the one argument version works
  • the two argument version does not work
WARN  site home two args     found: Page(/posts/post-1)
WARN  site home one arg      found: Page(/posts/post-1)
WARN  site home two args not found: post-4
WARN  site home one arg      found: Page(/posts/post-4)
WARN  $.Site home two args     found: Page(/posts/post-1)
WARN  $.Site home one arg      found: Page(/posts/post-1)
WARN  $.Site home two args not found: post-4
WARN  $.Site home one arg      found: Page(/posts/post-4)
5

Yes, you should be using one arg, but two args still works just fine. With two args, the first is a page kind, not a section name.

“posts” is a section name, not a page kind.

I’ve updated the docs to remove the examples with two args.

6

so `GetPage “page” “post-4” should return a created page - but it does not which for me concludes to

pages created by Content Adapter do not work with the two argument form

further observation

  • looks like the “kind” is ignored GetPage "OOPS" "post-1" returns a page

  • it fails if there exists more than one page with that name in the site
    page reference “/page-1” is ambiguous (the page exist in “/posts” and “/new”)

  • if one of the pages has been created with a content adapter the “normal” created page is returned

  • it won’t fail if one creates many pages

Summary:

  • inconsistent behavior for “created” and “normal” pages
  • two argument form does not consider kind
  • … may lead to strange effects in future

unless I got something terrible wrong and are on the wrong track :fearful:

7

First, in a broad sense this is not accurate:

pages created by Content Adapter do not work with the two argument form

For example:

git clone --single-branch -b hugo-forum-topic-50099 https://github.com/jmooring/hugo-testing hugo-forum-topic-50099
cd hugo-forum-topic-50099
hugo server

There may be some cases where the two argument form doesn’t behave as desired, but I have a difficult time getting excited about that. As discussed, the two argument form is no longer documented—don’t use it.

Second, you have definitely uncovered a bug related to the Site.GetPage method’s ability to “fuzzy find” a page:

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

But I’m not very excited about that one either. To me, if you want Hugo to get a page relative to the site, you should tell Hugo exactly which page to get.

1 Like
8

thx for the analysis, I must admit I did not check all cases.

definitely it’s solved with don’t use it and removal from docs.

and agreed in full path makes most sense, and for the rare case one knows he has that name only once in the site - it would be better to use full path, to have an exact reference on the long run.

fixed :wink: :tada:

9

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.