I use the following when starting the hugo server for localhost dev purposes:
hugo server --log --logFile /home/mike/projects/test-site/hugo.log --verbose --verboseLog -
-bind 10.0.2.15 -D --cleanDestinationDir
I was hoping that with verbose logging I’d see all errors and requests being logged in either standard out or the log file. But, I really only see startup and page rebuild logging. Maybe I’m confusing or missing parameters. Thanks.
version info:
Hugo Static Site Generator v0.25.1 linux/amd64 BuildDate: 2017-07-09T23:58:07-07:00
I don’t see the logic in supplying a high performance web server which doesn’t log requests. It’s not really a feature so much as a necessity for keeping tabs on what the server is doing.
Other alternatives like caddy seem to have some configuration overhead to work with hugo
It is a development server for site previews. We’re not adding request logging unless someone can come up with a convincing argument as to why this is relevant for Hugo development/content editing.
You can log yourself using a reverse proxy like Traefik. Alternatively, if you’re not running in production but want to tunnel outside where you can inspect traffic to a Hugo server try Serveo.
However, the docs clearly state that Hugo “comes with a high performance web server”, in fact that is the headline on the website.
Neither the headline nor the docs characterise the server as “content only for editing”.
Now perhaps you could change the docs to be in line with the forum statements or add basic request logging.
Here are some reasons for not using another web server, or other wrapper based solutions:
WYSIWYG. A web server needs to know how to serve content even if it is static.
Using a tool other than “hugo server” will always run the risk of presenting something different than what you see when you edit due to content-type headers and filesystem suffixes and what not.
simplicity. It doesn’t make sense for a user to add caddy or nginx or much of anything significant (eg server traefik) to replace basic request logging. A smaller set of tools has advantages when you only need static content + request logging. If you have basic request logging, then it would become reasonable IMHO in production.
I do not feel that “my architecture” is in need of your evaluation, nor that it is relevant to this discussion. Could we stick to the subject? I did however not get a follow-up on the reasons I gave that Hugo should consider adding request logging to its server.
Also, I think in basic form request logging should be really easy to implement, and it would be less work than everyone who wants it taking the time to work around the lack of request logging in hugo server.
Otherwise, so far I’ve mostly good use of hugo. Great work!
What was a possible response you were expecting? I think you should wait a while, let other folks come in and read, think and discuss your suggestions.
The docs have said that for years and very few people have reported issues with the wording. Please submit edits to that doc at Issues · gohugoio/hugoDocs · GitHub and you can hash out the details for the edit there.
You would think so. But if you add a config flag for it (I don’t want to see that request logging, so you would need some flag), then you also need to document it. Probably also add a test for it. And you would have to answer future questions here on the forum about log format (“Could you pretty please add some colors to the request log?”) and that it shows some odd characters on Windows etc.
In short, we’re not doing it. It does not belong there and it it did, it’s not worth it.
