bug: website was set up new and rendered, now website validation shows URLs that don't go away on apply #35

New Issue

hugo · 2026-07-17T15:48:55Z

hugo commented

2026-07-17 15:48:55 +00:00

I had to re-init my blog from git and then had to re-render it, now when I use website validation, I get 338 posts shown as missing but clicking apply doesn't change that fact - they still are missing. check what is going on in the app. the blog is "rfc1437" and it is in the default database for the dev runner.

hugo added the bug ctritical labels 2026-07-17 15:48:55 +00:00

hugo referenced this issue from a commit

2026-07-17 20:12:25 +00:00

fix: issue #35 validation expected unrendered .lang translation variant routes; main-language lists now render main-language translations

hugo commented

2026-07-17 20:12:36 +00:00

Root cause: nothing was wrong in the caching database or the rendered files. Website validation built its expected-URL list from translation route variants (/yyyy/mm/dd/slug.lang) that no part of the renderer ever produces. The blog has 334 posts whose original is English/French/Spanish with a German (= main language) translation restored from git; the variant suppression only dropped additional-language variants, so these .de variants stayed in the expected set as permanently 'missing' URLs. Apply could not fix them because there is no post with slug like 'p60.de' to render - it only re-rendered archives, leaving the count unchanged. The German translations were already correctly rendered at the canonical URLs.

Fix (23f05b7): removed the translation route-variant machinery entirely; sitemap and validation now build expected routes from published posts only, matching the MultiLanguageRoutes spec. Regression test reproduces the exact scenario (de-main blog, en post, de translation) and asserts clean validation plus correct rendering of both language versions. As a bonus, main-language list pages/archives/feeds now show the main-language translation of foreign-language posts instead of the original title (new LanguageVariantSelection spec invariant).

No repair tool is needed: the validation report is computed fresh on each run, so re-running website validation makes the 338 phantom entries disappear. Verified: full suite (1491 tests), credo, deps.audit, dialyzer all clean.

Root cause: nothing was wrong in the caching database or the rendered files. Website validation built its expected-URL list from translation route variants (/yyyy/mm/dd/slug.lang) that no part of the renderer ever produces. The blog has 334 posts whose original is English/French/Spanish with a German (= main language) translation restored from git; the variant suppression only dropped additional-language variants, so these .de variants stayed in the expected set as permanently 'missing' URLs. Apply could not fix them because there is no post with slug like 'p60.de' to render - it only re-rendered archives, leaving the count unchanged. The German translations were already correctly rendered at the canonical URLs. Fix (23f05b7): removed the translation route-variant machinery entirely; sitemap and validation now build expected routes from published posts only, matching the MultiLanguageRoutes spec. Regression test reproduces the exact scenario (de-main blog, en post, de translation) and asserts clean validation plus correct rendering of both language versions. As a bonus, main-language list pages/archives/feeds now show the main-language translation of foreign-language posts instead of the original title (new LanguageVariantSelection spec invariant). No repair tool is needed: the validation report is computed fresh on each run, so re-running website validation makes the 338 phantom entries disappear. Verified: full suite (1491 tests), credo, deps.audit, dialyzer all clean.

hugo closed this issue

2026-07-17 20:12:41 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: hugo/bDS2#35