Disable unused taxonomy page kinds (closes #13) #29
Reference in New Issue
Block a user
Delete Branch "issue-13-disable-taxonomy-kinds"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Closes #13.
What changed
One config key in
hugo.toml, with a comment explaining why:plus the
TODO.mdentry in the same commit. Nothing else.Hugo enables the
tagsandcategoriestaxonomies by default. This site is asingle page with no taxonomy terms and no taxonomy templates, so Hugo generated
taxonomy list pages it had no layout for and warned on every build.
No taxonomy templates were added, and
--panicOnWarningwas not added — bothare explicitly out of scope on the issue.
Premise re-verified before implementing
The issue was written when the build used apk's hugo 0.139.0.
mainnow buildswith the pinned, hash-verified
v0.164.0fromscript/bootstrap, so theissue's text was not taken on trust. On
v0.164.0at9e3f955the warning isunchanged:
and
disableKindsis still the documented mechanism. Nothing to revise.Verification
Zero
WARNlines.make test,make lintand the fullmake checkallrun clean; the build output is now nothing but the hugo banner and the page
count table. The
WARNline above no longer appears anywhere.Rendered output otherwise unchanged.
public/built before and after andcompared with
diff -r. The only differences are the intended ones:categories/index.xml— gonetags/index.xml— gonesitemap.xml— trimmed, see belowindex.html,css/style.cssand the RSSindex.xmlare byte-identical.Sitemap still generated, still has the home page. This was the stated
revert condition, and it does not trigger. Before:
after:
The
sitemapkind is untouched by this change; only the two taxonomy URLs thesite never wanted are gone.
script/cibuildsucceeded with the check layer genuinely executed. Given#23 is still open, exit 0 alone is
not evidence, so the build was run with plain progress output and the layer
inspected.
RUN make checkreportedDONE 4.6swith its full output present —not
CACHED— running the container's own pinned hugo v0.164.0, and emittingno
WARN. (The upstreamRUN script/bootstraplayer wasCACHED, which iscorrect and desirable: this change does not touch
script/.) No builder prunewas used; this is a shared host.
Deploy path
script/bootstrapand.gitea/workflows/deploy.ymlare untouched, so the livedeploy path is unaffected and no temporary branch trigger was needed.
Not verified
The change was not exercised against a live Cloudflare Pages deploy — that
happens on merge to
main, and there is a standing TODO item for confirmingthe deploy after the recent workflow changes.
Hugo enables the `tags` and `categories` taxonomies by default. This site is a single page with no taxonomy terms and no taxonomy templates, so every build emitted WARN found no layout file for "html" for kind "taxonomy" and generated `categories/index.xml` and `tags/index.xml` that nothing links to. `disableKinds = ['taxonomy', 'term']` is the documented Hugo mechanism for a site that uses no taxonomies; it removes the warning at its source rather than suppressing it, and it does not create dead template files to satisfy the layout lookup. The premise was re-verified against hugo v0.164.0, the version now pinned in `script/bootstrap`, rather than trusted from the issue text, which was written when the build still used apk's 0.139.0. The warning and the unwanted pages are unchanged on v0.164.0. `make test`, `make lint` and `make check` now emit zero `WARN` lines, so the build's noise floor is zero and the next warning to appear will be visible instead of scrolling past. Rendered output is otherwise byte-identical: `index.html`, `css/style.css` and the RSS `index.xml` are unchanged, and `sitemap.xml` is still generated, now listing only the home page rather than two taxonomy URLs.Review: PASS
Independent review of
70048b3against#13. No blocking findings.
Central claims reproduced
Rebuilt the image with cache defeated on this image only
(
docker build --no-cache, throwaway tag, no builder prune).RUN make checkexecuted for real (
DONE 3.0s, full hugo output present, hugo v0.164.0 fromscript/bootstrap), and emitted zeroWARNlines acrossscript/test,script/lintandscript/fmt-check. On base9e3f955the same run emits thetaxonomy
WARN; on head it does not.Rendered output compared by md5 across both revisions (built in-container, no
bind mount, no root-owned artifacts):
index.html,css/style.cssand the RSSindex.xmlbyte-identical;categories/index.xmlandtags/index.xmlgone;sitemap.xmlthe only changed file, trimmed from three URLs tohttps://lora.vegas/. DoD item 4's revert condition does not trigger — thesitemap is still generated and still carries the home page.
Also verified: CI green on
70048b3(check / check, success); head is exactlyone commit on current
maintip9e3f955, fast-forward mergeable; diff is 2files with
TODO.mdin the same commit; commit title ends(closes #13);make fmtclean; no scope creep, no--panicOnWarning, no taxonomy templates,script/bootstrapand.gitea/workflows/deploy.ymluntouched; no Claude orAnthropic reference or attribution trailer anywhere in tree, diff, commit
message or PR body; no non-inclusive terminology.
Non-blocking
DoD item 2 evidence not literally satisfied. The issue says "Paste the
full build output into the PR to demonstrate it." The PR body asserts zero
WARNin prose but pastes no build output. Given this repo's history withoverstated pre-merge evidence, that requirement exists precisely to make the
claim checkable without re-running. Waived here only because I reproduced it
myself from an uncached build; recording the deviation rather than silently
passing it.
TODO.mdline 41 — the new Completed Steps entry ends...instead of two taxonomy URLswith no terminal period, unlike everysibling entry. Cosmetic.
Note on the two removed URLs, judged fine.
https://lora.vegas/categories/and
/tags/were in the live sitemap, but the base build produces noindex.htmlunder either path (that is what the warning was about) — onlycategories/index.xmlandtags/index.xml. Those sitemap entries werealready pointing at 404s, so dropping them is a strict improvement, and the
two empty taxonomy feeds that do disappear on deploy are unlinked from
anywhere on the site. Nothing further needed.
The PR states plainly under "Not verified" that no Cloudflare Pages deploy has
been exercised; that is accurate and correctly scoped to merge time.
PASS accepted.
merge-ready, merging directly —mainis unprotected, so thisdoes not go to @sneak.
Two things from this review worth keeping.
The planted-defect control. The reviewer did not just observe zero
WARNon the branch; it ran the base commit through the identical harness and
confirmed the taxonomy warning does appear there. Without that, "no warnings"
is indistinguishable from a harness that cannot see warnings — which is exactly
the failure mode that has cost this repo a production outage and two rounds of
rework. Doing the negative control unprompted is the standard I want.
busybox diff -runder-reports. Inside alpine it did not printOnly in ...: categoriesfor the removed directories, showing only thesitemap.xmlhunk. The reviewer distrusted it and re-derived file lists andmd5s separately. Anyone verifying similar claims in this repo should not rely
on container-side
diff -rfor added/removed paths.Non-blocking, accepted, not reworked: DoD item 2 asked for the full build
output pasted into the PR and the PR asserts zero
WARNin prose instead. Thereviewer reproduced it from an uncached build, so the claim is sound — but the
deviation is recorded rather than allowed to read as a clean pass. The missing
terminal period in
TODO.mdis cosmetic and not worth forfeiting a reviewedstate.
Judgement call agreed:
/categories/and/tags/leaving the sitemap iscorrect, not a regression. Those entries already pointed at 404s — the absence
of an
index.htmlunder either path is precisely the warning being fixed — andthe two empty feeds that do disappear are unlinked from anywhere on the site.