As outlined in Jekyll's Collections docs, I've added an additional field to my collections. Here's part of my _config.yml:
collections:
algebra1-2:
title: Algebra 1-2
output: true
How can I access the title field in pages and layouts?
I've tried {{ page.collection.title }} (and a dozen other permutations) with no luck. However, I have found that {{ page.collection }} will render algebra1-2.
Edit: I'm not checking whether or not the page belongs to the collection, and also am trying to avoid conditionals and looping over all pages, as this answer recommends.
I found that this is possible using the following syntax: {{ site.collections[1].<field> }}.
So, given the example above, {{ site.collections[1].title }} will evaluate to Algebra 1-2.
Related
i want to print the value of current item in list(which is a integer) and its successor(not the list item) but the actual integer successor) at the same time..i am using
{% for i in hour %}{{ i }}-{{i+1}}{% endfor %}
but this gives me an error of "Could not parse the remainder: '+1' from 'i+1'"
Try: {{ i }}-{{ i|add:"1" }}
See https://docs.djangoproject.com/en/1.8/ref/templates/builtins/#add
As far as I know there are three approaches:
Change to a different templating language that allows cleaner logic (Mako I believe though my knowledge is out of date)
Install a third party django package that allows you to do math in templates.
Create a template tag that accepts a value (i), does the calculation you want, and returns that value.
#3 is the one I would suggest.
I want something like:
---
my_var: "foo.bar.baz"
---
{{- site.data.header[page.my_var] -}}
Unfortunately, it doesn't work…
I know that I can use site.data.header.foo.bar.bazor site.data.header["foo"]["bar"]["baz"], but it's not that.
Also I know that I can split page.my_var to substrings and use them then as site.data.header["foo"]["bar"]["baz"]. But this increases Jekyll build time.
I guess I need some Ruby plugin, but don't know one and I don't know Ruby to write one.
If you know such plugin or can help me write one or know some native workaround, this would be sooo great!
Help :)
Also I know that I can split page.my_var to substrings and use them then as site.data["foo"]["bar"]["baz"]. But this increases Jekyll build time.
I'm not sure you can do this. And even if you can, I'm not sure that there is a real performance impact.
But you can do this :
_data/foo.yml
bar:
baz: 1
biz: 2
buz: 3
beer:
baz: 1
biz: 2
buz: 3
Then :
---
my_var: "foo.bar.baz"
---
{% assign keys = page.my_var | split: "." %}
{% assign object = site.data %}
{% for key in keys %}
{% assign object = object[key] %}
{% endfor %}
{{ object }}
What are hoping to do has been blocked by design.
site.data["foo.bar.baz"] implies that you need to have a data file named foo.bar.baz.yml or foo.bar.baz.json, ... etc.
But Jekyll sanitizes data files' names and therefore the resulting object would only have a key named "foobarbaz"
A plugin that purposely removes this sanitization can written but it wouldn't appear to be a benign or safe to end-users. So the chances of finding such a plugin in the wild is slim..
I have a nested yaml data file for my jekyll blog like so:
Nickname1:
name: John
address: Johnstreet 1
Nickname2:
name: Rudolf
address: Rudolfstreet 1
I use this to print additional information after each post, which I specify in the front matter. This works fine.
I now wish to create a site that lists all entries of this data file. This should in theory be easy:
{% for nickname in site.data.NAMEOFFILE %}
<li> {{ nickname.address }} </li>
{% endfor %}
However, this does not work because the YAML data is nested. The data has to remain nested, and each entry needs to have a different nickname. The problem with that is of course that I am unable to loop over all entries, because they are all differently named.
Can you folks help me out here? Is there any way in which I can achieve this without changing the nested structure of my data file? Changing the nested structure would break large parts of my site.
Jekyll data files can be set up in two formats: list or dictionary (not the official terminology, but that's what I call them and what helps me understand them).
Lists are used for iteration. Dictionaries are used for looking up an individual item and shouldn't be used in iteration.
// list.yml
- nickname: Nickname1
name: John
address: Johnstreet 1
- nickname: Nickname2
name: Rudolf
address: Rudolfstreet 1
...
// usage
{% for person in site.data.list %}
<li> {{ person.address }} </li>
{% endfor %}
// dictionary.yml
Nickname1:
name: John
address: Johnstreet 1
Nickname2:
name: Rudolf
address: Rudolfstreet 1
...
// usage
{% assign person = site.data.dictionary['Nickname1'] %}
<ul>
<li> {{ person.address }} </li>
</ul>
I have the same data in two different files: one in a list format and one in a dictionary format. That lets me iterate or do specific lookups whenever I need. Drawbacks are that you have duplicated data across two different files and need to maintain consistency whenever you make changes.
To solve your specific problem, I would make another data file with the data formatted into a list so that you can iterate through the data. This means you don't need to change the file with the nested structure and can avoid breaking the site.
Jekyll docs example on 'dictionary' usage
Jekyll docs example on 'list' usage
When you iterate over an object, the iteration variable is a two-element array with the key at index 0 and the value at index 1:
<ul>
{% for nickname in site.data.people -%}
<li>
{{ nickname[0] }}: name {{ nickname[1].name }},
address {{ nickname[1].address }}
</li>
{% endfor %}
</ul>
renders (after whitespace cleanup) as
<ul>
<li>Nickname1: name John, address Johnstreet 1</li>
<li>Nickname2: name Rudolf, address Rudolfstreet 1</li>
</ul>
Weirdly, I can't find this described anywhere in the Liquid docs, neither on the Jekyll site nor in the official documentation. The only reference I've seen is on the platformOS documentation page.
config.yml defines collectio eggs
collections:
eggs:
output: true
A folder _eggs has a document with front matter
I can access the collection label so:
{{ site.collections[0].label }}
which returns "eggs" but not so
{{ site.eggs.label }}
which returns nothing as does this:
{{ site.eggs }}
The documentation about collections at https://jekyllrb.com/docs/collections/#liquid-attributes does not make much sense to me: "The collections are also available under site.collections, with the metadata you specified". In an issue at github the authors say, that the collections field was (silently?) dropped (https://github.com/jekyll/jekyll/issues/4392).
I am currently evaluating Jekyll and this causes doubts where it stable, has up to date docs and has other pitfalls ahead.
Do I misunderstand the docs? Why does the above access to collection metadata not work.
The metadata of each collection is available with site.collections, that means, it will return an array of the collections with its metadata.
If one access a collection directly, like site.eggs, there won't be metadata available, but an array of all the collection files, i.e. all the files in the _eggs folder.
example
To display the contents of site.eggs you can iterate over each file, consider having the following file in /_eggs/item.yml
---
title: "Jekyll is awesome"
---
Then you can display it in /index.yml like:
{% for egg in site.eggs %}
{{egg.title}}
{% endfor %}
Output:
Jekyll is awesome
I'm using SaltStack to manage some VMs. I'm looking for a way to render the ID/hostname of a minion(s) that have a specified .sls attached to them in the top.sls file or a particular state in a jinja template-enabled file. The reason I want to do this is so I can easily refer to a server(s) in a client's configuration without having to hardcode values anywhere at all. For example;
/srv/salt/top.sls:
base:
'desktoppc01':
- generic.dns
'bind9server01':
- generic.dns
- bind9
/srv/salt/generic/dns/init.sls:
/etc/resolv.conf:
file:
- managed
- source: salt://generic/dns/files/resolv.conf
- mode: 644
- template: jinja
And finally,
/srv/salt/generic/dns/files/resolv.conf:
domain {{ pillar['domain_name'] }}
search {{ pillar['domain_name'] }}
nameserver {{ list_minions_with_state['bind9'] }}
What I'm after specifically is an equivalent to {{ list_minions_with_state['bind9'] }} (which I just made up for demonstrations sake). I had assumed it would be something that would be pretty commonly needed, but after scouring the modules page I haven't found anything yet.
At the moment I have the client get information from a pillar, but this has to be manually configured which doesn't feel like time well spent.
I'm hoping I could expand this idea with a for loop so that servers are dynamically added as they're created.
edit:
With a file with the same data & hierarchy as a top.sls, rendering
base:
{% for server_id in salt['pillar.get']('servers') %}
'{{ server_id }}':
{% for states in salt['pillar.get']('servers:{{ server_id }}') %}
- {{ states }}
{% endfor %}
{% endfor %}
gives you
base:
'desktoppc01':
'bind9server01':
I tried a few variations on {{ server_id }} but was unsuccessful. Unless there's an easy way to use pillar variables in that function, I'm thinking of making a feature request and calling it a day.
The way I think around this problem is to use jinja and have a variable that contain the list of dns server... populated by a pillar variable
for instance you could have a pillar:bind:servers variable
see http://docs.saltstack.com/en/latest/topics/tutorials/states_pt3.html
and http://docs.saltstack.com/en/latest/topics/pillar/index.html#master-config-in-pillar
that can be used to both setup the nameserver of resolv.conf.. but also to add the - bind9 state to the servers.
so in the end you have just one place to edit: the list of minion that are bind server in pillar
The first thing that comes to mind would be using the test-state methodology by setting test=True for state.apply or state.highstate. If there were zero states to apply then your server would have your highstate or specific sls fully applied.
salt '*' state.highstate test=True
Using salt-run's survey.diff could be helpful (although the diff patch doesn't lend itself well to this scenario as much as examining config files):
salt-run survey.diff '*' state.apply my.state test=True
While not currently applicable to your question based on your examples another method that comes to mind would be to use salt grains within your states. When you have your states applied to the systems the state would append to the "states" grain. Grains track things like roles (eg. web, database, etc.) in your case grains could track states as more of a what was applied, instead of a what should be logic of roles. Then you can use them to target and/or query your servers.
Targeting by Grain (show only minion id's) :
salt -G 'states:bind9' test.ping
salt -G 'states:generic.dns' test.ping
salt -G 'states:my_jinja_state' test.ping
Querying Grains (for each minion show me the states grain):
salt '*' grains.get states
Diffing of Grains (compare each minions states grain):
salt-run survey.diff '*' grains.get states