Hi, I'm a new soupault user, and I really enjoy it. It's exactly the tool I need. It's great I can just use an html template without having to first convert it to a special format! After having finished my first website with soupault, I have 2 questions: - if I understand correctly: why are index views limited to index.* pages? I display a tag cloud on the blog's index page, and would have liked to also display it in the margin of blog posts, but it seems the limitation of index usage prevents this. Or is there a way I'm not aware of? - An example of a multi-language website managed with soupault would be great. It's not an immediate need, but this is probably something I'll need in the future. It's not yet clear to me what the best approach would be. Thanks for this great tool!
Hey, >why are index views limited to index.* pages? The practical answer is that you can make index data available to all pages with `index.index_first = true` (see https://soupault.app/reference-manual/#making-index-data-available-to-every-page) Now a longer answer as to why it's not the default... the reason why index data is only available to index pages by default is that I wanted soupault to be able to handle websites that are larger than the available amount of memory. CMSes solve the problem by storing taxonomies and other metadata in a database and querying it dynamically. If all metadata is stored inside pages rather than in a persistent storage with fast queries, you need some compromises. Jekyll et al. choose to mimic a CMS by loading all pages into memory at once and extracting metadata from their front matter, so that templates have access to variables like `site.tags`. But that also means that if you have a website with lots of pages (say, a static copy of Wikipedia), trying to process it on a machine with a modest amount of memory (like a CI worker) will cause the process to run out of memory and crash. Soupault builds a list of all pages first, then sends each of them to a function that reads the page files from disk, extracts metadata, then renders the page and saves the result to disk. The page source and element tree can then be safely garbage collected, so soupault is technically capable of processing sites of arbitrary size (as long as there's enough memory for the page list and for processing at least one page). Only when all content pages are processed and all index data is extracted, then index pages are rendered. But it means that a content page is removed from memory before the complete index data is available. This works well for most sites I think, but indeed doesn't work if you want a tag cloud or similar. So if you do, you can add `index.index_first = true` to the config and get that, at the cost of higher resource consumption. The book blueprint uses that to create a ToC sidebar, for example: https://github.com/PataphysicalSociety/soupault-blueprints-book >An example of a multi-language website managed with soupault would be great. I'm not aware of any examples yet. I have to admit that I'm not a fan of multilingual sites and I believe that in most cases when websites in different languages are actually required and useful, it may be better to just make multiple websites. But I can see how a post-index hook might extract the language from "about.en.md" and set a field, then use it for creating language sections, for example. On 11/1/23 09:47, firstname.lastname@example.org wrote: > Hi, > > I'm a new soupault user, and I really enjoy it. It's exactly the tool > I need. It's great I can just use an html template without having to > first convert it to a special format! > > After having finished my first website with soupault, I have 2 questions: > - if I understand correctly: why are index views limited to index.* > pages? I display a tag cloud on the blog's index page, and would have > liked to also display it in the margin of blog posts, but it seems the > limitation of index usage prevents this. Or is there a way I'm not > aware of? > - An example of a multi-language website managed with soupault would > be great. It's not an immediate need, but this is probably something > I'll need in the future. It's not yet clear to me what the best > approach would be. > > Thanks for this great tool!
Thanks for your detailed answer. I had missed the index_first option in the documentation. Regarding multi-languages sites, I would rather not duplicate data common between languages. I agree there are some languages that would change a lot (eg if a right-to-left language has to be introduced), but in most cases I could reuse the templates, css, lots of images, soupault plugins and helpers. Duplicating all this in a distinct soupault site to make a spanish version in addition to the english version doesn't seem to strike the right balance. Ideally (I think), there would be a general version of the asset (css, template, etc) that can be overriden by a language-specific version, and each language has its version generated under a sub directory (eg build/en, build/es). Just writing this I have some questions arising, so I don't think it's a simple thing to achieve. If I need it and I get something working I'll share it. Cheers