Following on from Handling improperly formed external links, I’m trying to think through the best way to handle the large quantity of broken internal anchor links my site has. They’ll be fixed eventually, but like in the previous thread, I’d like to find a good way to keep making progress on templates, etc, while the anchor links are fixed by Someone Who Is Not Me.
Since skip_anchor_prefix only applies to external links, there’s no way to get Zola to build a site that contains broken internal anchor links. #1716 helped a lot, but there are still 605 anchor links that are actually, truly broken. Currently, I’m working with a custom build of Zola with internal anchor link checking simply commented out, but that’s not really sustainable. I’d love to find a way to have Zola build a site, despite broken anchor links.
Emit warnings from the link checker instead of panicking or otherwise erroring out of the build. Or allow either, but make it configurable. [link_checker] strict = true could trigger errors, and [link_checker] strict = false could trigger warnings, perhaps.
Apply skip_prefixes and skip_anchor_prefixes to internal links as well (the prefix "" would disable all link checking, external and internal)
I think I like #1 better since it doesn’t change existing behavior (strict could default to true), it’s more explicit than #2, and it doesn’t hide broken links like #2 would, it simply allows them to be treated as acceptable.
I like #1 as well if it’s configurable with strict = true by default to match the current behaviour as you say. The only issue is that it does sound like it would work on internal links as well from the name. Maybe internal_strictness and external_strictness? Or whatever sounds better I’m not inspired. This way we can have different strictness levels, eg for my sites I can potentially be ok with dead external links (in practice I’ll fix it but it’s not that bad) but I do not want broken internal links ever.
I have a branch with the behavior complete, but the warnings feel really lackluster without colorization. I see there’s some nice colorization helpers in src/console.rs but I can’t import that from the other crates in the workspace.
I started crating console.rs, but console has a dependency on Site, and the Site crate needs console colorization. Cyclic dependency.
Inside console, I see two types of functions: output colorization (warn, etc), and content-aware logging (notify_site_size, warn_about_ignored_pages, etc). Only the latter have a dependency on Site.
If I make one crate for colorizing log output, and another crate for content-aware logging, that should eliminate the cyclic dependency. Thoughts on that?
We could move forward without colorization, but it is pretty hard to read the warnings without highlighting them in warning colors.
