We can specify a path to the source (–source=) but I would like to see the ability to break out the “content” from that so that it can be located somewhere else…content being any .md files, so content folder and archetypes folder and maybe static folder?.
Here is the reasoning. In the big picture (after a hugo site is ready for mass consumption) content is edited by “editors” and templates (e.g. /layouts) are edited by developers. Getting the template stuff out of the purview of editors is in the end best. Then they will have almost zero chance of being confused by or messing with “code” by mistake or on purpose.
I suppose I could use a directory link to do this but then it’s operating system specific, and custom and I am not sure Go will properly use a linked directory.
So I am proposing another CLI switch
–content="path/to/content/directorie(s)"
if it is not present then hugo defaults to the --source switch which of course defaults to the current directory.
It could be broken out as well. In other words just the /content folder and/or the /archetypes folder and/or /static???
I’m been developing a complete static site workflow (using nodejs/gulp) of which Hugo is just one component (the generator). If the all the path settings currently done in the config file were available as options in the commandline (e.g. the content) then one wouldn’t be forced to read/parse/write the config file in order to control these locations. Hugo is great, but as a critical piece of a bigger workflow its config file doesn’t need to control things outside its task.
There are a some really good js based generators that would of course play nicer with a js based workflow (gulp, node) but I really prefer Hugo. Thus my feature request. I’d love to just make a PR but I am concentrating on learning JS.
BTW Once I have this workflow down it won’t be too hard to put a face on it (gui) as some have wanted. Already it’s easy to bake keybindings and menus in sublime to launch any gulp task.
After contemplating this some more I think I will just read in the hugo config file and manipulate as I see fit within my gulp task, write it out and then launch hugo so it doesn’t really matter that I don’t have access to critical config settings from the commandline like various localtions.
Still in the bigger picture if Hugo was to be a binary library access by task managers like gulp it should have all that available in the command line (API).