I noticed my site is generating a bunch of amp directories, which aren’t intended.
I went to check things and I found out these are the culprits:
Table of Contents.adoc.NOT
So it’s basically left-over files, which should just be deleted, but for some reason (intentional or not) were left behind.
These get rendered in
./public/amp/developer/Table of Contents.adoc.NOT
What’s the logic behind assuming these are amp format files? They aren’t.
Apart from the ignoreFiles entry in config.toml which let’s us disable a specific list of file extensions, is there a way of asking Hugo to ignore all unknown extensions? That would be my preferred handling of these cases.
After you read that topic and the Hugo Docs (you may want to look into Output Formats to disable AMP) feel free to open another topic but this time with a more concrete question along with a link to the source code of your Hugo project.
I’m closing this thread because the questions posted are too broad.
Note that I am not asking about disabling the amp format, I am asking why these files are getting recognized as amp format when they aren’t. I don’t think I will find an answer to that in the Documentation. I also read previous posts here about this (there isn’t much).
So for the three files I mention, adoc is not returned by Ext, and GuessType will return unknown for the helper:
(it doesn’t matter that I have tons of valid .adoc files elsewhere in my site, this post is not about those, which are handled just fine).
So, we’re back to my Topic title which is asking about “Handling of unknown file extensions”.
I would like to understand better how this connects to Output formats, since the behavior I’m seeing now doesn’t make sense to me. Note that my main concern here is for Hugo’s consistency; I can just delete these old files and the problem goes away for me. However, if I’m uncovering something fishy here then it’s a good idea to improve Hugo in this regard. Or we could improve the Documentation.
First of all I want to point out that I am not a Go Developer.
Second it seems that an Unknown Output Format can be published by design. For example in lines 181-191 of outputFormat_test.go there is a test for an Unknown Output Format:
In the same file there are other tests for HTML, XML, JSON and AMP.
Why is the Unknown Output Format assumed to be AMP in your case?
I am afraid that I cannot answer your question.
Maybe you should open a bug report on GitHub.
But to be honest this is the first time I’m seeing this type of report in the Forum and I’ve been quite involved here for a while.
Why don’t you simply remove those temp files? Also you can use gitignore to exclude those files.
We all like to optimize our sites, why should the content folder be an exception to this rule?
Also on a friendly note if you do open the GitHub issue please tone down the language a bit, phrases like: “does this logic make any sense?” and “uncovering something fishy” are a bit counter productive.
@alexandros thanks for your good advice, always welcome.
I do moderation myself for a big Community and I recognize you’re doing a good job here, you are always polite even when in disagreement. Keep up the good work (and your excellent drawings!).
I also do a lot of Support and bug reporting work for a very large open-source project and let me tell you my hesitation in taking this to Github… I feel like I need some Forum discussion before opening a bug, because I don’t understand (yet) what the normal behavior is supposed to be.
I need to understand what I’m telling Hugo to do when I put this in my config.toml:
Am I telling Hugo to generate all these outputs for every file (unless I override in the front-matter)? Then why am I not getting any AMP generated for my normal .adoc files?
But if Hugo is doing things right, and AMP is not generated because I would need to add some extra stuff to get that, then why is it being generated for unknown file extensions?
Once I have this answer I feel I can be much more specific with my (eventual) bug report.
Note that some of my bogus files are generated “by accident”, without users being aware of it, like the .save file which probably comes from a text-editor’s auto-save. So people might be thinking they have removed some content from the site, without realizing the .save file is there. They won’t find it as a normal file when they browse the site, but it will be there under some amp directory… this sounds like the sort of behavior that could be improved.