4 ms·

> I wouldn't mind some convention-over-configuration there. I strongly agree. I started some of that with my theme https://tildegit.org/southerntofu/zola-water

> I wouldn't mind some convention-over-configuration there. I strongly agree. I started some of that with my theme https://tildegit.org/southerntofu/zola-water https://tildegit.org/southerntofu/zola-water and i'd be pleased to cooperate on "standard" conventions across themes so we can swap themes easily without having to reconfigure/reorganize everything. > But I also want multi-lingual articles and article revisions so maybe Zola is not for me. zola supports translations, though the details of that are being reworked. Revisions are not supported so far, but is technically possible by building your site in a specific output folder for every commit (or something along those lines). Linking across revisions, as it is not supported by zola would require either an external component (eg. in an iframe) or a build script that rewrites output pages to be aware of their revisions. Though implementing a simple git interface to zola to expose commit names involving a specific page would not be hard (managing the different revisions as single pages, like is done for translations, would be more complex). > I think Zola would get much more traction if it had several typical cases covered in the tutorials Agreed. There is definitely a lot to improve on the website/documentation. If you have a more detailed proposal and/or would like to get involved, feel free to talk about it in the community forums https://zola.discourse.group/ https://zola.discourse.group/

pdimitar 6y ago
I do have suggestions and ideas but I feel like the author(s) are too busy and would appreciate code PRs much more. I mean, everyone can just talk and talk, right? > Linking across revisions, as it is not supported by zola would require either an external component (eg. in an iframe) or a build script that rewrites output pages to be aware of their revisions. Ah, I mean something much simpler than that. Imagine having a combo box at the top of the article, named "Versions" (or "Revisions") that has the value of "latest (2020-02-28)" at the top and currently selected and then has all others just as dates below. When you choose one, the page loads another HTML file. Extremely simple vanilla JS, likely 5-10 lines. Or you can just have a limited list (say the last 5 revisions) with direct links -- again before the content starts. Clicking those would not even need any JS at all. It would be a plain old <a href="/blog/whatever-article/rev/2020-01-31.html">2020-01-31</a> markup. And if an article has no revisions (only has been written once) then the needs for such a combo-box or list of links disappears and they should just not be rendered at the article's page at all.
- southerntofu 6y ago
  > I do have suggestions and ideas but I feel like the author(s) are too busy and would appreciate code PRs much more. That is correct, and it would be sad and damaging to believe exhausted volunteer maintainers should satisfy each and every desire of yours. However, stating expectations and desires respectfully is really helpful, especially when it is done in a precise manner so someone with time and energy can try to implement it. > When you choose one, the page loads another HTML file. Well if you're keeping different versions of the Markdown file within your content folder, then it's not a problem. A page can link to its siblings just like you described. But zola, like all SSGs i know, uses a simple folder for content so there is no notion of history of a single file. We usually use a version control system (like git) for that.
  - pdimitar 6y ago
    > That is correct, and it would be sad and damaging to believe exhausted volunteer maintainers should satisfy each and every desire of yours. That's precisely why I am keeping silent. I worked on OSS myself and I don't want to come off as entitled. When I don't find the features that I would like I am mostly just shrugging and thinking to myself "either I'll research Zola's code base and make a good PR about it or I'll just keep my thoughts for myself because everyone can demand their own favorite features and it's not a productive use of the maintainers' time to read people's wishlists". > However, stating expectations and desires respectfully is really helpful, especially when it is done in a precise manner so someone with time and energy can try to implement it. True to an extent but I've been bitten by this in the past. My definition of respectful expectations is somebody's idea of entitlement even if I use language like "please consider this feature if you find yourself with some extra bandwidth in the future" and "I think this would help adoption because I know I am not the only one wanting it" and "this could help with SEO for this or that class of websites". I learned that many OSS maintainers are tired and jaded -- and thus very jumpy as a result. So I just stopped giving suggestions after I have been slapped with "only PRs are welcome, otherwise we are not interested in theoretical discussions" several times in the past. I realize Zola's maintainers might not be like this but there's something else to consider as well: it's mentally very tiring to have to use extremely watered-down diplomatic language (almost to the point of begging) just so you don't get on somebody's bad side if they had a crappy day. I've had people rage at me for saying something as simple as: "feature X would be very helpful for workflow Y, would you consider adding it during the next 6 months?" (I guess the trigger was the implication of a deadline imposed on somebody's hobby work but the reaction was violent enough that I lost my desire to apologize.) And so it goes. > We usually use a version control system (like git) for that. I don't know the specifics but wouldn't that require Zola's Rust code to be aware of the GIT history of the website itself? Sounds like 5 tons of complexity loaded on top of 10kg worth of software, so to speak -- but I might be wrong. I'd personally go for something like this: /articles/ /reasons-to-choose-rust-in-2021/ + 2020-01-31.html + 2020-02-28.html + 2020-03-05.html why-i-left-ruby.html /resume/ + 2019-01-17.html + 2020-03-15.html ^ The above describes only 3 articles, one of each has no revisions (why-i-left-ruby.html), one of them has two revisions (resume) and another has three (reasons-to-choose-rust-in-2021). However, I am just talking out of my a$$ and can't comment if this is easy to integrate or what complexity and repercussions would it have to the otherwise free-form directory/file structure that Zola encourages. I am simply illustrating what I would be after.

pdimitar 6y ago

I do have suggestions and ideas but I feel like the author(s) are too busy and would appreciate code PRs much more. I mean, everyone can just talk and talk, right? > Linking across revisions, as it is not supported by zola would require either an external component (eg. in an iframe) or a build script that rewrites output pages to be aware of their revisions. Ah, I mean something much simpler than that. Imagine having a combo box at the top of the article, named "Versions" (or "Revisions") that has the value of "latest (2020-02-28)" at the top and currently selected and then has all others just as dates below. When you choose one, the page loads another HTML file. Extremely simple vanilla JS, likely 5-10 lines. Or you can just have a limited list (say the last 5 revisions) with direct links -- again before the content starts. Clicking those would not even need any JS at all. It would be a plain old <a href="/blog/whatever-article/rev/2020-01-31.html">2020-01-31</a> markup. And if an article has no revisions (only has been written once) then the needs for such a combo-box or list of links disappears and they should just not be rendered at the article's page at all.

southerntofu 6y ago
> I do have suggestions and ideas but I feel like the author(s) are too busy and would appreciate code PRs much more. That is correct, and it would be sad and damaging to believe exhausted volunteer maintainers should satisfy each and every desire of yours. However, stating expectations and desires respectfully is really helpful, especially when it is done in a precise manner so someone with time and energy can try to implement it. > When you choose one, the page loads another HTML file. Well if you're keeping different versions of the Markdown file within your content folder, then it's not a problem. A page can link to its siblings just like you described. But zola, like all SSGs i know, uses a simple folder for content so there is no notion of history of a single file. We usually use a version control system (like git) for that.
- pdimitar 6y ago
  > That is correct, and it would be sad and damaging to believe exhausted volunteer maintainers should satisfy each and every desire of yours. That's precisely why I am keeping silent. I worked on OSS myself and I don't want to come off as entitled. When I don't find the features that I would like I am mostly just shrugging and thinking to myself "either I'll research Zola's code base and make a good PR about it or I'll just keep my thoughts for myself because everyone can demand their own favorite features and it's not a productive use of the maintainers' time to read people's wishlists". > However, stating expectations and desires respectfully is really helpful, especially when it is done in a precise manner so someone with time and energy can try to implement it. True to an extent but I've been bitten by this in the past. My definition of respectful expectations is somebody's idea of entitlement even if I use language like "please consider this feature if you find yourself with some extra bandwidth in the future" and "I think this would help adoption because I know I am not the only one wanting it" and "this could help with SEO for this or that class of websites". I learned that many OSS maintainers are tired and jaded -- and thus very jumpy as a result. So I just stopped giving suggestions after I have been slapped with "only PRs are welcome, otherwise we are not interested in theoretical discussions" several times in the past. I realize Zola's maintainers might not be like this but there's something else to consider as well: it's mentally very tiring to have to use extremely watered-down diplomatic language (almost to the point of begging) just so you don't get on somebody's bad side if they had a crappy day. I've had people rage at me for saying something as simple as: "feature X would be very helpful for workflow Y, would you consider adding it during the next 6 months?" (I guess the trigger was the implication of a deadline imposed on somebody's hobby work but the reaction was violent enough that I lost my desire to apologize.) And so it goes. > We usually use a version control system (like git) for that. I don't know the specifics but wouldn't that require Zola's Rust code to be aware of the GIT history of the website itself? Sounds like 5 tons of complexity loaded on top of 10kg worth of software, so to speak -- but I might be wrong. I'd personally go for something like this: /articles/ /reasons-to-choose-rust-in-2021/ + 2020-01-31.html + 2020-02-28.html + 2020-03-05.html why-i-left-ruby.html /resume/ + 2019-01-17.html + 2020-03-15.html ^ The above describes only 3 articles, one of each has no revisions (why-i-left-ruby.html), one of them has two revisions (resume) and another has three (reasons-to-choose-rust-in-2021). However, I am just talking out of my a$$ and can't comment if this is easy to integrate or what complexity and repercussions would it have to the otherwise free-form directory/file structure that Zola encourages. I am simply illustrating what I would be after.