Archetype fun and games

Greetings.

I have created a number of custom archetypes within a new theme I’ve built:

themes/myCustomTheme/archetypes/firstLevel/secondLevel/archetypeFileToUse.md

I expect, when I run the command:

hugo new firstLevel/secondLevel/relatedContentFile.md

that the correct archetype is used, however it is not.

Do I need to add something in config.toml perhaps?

Are my assumptions about using the same hierarchy in both my site/content directory vs theme/archetypes directory incorrect here?

The hierarchy I’ve chosen exists for $reasons… if it’s pertinent to how you answer I’ll elaborate but I suspect I’m just missing some fundamental understanding from the docs here.

Thanks in advance for your assistance.

You’re close.
Let’s use an example similar to the one in directory based archetypes.
Given archetype structure:

archetypes/
├── default.md
└── post-bundle
    └── index.md

When running:

hugo new --kind post-bundle post-1

Then this will be created:

content/
└── post-1
    └── index.md

Note: Notice that post-1 was used as the path arg, not post-1.md. This matters. Because anything you place inside the archetypes post-bundle dir will be generated for a new page when using the flag --kind

1 Like

Thank you @zwbetz! You are a wonderful human being!

I did read about these directory based archetypes and knew it had to be something like this.

My trial and error attempts, however, were unsuccessful. This was the information I was missing.

Thanks again.

1 Like

Happy to hear you got things working :+1:

For future readers, and for my own curiosity, would you share your archetype structure and the command(s) you ran?

Alas I spoke too soon… it appears it’s not actually working… you’ll have to forgive me I’m very new to Hugo and am attempting to build a more comprehensive theme for hospitality businesses to offer up to the community as a means of getting to grips with the technology.

let me show you what i’m doing here:

Site file structure

(i’ve omitted some dirs for easier reading)

site-directory
         |_ content
         |     |_ menu
         |         |_ degustation
         |         |_ dine
         |         |_ drinks
         |         |_ seasonal
         |         |_ takeaway
         |
         |_ themes
               |_ hospo-hugo-theme
               |    |_ archetypes
               |         |_ menu 
               |             |_ degustation
               |                  |_ index.md
               |             |_ dine
               |                  |_ index.md
               |             |_ drinks
               |                  |_ index.md
               |             |_ seasonal
               |                  |_ index.md
               |             |_ takeaway
               |                  |_ index.md
               |
               |_ layouts
               |   |_ menu
               |        |_ degustation
               |            |_ single.html
               |            |_ list.html
               |        ...                       

An archetype example:

# degustation archetype example
---
draft: true
title: "{{ replace .Name "-" " " | title }}"
slug: ""
type: "menu"
category: "degustation" 
course: "" #["hors d'oeuvres","soup","fish","main","salad","dessert"]
tags: []  
layout: "menu/degustation/single.html"
images: []
price: ""
---

A layout example

# Layout for a single degustation menu item/course
# I'm yet to work on these templates ... WIP

<article class="foodMenuItem">

  {{ .Content }}

</article>

Command example

hugo new menu/degustation/filet-mignon -k

Notes

  • hugo version:
    Hugo Static Site Generator v0.58.1/extended linux/amd64 BuildDate: 2019-09-06T16:42:16Z

  • menu items should be separate bits of content as opposed to simply defining them in config.toml. The reason behind this as menus will change and having previously written content available saves time and effort. The idea being we can toggle draft = true/false to publish.

  • developers will have the templates all ready and awaiting their own specific customizations, which means they can delete any of these menu dirs that they don’t require to eliminate kruft.

  • i’ll be attempting to follow ABEM CSS methodology, and am also trying to keep consistent naming convention throughout.

  • I’m confused a little by this, and hope it’s ok just to use “menu” for consistency rather than single and plural stipulation.

  • running the aforementioned command simply causes the help text to be displayed in terminal

Questions

  1. is the word “bundle” significant in your earlier example? e.g post-bundle, menu-bundle?

  2. Anything more I can add to help with your understanding?

  3. Am I over-complicating things? The reason for this approach is to make it simpler for the user first and foremost, then developer.

Thanks again for your interest and assistance.

Might be overcomplicating things.

A few things to ask at this point:

  1. will the user be using a CMS? this might have implications of ease of editing, how your data is structured, etc.
  2. Might want to look at Data since it seams that you are trying to separate “menu items” from a particular “menu”

Since in Hugo “everything is a page” (unless it is Data) there might be some URL/Permalink effects when certain pages are building and then later not building (i.e. broken links might pop up, at least on sites linking to yours).

I’ve found it useful to very carefully map out how all these things are connected (being very aware of the URL structure) and trying to reduce things down.

CMS? <=> Archetypes <=> Content <=> Layouts <=> Build

This is not a linear flow/mapping. Classic design problem – think it through, though at some point you’ll have to take a subjective call.

1 Like

oh my gosh I feel stupid now.

Thanks @HenrySkup this ‘data’ route looks a far better way to go. I hadn’t actually got that far through the docs and really should have known better.

With that in mind I will make some changes now and once I’ve got it working I will show my workings here on this thread in case its useful to other new users.

My intention is to use Netlify CMS btw. :slight_smile:

1 Like

Might be good to figure out to use multi-select where the options are populated based on what is in the data folder/ a particular data file.

Some stream of consciousness…
now that i think about that, i should try to do that with forestry.io and maybe Hugo Pipes??? I’m pretty sure that you could do that with a build system (Grunt, etc.) but since I haven’t taken that plunge, IDK. Though this route might not work if you are updating possible menu items in Data in real time when trying to add them to a particular menu… something would have to generate those options and put them in the CMS config before they appear elsewhere in the CMS…

1 Like

Good idea.

I’m feeling better about this now thanks to your insight. Thanks again.

It’s time for me to rest, so I’ll let this all digest, pick it up again in the morning and see if I can’t make some solid progress.

On another note, I’m super impressed with the body of work you have displayed on your personal site. So cool! Small typo in your about section you may wish to correct:
infomration => information.

All the best.

1 Like

Thank you so much! It’s a little out of date right now, but I should get out a new version (which uses Hugo Mods) out soon!

Haha :stuck_out_tongue: spelling has never been a strong suit!

1 Like