The theme that I’m using had a buggy RSS template that didn’t even render valid XML (for some content). But Hugo happily rendered broken XML and didn’t exit with an error. Because of that, I’ve only randomly noticed the issue later. I think that Hugo should be more helpful. Hugo should validate expanded templates according to the output type.
Originally proposed and discussed (a little) in " in a summary breaks RSS feeds on Hugo 0.132.0+
Now, continuing from the comments in the original thread:
I understand that that’s a tradeoff. More confidence for the users, more work for Hugo and its maintainers.
It may not be reasonable to validate every format under the sun. Or to ship a full-blown linter. But it may be reasonable to do very basic validation for a few “blessed” formats that are easy to validate in the context of Hugo. E.g., Hugo may already have an XML parser dependency somewhere, but not a CSS parser.
If the Hugo team is absolutely against this extra maintainance burden (which would be understandable), then at least we should officially document a setup for integrating third-party validation tools. I assume that most users would want to have this validation by default.
Hugo comes with a powerful templating system. You can customize the XML or RSS output to fit your exact needs—why not tweak it yourself?
You seem to misunderstand my request. I did eventually tweak the RSS template to fix the output. The problem is:
So, don’t say: “you should test your templates, duh”. It was tested! The old/test content just didn’t trigger that specific issue. I want automated validation every time I render my real content. Computers can do that! Come on.
If Hugo will never do that (understandable), then we at least should document a recommended “external” setup for doing that.
Yeah, that one.
Build and deployment workflows vary greatly, from automated CI/CD pipelines to manual processes involving local builds and uploads. Users also employ diverse operating systems like macOS, Windows, and various Linux distributions.
Given these variations, there’s no single “recommended” setup. For instance, if you’re building and deploying with GitHub Pages, here’s an example workflow for a monolingual site:
https://github.com/jmooring/hosting-github-pages/blob/main/.github/workflows/hugo.yaml
Note that the “validate” job in this example is generic, applicable to any website, similar to how CSS, HTML, and JavaScript are universally applicable.
While we won’t officially document this, feel free to share your insights in a blog post or a forum topic.
I would guess the repo could be open to pull requests that aim to contribute some kind of basic pass of “warning: built file X.[html|xml] does not appear to be a properly closed HTML/XML”.
As others said we could just put this into our own build pipelines (a ~5 minute exercise via codebot assistance?)
But as far as being the highest reputed, most appreciated, safest site builder possible, the O.P. could have a point there.
The “crap in, crap out” struggle is real for us all
Now we’re talking! Thank you, that’s better than nothing. I knew that there must be an example somewhere. I’ll look into this.
I use a variation of the same Github workflow, copied from the official deploy docs. But that version doesn’t have the “validate” job. When I have time, I’ll look into contributing to the docs and making sure that everything is in sync.
I’m still not convinced that we can’t have a single “recommended” setup that’s largely shared. After all, Hugo itself is a good counter-example. It’s a static binary that’s easy to run on any desktop OS, and behaves roughly the same on each (doesn’t it?). And even Linux-only, non-static tools can be wrapped in a portable Docker container.
I can imagine a “recommended” shell script. It would assume that some static-validator tool (or Docker) is already installed, then set all the flags and run the tool (or Docker with the tool inside).
This script could be used both locally (after installing the tool manually), and in CI (with a short workflow that installs the tool and then just runs the script). I’d want to have both. I’m not sure if it’s possible to make hugo server call this script on every rebuild (that would be the best for quick iteration), but a local pre-commit hook is already better than having to push to the server and check the CI logs. And that, in turn, is better than no validation!
feel free to share your insights in a blog post or a forum topic.
Yeah, I’m going to do that in the end. I’m already working on a draft.
Thanks for that link. It led me to install the vnu validator locally. However, it appears that vnu relies on the W3C HTML and CSS validators available online. And those are, unfortunately, lagging on HTML and CSS features:
popover*@layer at-rulesSo, vnu potentially flags correct statements as error. In the case of nested rules, quite a few of them.
That’s an unfortunate choice of words.
I created this example yesterday in response to your inquiry.
Please don’t. We are not adding a validation step to the example workflow.
Sorry, I didn’t mean any disrespect or implied obligation. Thank you for your help.
I meant that it’s good to find an existing validation example that I can iterate on! Initially, I was very surprised about having “nothing”. That’s why I made a point about that. I was unable to find anything relevant when googling the topic of validating Hugo outputs. It feels like a very common need, something that most users would want… but apparently it isn’t? Don’t other people make similar subtle mistakes when working with templates?
I’ll probably find some third-party examples if I manually go through the biggest sites that use Hugo. But I kept that as the last resort and thought that asking here first would be easier, more fruitful, and benefitial to everybody (as a thread that can be googled later).
Oh. Sorry, I didn’t mean to sound insistent. I’ve missed that part in your previous comment:
I still don’t understand the basis of your reasoning here. Is it that Hugo shoudn’t be concerned with validation (even in the docs!), because Hugo is a “pure” templating tool?
But it’s a rich, domain-specific tool for building websites! It has hugo deploy. It has hugo import. It has an embedded Sass transpiler. It has embedded integration with analytics providers, comment widget providers, and so on. It officially references a plethora of third-party development tools, from editor plugins to graphical CMSes.
Why are you against documenting validation specifically?
I’m not saying that there can’t be a reason for that. I just don’t see it yet, and I want to understand it.
As I think about it, I probably made a mistake by querying Hugo-specific info. Any tool for validating static websites would do. I’ll search for these and come back with results later.
I still think that referencing these general third-party tools in the official documentation would be a good idea.
I’ve mentioned this before, and it’s crucial to understand: the validation tool you’re looking for is a general-purpose website tool, not something tied to Hugo. It’s applicable to any website, just like tools such as Screaming Frog SEO Spider.
To reiterate: