HUGO

Best practices for theme development & Hugo Modules

Hi,

So this is sort of a combination question:

  1. I’m having some difficulty working on a theme when my website is using the theme via a hugo module. I push a change to my public forked repository, which I have replaced as the hugo module in my config.toml:
#    path = "github.com/lxndrblz/anatole"
    path = "github.com/cdichiara/anatole"

I’m not seeing changes reflected. Is there some command to re-initialize the hugo modules that I forgot to run?

  1. What is the best practices that people are doing when they’re working on a theme? Should I create a dummy website and have github mount the theme in the /themes/ directory in order to make changes without pushing?

Thanks in advance,

Carmine

Theme overrides are the way to go for third party themes, so that the original can be updated.
The overrides go under /project-root/layouts/ you need to replicate the PATH of the theme template you wish to customize.

See: hugo mod get | Hugo

Ah thank you again @onedrawingperday … so I’m helping develop the theme, not just overriding it for this one website. That’s why I forked the theme and am making fixes. I’m trying to figure out if people have best practices for quick updates of themes that are mounted using the Module system, or if they just revert to mounting the theme statically for the duration of development.

Ah yes … so the interesting thing is, either I ran that command or somehow I picked up my module change anyways … because in go.mod I can see the new module being required and in go.sum I see the hash. But up to now I haven’t been able to see my changes reflected in the test website. In the end I may just abandon using the modules for development … maybe it’s not worth the challenge and the mandatory pushes.

Thanks,

Carmine

For theme dev and testing, I use a development config that points to a local module: Configure Hugo | Hugo

then I have a production config that points to the github location.

1 Like

Thank you @pointyfar that confirms it, I bit the bullet and mounted the theme as a submodule for dev purposes. I’ll look into separate dev and production configs.

Carmine

Just to clarify, something like this is what I meant:

├── site-foo
│   ├── config
│   │   ├── _default
│   │   ├── development
│   │   └── production
│   └── ...
└── themes
    ├── theme1
    └── theme2
# dev
themesDir = "../../themes"
theme = "theme1"

# prod
theme = "github.com/pointyfar/theme1"

I do not use git submodules.

1 Like

Ah that’s cool thanks for the diagram I like the approach.

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