Skip to content

Templates: convert to a real base template (baseof.html) - #695

Open
cwhite911 wants to merge 4 commits into
hugo-deprecationsfrom
baseof-conversion
Open

cwhite911 wants to merge 4 commits into
hugo-deprecationsfrom
baseof-conversion

Conversation

@cwhite911

@cwhite911 cwhite911 commented Aug 4, 2026 •

Copy link
Copy Markdown
Contributor

Converts the theme to a real base template. baseof.html now owns the document scaffolding (doctype, head, body, header block, <main> landmark, footer, scripts); all 38 page templates become define "header"/define "main" blocks, head.html is split into head/{meta,assets,favicons,analytics} partials, and the three colliding global define "menu" templates become sidebar partials (sidebar-menu.html, shared by the default and contribute layouts, and sidebar-menu-download.html).

Verified on Hugo 0.113 (compose production build): every page changes only by the new <main id="content"> landmark, apart from deliberate fixes visible in the diff: roadmap's stray closing tags after the footer, theme's unclosed fixed-top div, and the stray </li></ul> after the sponsors sidebar. On main the download template won the menu collision, so the contribute layout's own menu code never ran. That code was broken, so the contribute layout now uses the shared partial, which renders the same sidebar production does. A with .File scoping bug that hard-errors on current Hugo is fixed (RelPermalink comparisons). Hugo 0.167 builds the converted site once the remaining upgrade changes listed on #694 are applied.

Stacked on #694 (stack #696); reviewers see only this layer's commits.

@cwhite911 cwhite911 changed the title baseof conversion Templates: convert to a real base template (baseof.html) Aug 4, 2026
@cwhite911 cwhite911 self-assigned this Aug 4, 2026
@cwhite911
cwhite911 requested a review from wenzeslaus August 31, 2026 21:13
@cwhite911
cwhite911 marked this pull request as ready for review September 4, 2026 18:10
@cwhite911

Copy link
Copy Markdown
Contributor Author

Does anyone have time to review this PR stack? They are blockers for moving forward with the Hugo upgrade.

@echoix

echoix commented Oct 10, 2026

Copy link
Copy Markdown
Member

This second PR doesn't seem ready. #694 is more ready to merge than this one.

From PR #694:
image

And from PR #695:
image

Details

PR 695 stacks on 694, adding a real base template, converting page templates to it, and fixing sidebar-menu File scoping — as a pure refactor, it should render identically to 694. I'll build it on Hugo 0.113.0 and 0.144.2 and compare outputs against both 694 and main.

The 0.113 failure is my own mistake: --logLevel doesn't exist in that version. I'll rerun without it.

Many pages differ for a refactor that should be output-neutral. I'll aggregate the changed lines to see what actually changed.

Besides the new <main id=content> wrapper, I noticed sidebar markup changes, an icon class switch from fa-contribute to fa-user, and a page missing </body> and </html> in line 695. I'll locate where each of these occurs.

The sidebar changes are all on the contribute pages (one page has about 200 sponsor items), and the roadmap page needs a closer look. I'll examine the roadmap and sponsors pages directly.

Both 694 and main leave a stray </section></section></body></html> at the end of the roadmap page, while 695 fixes that markup. Next I'll check the contribute/sponsors sidebar changes.

I noticed the sponsors page sidebar in 695 nests progressively deeper with a list-style staircase, unlike 694's flat rendering—likely a regression. I'll check the new templates and the full rendered sidebar to confirm.

I traced the staircase markup to the <li style="list-style: none"> pattern in sidebar-menu-contribute.html. Now I'll check 694's contribute.html and the sponsors page layout to see if 695 copied this or changed the rendering template.

I noticed a mismatch: the sponsors page shows fa-contribute/<ul class=sub-menu>, while 694's contribute.html defines fa-user/<div> — likely a collision since Hugo's {{define "menu"}} names are global. I'll check which definition actually wins on main vs. 694.

fa-contribute isn't in any template, so it must come from content or data. I'll find the source, and look at the full sidebar on 694 vs 695 side by side.

The 694 fa-contribute icon must be built dynamically, so I'll find that template. It decides which "menu" definition the contribute pages were actually using on main.

Found that download/single.html and _default/single.html were both defining "menu", with the download version winning globally — so contribute pages were actually rendering the download sidebar, not their own. PR 695 fixes this by splitting menus into per-section partials, which changes how /contribute/sponsors/ renders, so I'll screenshot both 694 and 695 to compare.

On 695 the sidebar box has height 0 and the <ul> nesting is 179 deep, against height 129 and depth 1 on 694. Here are the screenshots.

I've confirmed the contribute sidebar regression in 695 (works on 694, shows empty grey box on 695). Next I'll check the 0.144.2 diff, test whether the <main> wrapper affects CSS, and try a time-boxed build on current Hugo since that's what the commit targets.

Two details remain: _base.scss has a main { … } rule that the new wrapper will now match, and about/theme has an extra </div>. I'll look at both.

The main { display: block; } rule is harmless. The extra </div> on about/theme sits right before the new <main>, so I'll check its context.

I'll spend a bit of time building against current Hugo 0.167, since that commit targets it, using scratch copies with the two content-level blockers worked around so main's pre-existing failures don't mask the template results.

An empty allowContent whitelists nothing, so I'll use a permissive pattern.

Both branches build on Hugo 0.167 with those workarounds and print the same deprecation warnings. I'll diff 695 against 694 there and check whether the sidebar problem persists.

The sponsors regression shows up identically on Hugo 0.167. I'll stop the local servers and send both screenshots.

Verification: #695 (stacked on #694): real base template and templates converted to it

Verdict: FAIL for 695. 694 still stands as a PASS.

Claim: 695 introduces a real baseof.html, converts every page template to it, splits head, footer and sidebar into partials, and fixes sidebar File scoping for current Hugo. It is a refactor, so the rendered site should match 694's, apart from deliberate changes. 695's head contains 694's head, plus 4 commits, 50 files.

Method: I built 695 with Hugo 0.113.0 (production's version), 0.144.2 and 0.167.0, and diffed the generated HTML against the 694 build. For 0.167 I used scratch copies with two content-level workarounds, because both branches otherwise fail there for reasons unrelated to either PR (_build front matter, text/html content policy). I then drove the changed page in Chromium.

Steps

  1. ✅ 695 builds with exit 0 on 0.113.0 and 0.144.2, and on 0.167.0 with the workarounds. The page count is unchanged.
  2. ✅ The 0.113.0 diff, 695 vs 694, covers 226 HTML files. Every one gains a single <main id=content>…</main> wrapper. The main { display: block } rule is harmless and nothing else targets main.
  3. ❌ On /contribute/sponsors/, the sidebar goes from a working list to an empty box.
    • 694: ul nesting depth 1, sidebar height 129px, and the links "Contribute → Sponsoring / Development / Sponsors" are visible.
    • 695: nesting depth 179, sidebar height 0px, nothing visible. There are 218 links in the DOM, all collapsed. Screenshots sent.
    • Same result on 0.113.0, 0.144.2 and 0.167.0.
  4. ✅ /about/roadmap/: 694 and main emit a stray </section></section></body></html> after the real end of the document. 695 removes it, so that's a markup fix.
  5. ✅ /about/theme/: 694 leaves <div class=fixed-top> unclosed. 695 balances it.
  6. ✅ News pages: 694's fa fa-latest news icon class (3 pages on 0.144.2 and 0.167) is gone in 695.
  7. 🔍 I looked for other sidebar changes. Apart from the <main> wrapper and the fixes above, /contribute/sponsors/ is the only page whose rendered output changed, so the regression is contained to that one page.

Root cause of the sponsors regression

{{define "menu"}} names are global in Hugo. _default/single.html, download/single.html and contribute/contribute.html all define "menu", and on main and 694 the download definition wins. The contribute page has therefore always rendered the download-style sidebar (<ul class=sub-menu> and fa-{{lower .Title}}, which is where fa-contribute comes from). The contribute layout's own menu code never actually ran.

695 splits that code into partials/sidebar-menu-contribute.html, so the contribute template's own markup executes for the first time. That code is broken. It emits <li style="list-style: none"> and <ul> wrappers without closing them, and contribute.html has stray </li></ul> tags after </nav>. For about 180 sidebar items that becomes 179 nested <ul> levels, and the sidebar collapses.

Findings

  • ⚠️ Fix for 695: make contribute/contribute.html use the generic sidebar-menu.html partial. It already matches what production renders today. Failing that, delete sidebar-menu-contribute.html and its stray </li></ul>. Only the sponsors page is affected, because it's the only content file with layout: contribute.
  • ⚠️ This is also a lesson for the rest of the refactor. The conversion un-masks latent bugs wherever a layout's own define was previously shadowed by another. Only the contribute layout showed visible fallout in my diff, but a pixel diff across sections would be worth running before merge.
  • The remaining deprecation warnings are the same on both branches under 0.167: .Site.Data, .Site.LanguageCode, and the languageCode/languageName config keys. Neither PR addresses them.
  • The 0.113.0 vs 0.144.2 page-path differences under news/cerl1996/ are Hugo-version effects and are identical on main, 694 and 695.
  • I could not confirm the "File scoping for current Hugo" fix independently. It builds cleanly on 0.167 either way, and I saw no .File-related output differences beyond those above.

Are both together correct? 694 is correct on its own. Stacked, they are not correct as-is: 695 breaks the sidebar on /contribute/sponsors/, and the rest of 695's changes are fine. Everything else in 695 looks correct. Merging 694 first is safe, and 695 should be fixed before it follows.

@cwhite911

Copy link
Copy Markdown
Contributor Author

This second PR doesn't seem ready. #694 is more ready to merge than this one.

The contribute layout now uses the shared sidebar-menu.html partial, and the broken sidebar-menu-contribute.html is gone. menu was the only define name used by more than one template, so no other layout was hidden the same way.

Details

Fix. a6c0853 points contribute/contribute.html at sidebar-menu.html, deletes sidebar-menu-contribute.html, and removes the stray </li></ul> after </nav>. ce758f3 merges the root-relative script commit from #694 into the split partials.

Checks, all on Hugo 0.113:

  1. The sponsors sidebar has the same 218 links in the same order as production, and its tags balance (7 of 7 ul, 218 of 218 li). The only change is the empty <i class="fa fa-contribute">, which has no CSS behind it. Without it the "Contribute" heading sits about 4 px further left.
  2. The output diff between Templates: replace deprecated Hugo APIs, drop Babel, prune config #694 and Templates: convert to a real base template (baseof.html) #695 is the same as before the fix, with the <main id=content> wrapper on every page and the roadmap, theme, and news icon fixes. Sponsors no longer changes.
  3. I added a structural check over every page that counts stray end tags, unclosed tags, and the deepest ul nesting. The pre-fix Templates: convert to a real base template (baseof.html) #695 fails it on sponsors (depth 1 to 177). The fixed Templates: convert to a real base template (baseof.html) #695 is no worse than Templates: replace deprecated Hugo APIs, drop Babel, prune config #694 on any page, the deepest nesting on the site is 3, and roadmap and sponsors improve.
  4. I took full-page screenshots of one page per layout (36 pages at 1280 and 400 px) on main and on Templates: convert to a real base template (baseof.html) #695. They show no pixel changes apart from the home carousel landing on a different slide.

The same 36 pages on Hugo 0.167 are covered in my comment on #694. The problems there come from the version bump, not this PR.

baseof.html now owns the document scaffolding (doctype, head, body,
header block, main landmark, footer, scripts) through new head/*,
page-header, site-footer, and scripts partials. Pages define header
and main blocks. single.html's colliding define menu / define
pagination become the sidebar-menu and prev-next partials.
Output change is limited to the new <main id=content> landmark.
Mechanical conversion of 34 templates: the repeated header stanza
becomes page-header options (or a header block override for the pages
whose banner sits outside the header), bodies wrap in define main, and
head.html is deleted. download and contribute sidebars move to their
own partials, ending the parse-order collision between three global
define menu templates. Side effects, all verified in the output diff:
contribute-layout pages render their own sidebar variant again,
roadmap's stray closing tags after the footer are gone, and theme's
unclosed fixed-top div is closed.
The tree item rendered inside unclosed 'with .File' blocks, so
.IsAncestor executed against the File object; old Hugo shimmed that,
current Hugo errors. Close the scopes and compare RelPermalink.
0.113 output is unchanged.
The contribute layout's own menu markup never rendered on main: three templates defined a global "menu" and the download one won. Moving it into a partial made it run, and its unbalanced <ul>/<li> wrappers collapsed the /contribute/sponsors/ sidebar. Render the shared sidebar-menu.html instead, which matches production, and drop the stray </li></ul> after </nav>.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants