Feature: save posts in a specific folder fo cleaner output folder

[hollisticated-horse]

describe the feature
As of bearclaw 1.2.0, the blog posts are generated in the output folder, with everything else.

It might be cleaner to have posts in a post folder ? And maybe pregenerate an asset folder, for images and icons ?

[donuts-are-good]

That's a great idea, will implement post folder and assets. Tentatively thinking something like this could be good for the assets folder structure.
./assets/

./assets/js

./assets/css

./assets/img

[donuts-are-good]

Making a note, perhaps it makes sense to add to this issue: explore possibility of --output option so that those running other servers like apache/nginx/caddy can --output "/web/server/path"

[hollisticated-horse]

As an example, my current folder structure is as follows, with 1.2.0alpha:

.
├── markdown
├── output
│   └── assets
│       ├── fonts
│       │   └── martel
│       ├── icons
│       └── img
├── plugins
└── templates

[hollisticated-horse]

And how about --input for a different markdown folder ? For use with different markdown systems (Obsidian, Logseq, ...)

[hollisticated-horse]

To be fair, I quite liked the fact that bearclaw is basic and opinionated. Adding too many features, aka feature creep, would just make bearclaw like a lot of other SSGs.

[donuts-are-good]

To be fair, I quite liked the fact that bearclaw is basic and opinionated. Adding too many features, aka feature creep, would just make bearclaw like a lot of other SSGs.

I can tell we are already friends :) Also, there's no rule saying that if a feature doesn't work out or keep with the theme that we can't chop it out or make it a plugin or something. I'm okay with plugins taking on whatever type of sprawl on their own, but the core product I agree is important to keep simple.

[donuts-are-good]

So far, I see two easily actionable objectives from this issue:

• build folders should be cleaned up and compartmentalized with an assets folder, and a posts folder

• --output --input as optional flags

I have a few last tasks at the office and can prioritize this first for this afternoon's work toward the 1.2.0 release.

[donuts-are-good]

  -input string
        the input folder for markdown files (default "./markdown")
  -output string
        the output folder for html files (default "./output")
  -plugins string
        the plugins folder for plugins (default "./plugins")
  -templates string
        the templates folder for header and footer html files (default "./templates")
        ```

[donuts-are-good]

hmm. working through a bug.

go build && ./bearclaw --output /usr/share/nginx/html
flag provided but not defined: -output
Usage of ./bearclaw:
  -watch
    	watch the current directory for changes

[donuts-are-good]

works now

[static@donutshop bearclaw]$ go build && ./bearclaw --output /usr/share/nginx/html
[static@donutshop bearclaw]$ 

[donuts-are-good]

@hollisticated-horse small note, im jamming through these tickets right now and most of it is going smoothly. one thing comes to mind: feature requests are easiest to code up as single-objective tickets, that way details don't get forgotten or misunderstood, and can be managed easier in terms of deliverability.

I mention it because I was about to close this ticket, but something told me to re-read and I just noticed I forgot the /assets thing :) which I'll do next. wew close call haha

[donuts-are-good]

haha, well this is woops, juuuuust kidding.. so here's what i just realized...

there isn't actually a thing currently that does anything with image files. I think since every image and css file we've used so far is remote content, it never came up. Having thought about it a bit, it was going to get messy fast because of these concerns:

does markdown folder also have assets?
if yes, should the user be expected to use it?
if yes, the user has to type some form of path to insert it in their document and then do we expect them to use the build folder or the markdown folder, or the assets folder in each one of those?
are we now reaching an image during transcoding and then scanning all of those paths for the correct image?

all of this added complexity in ways that I don't expect a user to have to deal with. for that reason, im not going to implement assets/ even though it made sense initially. I'm still open to suggestion, and if someone told me today "hey i have an elegant solution for this, and I'd like to PR it, here's the idea ...." I'd happily hear them out but the way it stands currently, I think this is deviating away from simplicity.

however @hollisticated-horse , all is not lost, there is a quasi-solution currently, in the form of 'dropzone' which is just this little html document i made that lets you drop a png or something onto it, and it loads your clipboard with encoded text that you can then paste into html or whatever (markdown parser we use accepts html incidentally) and it will display as an image

https://github.com/donuts-are-good/dropzone

It's kind of a compromise, but the unavoidable drawback of that strategy is the amount of text required for larger images. The best bet is to just use a remote url in the image link, imo.

It pains me to close this issue, but I think that's the best course of action. Thank you for reading my novel :)

[hollisticated-horse]

@donuts-are-good

I totally agree with you on this. Your initial folder structure is very good:

.
├── markdown
├── output
├── plugins
└── templates

I still think having a posts folder generated in output is a good idea (am not sure from your posts if you implemented it). [Complexity = low]. On the other hand, I might be coming around to the idea of just bunching all posts in the ouput folder with the post.html/index.html

.
├── markdown
├── output
│   └── posts
├── plugins
└── templates

But I can see how the assets folder probably adds unwanted complexity.

With this in mind, the way I current use bearclaw is, I actually do use the default output folder, containing my assets folder. What I then do is I made my output folder into a git repo that pushes to a Git* page service. And in the past I used to rsync output's content to my webserver.
Either way, output is where stuff goes, and then output/* gets moved to where ever I want it to go.
--output then means that it content that was generated, as a folder, is copied to a new location, and not generated there.

Possible solution there.

(Could this become a conversation also ?)

[donuts-are-good]

your wish is my command 🐴 🧞

[donuts-are-good]

ive got to go get fitted for a rental tux here in a bit, but ill be thinking about the ./output/posts thing. i think that shouldn't cause too many problems, but then again hard to say without the code in front of me. also good idea making it a discussion

[donuts-are-good]

Either way, output is where stuff goes, and then output/* gets moved to where ever I want it to go.
--output then means that it content that was generated, as a folder, is copied to a new location, and not generated there.

about this.... i wonder how bearclaw would behave if you put a network path in there as the output folder

so rsync syntax, but on bearclaw: ./bearclaw --output user@host:path/to/www/html

i havent tested this, it's just an assumption that it might work assuming you're able to auth with that network path. i use sshfs for something similar to this locally, where i mount the network path as a local folder via ssh and sshfs similar to what you would have on a 9p system.