I have a simple site is keyed to the calendar and grows by 200-400 pages per year. Presently I’m at 2200 pages and it takes ten seconds to build.
I would prefer NOT to modify or update pages from previous years, though that often happens as I heavily leverage shortcodes and json data sources for content. Those shortcodes, some of which have significant decision trees, continue to evolve. Many of the pages look similar from year to year, but the finer details are always changing.
I would like to archive pages so that I can have:
the freedom to evolve shortcodes without worrying about distorting older pages
faster builds
Is there a preferred way to archive pages within my site so that they will not be rebuilt any more?
Could I, for example, copy sub-directories of the deployed (html) site into the static folder and link them from the relevant content page? Or perhaps I should keep separate repo’s for older years and somehow mount them into the current one?
Before going into partial builds with caching parts I would check template metrics if there are candidates for using partialCached. Check the time consuming/often called ones for code improvements.
One approach maybe exclude the old pages (by year folders) from standard builds. cache the old segments and just build the one for the new pages
keep in mind, that that won’t help if you loose your rendered “caches” without some versioning. tag your repo and in case you loose your caches
versioning your shortcodes sc-v1, sc-v2
check for old pages in shortcode and ignore
implement a version guard in the shortcodes that calls different code
version your repo use tags to go back
tag your repo and in case you loose your caches start rebuilding for each tag/segment.
tried to do a bare build after clone on wndows.
duplicate pagenames Capitalization
warning: the following paths have collided (e.g. case-sensitive paths
on a case-insensitive filesystem) and only one from the same
colliding group is in the working tree:
'content/archive/2023/Proper-19.md'
'content/archive/2023/proper-19.md'
'content/archive/2023/Proper-28.md'
'content/archive/2023/proper-28.md'
'content/archive/2024/Proper-14.md'
'content/archive/2024/proper-14.md'
'docs/images/qr/archive/2023/Proper-19.png'
'docs/images/qr/archive/2023/proper-19.png'
'docs/images/qr/archive/2023/Proper-28.png'
'docs/images/qr/archive/2023/proper-28.png'
'docs/images/qr/archive/2024/Proper-14.png'
'docs/images/qr/archive/2024/proper-14.png'
'static/images/qr/archive/2023/Proper-19.png'
'static/images/qr/archive/2023/proper-19.png'
'static/images/qr/archive/2023/Proper-28.png'
'static/images/qr/archive/2023/proper-28.png'
'static/images/qr/archive/2024/Proper-14.png'
'static/images/qr/archive/2024/proper-14.png'
build errors with hugo 164.0
hugo
WARN deprecated: project config key languageCode was deprecated in Hugo v0.158.0 and will be removed in a future release. Use locale instead.
Start building sites …
hugo v0.164.0-ce2470e7012b5ab5fc4e10ebe4027e9f8d9e00dc windows/amd64 BuildDate=2026-07-06T16:39:30Z VendorInfo=gohugoio
Total in 36151 ms
ERROR error building site: assemble: failed to create page from pageMetaSource /archive/2021/he-covid-augustinearchbishop: "C:\_repos\github\clone\topic-57468-archive\content\archive\2021\he-covid-augustinearchbishop.md:5:1": [4:1] mapping key "title" already defined at [1:1]
1 | title: Holy Eucharist, Rite II (Augustine, First Archbishop of Canterbury)
2 | date: 2021-05-26
3 | lectionaryyear: b
> 4 | title: "Holy Eucharist for Augustine, First Archbishop of Canterbury, 605"
^
5 | bcppage: 355ff.
Thanks for the reply – and for digging up the fact I’ve asked this before! Three years later the question is shaped differently because I have twice as many pages to generate. Performance is a concern, but I’m pretty convinced that “segmenting the build” would render the performance issue negligible.
Thanks, too, for trying to build and discovering the filename conflicts. I wonder if those are only in 2023-2024. That looks like technical debt that ought to be paid down someday.
Versioning the short-codes: you offer several excellent options. Thank you. Some of them were offered to me three years ago, and some partially implemented. I keep weighing complexity against the fact that I only dive into the code about once every other year (and therefore desire a clean, simple, readable system).
Segments look like a promising direction, though they would require a more complicated call to hugo to build and not lose my old versions. Is this how makefiles came to be? As you say, my git history will be my friend in this.
It seems the answer is [still] not going to be as simple as I hoped for my idiosyncratic use-case. @irkode Thank you for engaging the conversation with me. I’m going to look into segments.
If it were my site I would, as suggested before, version your shortcodes, and I wouldn’t complicate things by somehow taking older content out of the workflow to reduce build times.
At the rate you’re adding pages it will take another 5-10 years to double the page count. And in a CI/CD workflow, a 10-20 second build is noise.
Thank you again for helpful input – and your continued generosity to the hugo community.
It’s all about context, isn’t it? In a CI/CD workflow, you’re right: speed (on this scale) wouldn’t be a relevant thought. For my little manually-built hobby site, I can put up with longer build-times (though memories of optimizing builds as a software dev makes me want a faster turnaround when there’s no reason to re-render 95% of the pages during most builds). But yes, I am certainly weighing the complexity of segments (and the startup cost of figuring them out!) against my 10 second waits.
I think you’re right that versioning my shortcodes is probably something I need to do. Though that adds its own complexity.
So really this is an exercise in weighing out my own values and hopes against the ways that hugo is meant to be used. Thank you (again) for giving me some clarity on what makes sense on the hugo side!
As you say, my git history will be my friend in this.