AsciiDoc files in collection not processed unless they are written

[elmiko]

As a Jekyll user converting my documentation to AsciiDoc, I expect document variables that are processed in collections to be available through the page variables. In cases where the collection documents are not written out though, jekyll-asciidoc will not process the variables.

This line of source seem to point at the issue https://github.com/asciidoctor/jekyll-asciidoc/blob/master/lib/jekyll-asciidoc/integrator.rb#L36

Steps to reproduce:

1. clone this project https://github.com/elmiko/jekyll-asciidoc-collection-test
2. run jekyll serve (or equivalent) in the root of project
3. visit the page generated by jekyll

Expected output:

The generated page should contain the doctitles of the AsciiDoc files in the collection, and the content for each entry should display a page variable encoded in each.

Observed output:

Instead of doctitles, i see the default filename title created by Jekyll and the page variables are absent.

I will note that with help from @mojavelinux I was able to get the variables output by adding the output: true key to my collection in the _config.yml file for my project.

Suggested solution:

It would be great if these files just worked like the Markdown files that Jekyll normally processes. As a user I would expect the variables to be processed in my collection documents regardless of whether they are marked for output.

[mojavelinux]

Thanks for this excellent report...and for providing a sample project! You did a superb job of pinpointing the faulty logic.

When support for collections was added, a decision was made to skip page variable integration if the collection is not written (as the identified line reveals). What we're challenging here is whether that was the right decision.

I think I had assumed that if a collection was not written, then it was disabled. However, this is a perfect use case of when a collection is used for embedding information into another document.

I think there are two possible paths to select from:

• Require an additional process: true configuration flag on the collection to force integration to happen even when the collection is not written.
• Process all collections regardless of whether they are written.

These are mutually exclusive options.

I think the second option is pretty safe. We just need to make sure we don't do any processing which would produce unexpected output. In other words, we need to make sure we are only integrating and not trying to write out any files that would cause other problems. A spec should allow us to answer this question easily.

[stdll]

Is there a chance that this fix will be released in a minor release before v3.0.0 (as it's only a one-liner, essentially)? I've just stumbled across this issue and it's a major setback for a customer project. The customer doesn't want to mix markup languages and chose Asciidoc as their primary language.