[Solved] Baffling 'range .Pages' error in sections in 0.22

Testing 0.22 (Mac), I’ve got an odd problem in my sidebar partial (included below). In 0.21, it works perfectly. In 0.22, the first section (range first 10 .Pages) works, but the second (range .Pages.ByTitle) lists every content page.

The thing is, switching the two range statements doesn’t switch the problem. Using range .Pages.ByTitle works fine for the “recently-spotted” section, generating the correct list of titles, but range first 10 .Pages still shows content files from all sections when called from the “elsewhere” section.

There are a total of 7,508 MD files in content, 38 of them in “elsewhere” and 615 in “recently-spotted”. The full diff is twice the size of the site, the site takes twice as long to build, and public is 500+ MB on disk instead of 90 MB, so there’s a lot more going on, but this is the first piece I’ve nailed down.

{{ with $.Site.GetPage "section" "recently-spotted" }}
<div class="sidebar-module">
  <h4>Recently Spotted</h4>
  <ol class="list-unstyled">
  {{ range first 10 .Pages }}
    <li><a href="{{ .Params.link }}">{{ .Title | safeHTML }}</a></li>
  {{ end }}
  <li><a href="/recently-spotted"><span class="glyphicon glyphicon-menu-down"/></a></li>
  </ol>
</div>
{{end}}

{{ with $.Site.GetPage "section" "elsewhere" }}
<div class="sidebar-module">
  <h4>Elsewhere</h4>
  <ol class="list-unstyled">
  {{ range .Pages.ByTitle }}
    <li><a href="{{ .Params.link }}">{{ .Title | safeHTML }}</a></li>
  {{ end }}
  </ol>
</div>
{{end}}

-j

I assume you cannot share your project?

I would not focus too much on the ByTitle.

What is your section structure?

Is it:

/content/
/7K files
/recently-spotted/
/elsewhere/

And no _index.md files?

It’s not in a public repo, no.

The section under content look like this (no index.md files anywhere):

/_comment (1,206 files)
/archive (173 files)
/elsewhere (38 files)
/post (2,885 files, split across 40 sub-directories by filename)
/projects (14 files)
/quotes (272 files)
/recently-spotted (615 files)
/repeating-endlessly (88 files)

/_comment is my imported comments that are only rendered via taxonomy. /archive contains stubs generated by a script so I can have monthly archive pages. /post is the actual blog; the rest are microblogs with only list templates.

The sub-directories under /post are just for breaking up the directory into manageable chunks. I’m using the original Movable Type entry ID as the filename, so it looks like /content/post/0034/003447.md, etc.

-j

To be specific, I asked for “_index.md” files, i.e. no prefix, but I assume the answer is still no.

I assume I have “borked” up something with my section logic, but I haven’t seen anything like this in my tests. Will have a closer look/think about this.

Heh, typo on my part; yes, I meant “no _index.md files”. :slightly_smiling:

I can tar up the site if you need it; I just don’t want to put it in a public repo (I use Mercurial in a privately-hosted Kallithea instance for source control).

-j

I would really appreciate if you could – because I have a hard time guessing what it could be. It is probably something “stupid” and obvious when I see it.

You can PM me a link to an archive or mail me at bjorn.erik.pedersen@gmail.com.

1 Like

Done.

Thanks, yes, I see what happens – just have to find the simplest fix.

This releases should fix your issue:

I have tested it OK on your site. (on a footnote: You should consider getting rid of the “comment” taxonomy definition in your config, not sure how useful a taxonomy with mostly unique values is).

1 Like

Thanks. I’ll check it out tonight.

When I exported everything from Movable Type, I put the comments into individual content files to preserve their front matter, and linked them to their parent article through that taxonomy. I could have baked them into the article, but then I’d never be able to go back and clean them up. (new comments are in Isso, and since it doesn’t really support closing threads, I’m planning to export them to content files and then delete them from its DB)

-j

Had some downtime at the conference, so I grabbed 0.22.1 and diffed the output against 0.21. The only differences were the expected “noindex” change and the hugo version meta tag.

Thanks for the quick turnaround on this.

-j

1 Like