touch each file that includes an "ENV" in it, but that's kinda weird
@DivineDominion Are you using the ENV variable directly in code? (e.g. <%= ENV['SOMETHING'] %>) That’ll not work because Nanoc does not track changes to ENV.
What you can do, is copy stuff from ENV to @config in the preprocessor, and then only use the stuff that you copied to @config.
https://github.com/nanoc/nanoc.ws/blob/main/Rules#L5-L11
ENV some 6 years ago because I found no other way. The environment stuff looks way better than what I have, though!
atom_feed(articles: @items.find_all('/blog2/*')
<%= atom_feed :limit => 50,
:articles => sorted_posts_by("sascha"),
:title => "Zettelkasten Posts by Sascha",
:author_name => "Sascha Fast",
:author_uri => "http://zettelkasten.de/authors/sascha/" %>
Hi, and first of all a big thank you to the Nanoc developers! I’ve been looking for an extensible static site generator and so far Nanoc seems to fit the bill perfectly: it’s quite bare-bones on the surface but the provided mechanisms for rules, helpers etc seem to be very powerful.
As I’m working on some features for our own workflow, I thought I’d bring them up here to see if anyone has any experience doing similar things, before I go on reinventing the wheel.
First, we’d like to have something like “page bundles” in Hugo where a page is based on a directory rather than a single file. So, for example, in a blog context, the main file for a post may be
content/posts/my-post/index.md, resulting in a URL of/posts/my-post. In addition, it should be easy to refer to assets in that particular directory from the layout for the post. I did get something like this up-and-running already, just curious as to whether anyone else has done the same thing and come across any dos and don’ts?Other static site generators provide mechanisms for managing URLs, for example in the case where your site runs in a subdirectory (like
/blog/) in production, but you’d like to link to assets without the/blog/prefix internally. Does Nanoc have something built-in for managing this?We often store so-called content in Markdown front matter: things like an intro or an excerpt for a blog post. It could be argued that these belong in separate Markdown files, but having them in the same file is convenient when it comes to editing. To that end, I’m wondering if it’s possible to run the front matter attributes for items through Markdown? Actually, considering that these attributes may include things like image tags and considering the subdirectory URL situation mentioned above, it would be great to even have ERB in the front matter, but this sounds like it might get complicated if you refer to item attributes from item attributes… Is there a better way to go about this?
Appreciate any input! Thank you!
Hey @klumme! I’ll give a brief answer to your points and we can go into more detail if you need it:
Nanoc doesn’t have the concept of page bundles, but it’s also quite flexible in where you put your stuff. I usually put assets (images and videos) in the directory that corresponds to the page, because it makes it easier to find things and this way I don’t end up with a giant assets or images directory.
For sites that run in subdirectories, there is the relativize_paths filter (https://nanoc.ws/doc/reference/filters/#relativize_paths). This way, Nanoc can pretend everything is an absolute path, and then afterwards make all the paths relative.
You could use the filtering helper (https://nanoc.ws/doc/reference/helpers/#filtering) and do something like
<% filter :kramdown do %><%= item[:excerpt] %><% end %>.
@items.detect {|item| item.path == <url>} is no problem. However, it would be useful for the helper to establish a block inside which @item is reassigned to the page we just looked up, instead of the rendered one — that way, other helpers and partials can be used in the same way both inside such a block and outside it, always referring to @item. Given that this may be trivial, as I’m not yet that familiar with Ruby: is there a nice way to accomplish this in Nanoc?
<%= render 'head', :title => 'Foo' %> will be relevant to you, as it shows you how to pass in variables to render
One more thing — I recommend finding items using @items['/blog/2020/something.*'] rather than checking the path. It’s more idiomatic and also faster.
It uses identifiers rather than paths, so the example above would match a file at content/blog/2020/something.md, regardless of where that file is written to in the Rules file.
@ddfreyne: Thanks again! I don't want to have to rely on the rendering helper as I may want to temporarily reassign @item without rendering a partial, but I should be able to look at the rendering helper source code and do something similar with the assigns.
Regarding the @items lookup: yeah, that makes sense... as it's clearly covered in the docs I wonder if I had some particular reason to do it differently, but can't recall... that should work fine!
@DivineDominion: I think that's similar, the main thing for me is to be able to specify a certain post/posts and have @item refer to that other post temporarily, instead of the one currently being rendered. This would, I guess, happen in your case when rendering your /page — fetching the 10 blog posts and rendering them in turn. For that, it's probably enough to use the rendering helper, passing in different items? It's possible that will cover it for me as well, though I'm not sure.
However, I was probably over-complicating things massively — a helper along these lines seems to work fine:
def with_item(id, &block)
orig_item = @item
@item = @items[id]
yield
@item = orig_item
endAs I'm new to Ruby, I wasn't sure I could just reassign the instance variable @item without it creating problems elsewhere... which it might still do, but it appears to be working!
_post.erb.html template that doesn't use @item but a post variable. Then I include this partial from 2 places: the overview page, where I fetch the 10 posts and pass them in as a parameter to the template, and the post detail page, where I pass in render 'post', post: @item
@item so I can use it anywhere, if that makes sense. (Supplying the item as an argument to the helper function would also work, I guess.)
@item and you cannot figure out where it is used. You'd have to pass in the "hosting" path as a parameter in that case, whereas my existing stuff would be the other way around: @item would tell if I'm on the landing page or some archive page or whatever, while the render helper parameter contains the data to be renderes. -- Apart from that, a simple search and replace makes our approaches totally interchangeable, it seems. If it works, don't change it, I guess :)
@item reassignment trick could be helpful to save a parameter in some lib/helpers.rb code, where I have to pass in the post parameter while you can just work with the @item context variable.
ensure right before the @item = orig_item but it probably doesn’t matter
@DivineDominion: Yeah, I think I see what you mean. Hugo has a nice version of this where . is originally the page being rendered, but as you reassign that, for example using the with statement, you still have access to the original context using $... though you'd still have to keep track of which of the variables you're using. Whichever drawback is preferable depends on the structure of your sites, I guess 🙂.
@ddfreyne: Nice to hear that it shouldn't cause problems!