Debugging my templates is impossible with the tools at my disposal.
I have an exceptionally complex template structure that is attempting to output API documentation. This requires model tables with fields which can also be models. In other words, templates are looping over fields and outputting data that can nest many levels.
Debugging with print(f) pollutes the page so terribly that I cannot use it practically. I have tied errorf, but this also outputs to the page, and it appears that it does not output data “in order” - by that, I mean the output seems to include errorf’s from calls to templates before the errorf that should come out before that template call. I believe there is some sort of buffering going on.
What would help tremendously would be a simple “debugf” call that would output to a file, and that output would be flushed at the end of every debugf statement to ensure orderly output.
I handle debugging of such things by using a recursive partial.
I have a theme called hugo-bare-min-theme designed solely for debug and development of Hugo sites. You don’t have to use the whole theme; copying just the debugprint.html partial that I link in that project’s README (and debugprint.css partial) would suffice.
However, these do not solve the problem. Logging to a file is the solution that is needed, and adding a debugf function cannot be terribly difficult. I have lost so many hours of my time to something that could have been debugged in minutes with proper logging.
But in the mean time you can use the errorf function to print information to the command line. If you use the logFileconfiguration variable you can also have that output appear in a file, from what I understand.
Though honestly, it is probably easier simply to keep them on hand in this forum so that people can include and adapt as needed. It would be quite hard to create a template that covers everyone’s needs.
The debugprint.html partial detects a slice/map using a regex, so is not very robust by definition. But it works for all my use cases. So it wouldn’t be a good candidate for an internal template yet … until IsSlice, IsMap get implemented.
There was also a discussion on debug/dump function a while back. Folks interested should chime in their interest or support to make that happen in that issue.
Perhaps add them to the documentation? The problem with keeping them here on the forum is that they’re so easily lost. It depends on people actively remember them. Much like the requesting help thread that Rick put together, but doesn’t get referenced here on the forum enough (in my view).
I totally understand where you’re coming from and I agree. But I also feel comments such as this don’t always help. Not everyone knows Go programming, has the time to learn Go, or has the time to learn the Hugo project and make contributions. We perhaps sometimes forget how hard that is.
I don’t disagree about the issues with keeping things in a forum. However, there is a hints and tips section. The Hugo docs might be a better place perhaps but that would be up to the Hugo devs to comment on I think. I’d be happy to submit my suggestion somewhere if there is agreement on where. I fully expect that I will add more things like this to my knowledgebase. I started that because of similar questions and issues of location in another open source project.
But they do remind people that these forums are not a one-way street. I know that the Hugo devs are busy people - like the rest of us, they probably don’t have time to deal with all requests and desires. I am not a developer but I do try to add value to projects I use whether through input of hints, tips, help, documentation updates and even bits of code if possible. I’m not promoting myself here, just saying that we can all find ways to help. The OPs response came back very aggressively and while this may well be a language issue, it is still frustrating to see such responses when you know that there are people working really hard to make good things.
No aggression was intended, just a statement of fact. If you look specifically at the partial here:
which is working recursively with other partials, as well as the overall layout and data models of this project, which produces the documentation of a API, you can see that trying to debug this logic without any sort of logging ability would be difficult at best. The recursive nature of these partials, combined with Golang’s less than appealing scoping, makes this a difficult thing to code, let alone debug.
If I was not engaged 16 hours a day 7 days a week, I would be more than happy to contribute to the project. My contributions to open source over decades has been substantial. Sadly, at the moment I am burdened with delivering working systems for startup companies and have no time to contribute.