4 ms·

Can I also use it to write blog posts and generate an RSS feed for them? A lot of documentation sites want this but it was always hard with things like sphinx

Can I also use it to write blog posts and generate an RSS feed for them? A lot of documentation sites want this but it was always hard with things like sphinx where the input must be files on disk so one couldn't e.g. load blog posts from a db.

perpil 11mo ago
Its predecessor (mkdocs material) supported blogs via a plugin and rss feeds via a mkdocs plugin (https://guts.github.io/mkdocs-rss-plugin/ https://guts.github.io/mkdocs-rss-plugin/). I don't believe it supports blogs yet according to this: https://zensical.org/compatibility/#phased-transition-strategy https://zensical.org/compatibility/#phased-transition-strate... but will in the next phase when it supports plugins. It doesn't support loading content from a database that I'm aware of, it uses markdown files on disk as input.
- sureglymop 11mo ago
  Thanks for the information. If files on disk are a requirement that would be a shame. Such tools keep abstracting such that one can generate a plethora of output formats but don't abstract the input in such a way that one could programmatically add content. Even though that wouldn't stand in the way of using the filesystem as the source regardless.
  - kurayashi 11mo ago
    It’s a requirement for now. But once the module system is in its possible to add other data sources.
jarofgreen 11mo ago
> load blog posts from a db Can you explain a bit more about your requirement and how many blog posts you are talking about? I'm curious to hear more for my future work as I have an extendable static site builder it would be easy to add this too. I don't want to be going all marketing on someone else's post (and it's early days so you'd probably find other features lacking) so I'll just say my email is in my profile if you want.
- sureglymop 11mo ago
  Sure! I am coming from sphinx, another python based documentation tool that is used for example for the Linux Kernel docs, Python's docs, etc. While it is great for documentation, we used it for the whole website of a project, mainly because people in the team already understood it. But we ran into many issues when it came to adding a blog... Sphinx has a hard requirement for input files to be on disk. It means that, for example, it would be hard to add a page that lists all blog posts posted in a certain category (as the "meta" page would have to inspect other pages and then be generated on the fly). The only option is to pre-generate such pages into the source folder before a build. I think that the inputs should be abstracted in a way such that there isn't a hard requirement on the filesystem. For example, extensions should be able to add input files using code, without having to write them to the filesystem first. This would make many things much easier and open a new world of possibilities without actually resulting in more maintenance work for the ssg. The thing is that the output is abstracted in that way, one can create a new plugin to write to a different output format. If one could also "generate" input/source files dynamically, one would get support for all of these output formats "for free". As for me personally, I don't really have enough blog posts to have to store them in a db, that was just an example. But if abstracted transparently in the way I am thinking about it actually doesn't matter for the ssg, it only knows about inputs and outputs and not how it got these inputs.

perpil 11mo ago

Its predecessor (mkdocs material) supported blogs via a plugin and rss feeds via a mkdocs plugin (https://guts.github.io/mkdocs-rss-plugin/ https://guts.github.io/mkdocs-rss-plugin/). I don't believe it supports blogs yet according to this: https://zensical.org/compatibility/#phased-transition-strategy https://zensical.org/compatibility/#phased-transition-strate... but will in the next phase when it supports plugins. It doesn't support loading content from a database that I'm aware of, it uses markdown files on disk as input.

sureglymop 11mo ago
Thanks for the information. If files on disk are a requirement that would be a shame. Such tools keep abstracting such that one can generate a plethora of output formats but don't abstract the input in such a way that one could programmatically add content. Even though that wouldn't stand in the way of using the filesystem as the source regardless.
- kurayashi 11mo ago
  It’s a requirement for now. But once the module system is in its possible to add other data sources.

jarofgreen 11mo ago

> load blog posts from a db Can you explain a bit more about your requirement and how many blog posts you are talking about? I'm curious to hear more for my future work as I have an extendable static site builder it would be easy to add this too. I don't want to be going all marketing on someone else's post (and it's early days so you'd probably find other features lacking) so I'll just say my email is in my profile if you want.

sureglymop 11mo ago
Sure! I am coming from sphinx, another python based documentation tool that is used for example for the Linux Kernel docs, Python's docs, etc. While it is great for documentation, we used it for the whole website of a project, mainly because people in the team already understood it. But we ran into many issues when it came to adding a blog... Sphinx has a hard requirement for input files to be on disk. It means that, for example, it would be hard to add a page that lists all blog posts posted in a certain category (as the "meta" page would have to inspect other pages and then be generated on the fly). The only option is to pre-generate such pages into the source folder before a build. I think that the inputs should be abstracted in a way such that there isn't a hard requirement on the filesystem. For example, extensions should be able to add input files using code, without having to write them to the filesystem first. This would make many things much easier and open a new world of possibilities without actually resulting in more maintenance work for the ssg. The thing is that the output is abstracted in that way, one can create a new plugin to write to a different output format. If one could also "generate" input/source files dynamically, one would get support for all of these output formats "for free". As for me personally, I don't really have enough blog posts to have to store them in a db, that was just an example. But if abstracted transparently in the way I am thinking about it actually doesn't matter for the ssg, it only knows about inputs and outputs and not how it got these inputs.