Node improvements

dev
21

In a similar situation, I just let the MD files on /content and it worked perfectly.

1 Like
22

Does that work for index.html? Setting /:title/ to index.html serves the content on /index/ in stead of /

23

Not sure what you’re talking about. Can you provide a little more info on what you’re trying to get done?

W/r/t @robsonsobral method of just keeping your single pagers at the root content folder, I don’t think this will work for your site’s index.html. If you’re talking about the index.html for a section homepage (list page), I’m not sure why you would want to keep the URL structure at the root. Does that make sense?

24

I have a structure like this:

content
└── singles
    ├── index.md

My config is set up like this:

permalinks:
  singles: /:title/

This works great for pages like /about, /contact, etc, but /content/singles/index.md maps to /index/. Is there a way to map it to / ?

25

@nathancahill I assume you’re talking about a homepage, right? Just add a full index.html to your layouts/ folder. Make sense?

Remember that your homepage is a list/node page with some added variables (eg, .IsHome).

Can you point me to a repo?

26

Can you please take this discussion into another thread … it bears only remotely relevance.

27

Has this Node problem been solved? I’m trying to set a custom title for a section by saving it in contents/posts/index.md and creating a list template in layouts/section/posts.html but it doesn’t work. Hugo tries to render index.md as content rather than as a node…

edit: I got it to work with .Site.Data but it looks extremely ugly :frowning:

{{ (index (index .Site.Data.sections (lower .Title)) "title" ) }}

28

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

29

I have started a implementation on this on my spare time.

https://github.com/spf13/hugo/pull/2649

Here is my tentative content structure:

content
├── _node.md
├── categories
│   ├── _node.md
│   └── photo
│       └── _node.md
├── post
│   ├── _node.md
│   └── hugo-rocks.md
└── tags
    ├── _node.md
    └── hugo
        └── _node.md

The above shows content files for home page, taxonomy list, taxonomy terms and sections.

Looks sensible?

Looking at the above I think maybe _index.md looks better instead of _node.md… ?

Note:

  • If no content file is provided for a node, a default page is created – it will work like today
  • I assume we should be able to set another content dir for these files
  • Also it would be nice if it was possible to set some default node content in themes

I still have some questions for myself, like – should it be possible to add taxonomies to node pages … so what if I tag the hugo tag with hugo …

3 Likes
31

This is a great idea with the underscore, but I would vote for _index.md since it’s easier to intuit. Just my 2 cents…

1 Like
32

This makes sense to me and I am excited to see where this goes!

1 Like
33

Small update on my implementation: The tests are all green – and this actually works now. Still many loose ends to tie, but it looks promising.

And faster (compared to the current master, which also is faster than the current release):

benchmark           old ns/op       new ns/op       delta
BenchmarkHugo-4     12606861551     11300837482     -10.36%

benchmark           old allocs     new allocs     delta
BenchmarkHugo-4     48522596       48506418       -0.03%

benchmark           old bytes      new bytes      delta
BenchmarkHugo-4     9800844224     9791154400     -0.10%
34

Awesome. I’ll download from source and play with this tonight. Question for you in terms of the docs project in working on with respect to your goals for this feature:

  1. Is the idea to get rid of the node/list page type altogether? As in, a way to decrease what seems like the oft-cited confusion of Node Vs Page?

  2. Does this have any possible implications for nesting content/directories?

35
  1. There will now only be Page, but there will still be a list term, as in a page can have Data.Pages. The API will work as before (IsNode, IsHom etc. will still work), but it will be a simpler mental model.
  2. Not now. I have 27 tasks and counting tasks listed, and I don’t want to add nested sections to that. It is a challenge to do major changes like this without breaking every site in the world.
36
  1. Got it. I think this will definitely help the mental model.
  2. I can see that being a big hurdle, so understood.

In terms of avoiding breaking changes, do you see that as a long-term goal with Hugo? The sort of “stability without stagnation” model (a la Ember.js)? Or maybe that for the project to live on there will inevitably be breaking changes (eg, V18 handling .Site.Params.config differently with casing)?

37

Hugo 0.18 isn’t released yet, so I would not conclude on the params casing debate yet (there is a PR from me in the pipe lline, see https://github.com/spf13/hugo/pull/2630).

Hugo is pre 1.0 so there will be some breaking changes until then, but they have to be worth it – because it costs a lot to do it in a polite way. We have 100+ themes, it would be bad if all the themes on themes.gohugo.io went black for 6 months, it would be bad if this forum started to fill up with questions about nil pointers that didn’t happen in Hugo 0.x and bug reports on GH about the same. So the care taken about keeping a fairly stable master branch is mainly motivated by saving head aches for myself, not so much me caring about other people.

But the nested sections isn’t about that (it should be possible to do that without havoc in the breaking glass department), that is not part of this issue because, well, it’s another issue – and it helps the focus on doing one thing at a time.

1 Like
38

I need some input on my naming scheme. In the whole “not breaking” stuff I decided to keep the Site.Pages etc. as they are today.

So, now everything is a Page, but we have different types of pages.

  • Pages lists the pages we currently know as a Page, a content page.
  • Nodes lists ALL pages, content pages, home page(s), sections, taxonomies etc.
  • A page’s type is identified with its NodeType
  • I will have to think about the API, but you will be able to use where to list all sections etc.
  • I will also probably expose a method on Site so you can easily fetch a single page (where that makes sense), i.e.:
    • .Site.GetPage("home")
    • .Site.GetPage("section", "blog")
    • .Site.GetPage("taxonomy", "tags", "hugo")

My main question to the above (other than the general: does it make sense?) is the distinction between the Pages and Nodes … I don’t have a better name for the latter.

39

Pages is now a subset of Nodes? Something like Node.filter(‘Content’)?

Are you looking to eventually standardize on using Node or Page? Node, to me, sounds like the better long term. Either way, add a log message on first use to say “deprecated please use blah”.

Is it possible (not asking easy) to add a “upgrade your theme” to automatically translate use of Page to Node? That would ease the six month hole.

40

Yes, Pages are a subset of Nodes.

I think I want ONE collection and that should be called Pages, but that is taken… So I can name it Nodes like I do now, and maybe deprecate the others.

I will have to think about this … when we get nested sections, it may make sense to create some kind of tree.