_config.yml variables from asciidoctor.attributes can't also be used as 'site.asciidoctor.attributes.foo' in jekyll templates

[hossman]

The jekyll docs note that...

All the variables set via the command line and your _config.yml are available through the site variable. For example, if you have url: http://mysite.com in your configuration file, then in your Posts and Pages it will be stored in site.url

...and nested structures such as this onebelow work fine and allow for variables like {{ site.my_stuff.attributes.foo }} in liquid templates to be resolved to bar...

my_stuff:
  attributes:
    foo: "bar"

However, something about the way the jekyll-asciidoctor plugin is initialized seems to be "eating" it's config and preventing the asciidoctor attribute declarations to be re-used as jekyll variables in liquid templates. So for example with this _config.yml snippet...

my_stuff:
  attributes:
    foo: "bar"

asciidoctor:
  attributes:
    foo: "yak"

...the attribute {foo} in an index.adoc file will be expanded to yak but if the liquid template contains the following:

foo1:  {{ site.my_stuff.attributes.foo }}
foo2:  {{ site.asciidoctor.attributes.foo }}

the output will be...

foo1:  bar
foo2:  

[mojavelinux]

That's correct. That's not how this part of the configuration is consumed. It's handled specially. If you know of a way to make these settings available to Liquid, I'm open to considering it. But it doesn't work as you describe because it was not a requirement for the design of this plugin.

I think the SiteDrop would need to be enhanced somehow to allow access to it, but Liquid in general is very strange in what objects it permits to be navigated (very different from Slim and Haml).

[hossman]

That's correct. That's not how this part of the configuration is consumed. It's handled specially. If you know of a way to make these settings available to liquid, I'm open to considering it. But it doesn't work as you describe because it was not a requirement for the design of this plugin.

I am in no way a jekyll/liquid expert, so if you're saying this is expected behavior then so be it -- feel free to close.

I opened the issue only because:

1. I wanted to re-use my asciidoctor attributes as jekyll variables in my liquid templates
2. the jekyll docs seemed pretty clear that any variable in _config.yml should be usable as a site.* variable
3. when i tried doing that it didn't work
4. the behavior of asciidoctor's attributes in this regard seems inconsistent with everything else in _config.yml (ie: seemed like an implementation problem, not a documentation problem)

For example, my _config.yml includes the following...

gems: [jekyll-asciidoc]

...and if i drop {{ site.gems[0] }} into my liquid templates it resolves as expected to jekyll-asciidoc even though jekyll is clearly/probably using that gems config option for important things long before my templates are evaluated -- but the variable is still available for use.

Random experiments with other variables (even deeply nested variables) in _config.yml produced similar results. It was only when I tried using site.asciidoctor.attributes.foo that I ran into problems -- Suggesting that the jekyll-asciidoc(tor) plugin was doing "something" with those configuration variables during initialization that was inconsistent with how jekyll expected them to be used.

[mojavelinux]

the jekyll docs seemed pretty clear that any variable in _config.yml should be usable as a site.* variable

That's extremely misleading of those docs because it does not take into account plugin configuration. It should say that any configuration that isn't part of a plugin configuration is likely (but not always) to be available to Liquid. So it's a generalization.

[mojavelinux]

Liquid templates can access simple structures, but they cannot access complex structures like a Hash with symbol keys. It requires special handling. There are various reasons why we have to use a Hash, and, for that matter, modify the raw site configuration. It has to do with how Jekyll is implemented and the lifecycle it exposes to plugins. We are limited by its design. I'd argue this is just the way this plugin works.

Having said all that, there is a way to access the attributes you define in _config.yml another way. You can use a YAML reference to define the attributes at the top level, then pass that to the configuration in the asciidoctor block.

asciidoc_attributes: &asciidoc_attributes
  foo: bar

asciidoctor:
  attributes: *asciidoc_attributes

Then you can reference:

{{ site.asciidoc_attributes.foo }}

Keep in mind, these will be the unprocessed entries.

[hossman]

That's extremely misleading of those docs because it does not take into account plugin configuration.

understood.

You can use a YAML reference to define the attributes at the top level, then pass that to the configuration in the asciidoctor block. ...

Ahhh... excellent! thank you for the suggestion/pointer to YAML reference - those do solve the problem nicely.

[mojavelinux]

👍

[mojavelinux]

I documented this in the README. See https://github.com/asciidoctor/jekyll-asciidoc#using-asciidoc-attributes-in-a-liquid-template.