From 8bacf01c1b49042d9aeb1a9b82824f46292545e5 Mon Sep 17 00:00:00 2001 From: Tom Johnson Date: Sun, 29 Jan 2017 21:45:03 -0800 Subject: [PATCH 1/4] Add documentation about order of interpretation This tutorial defines Jekyll's "order of interpretation," as @swizca called it in [#5808](https://github.com/jekyll/jekyll/pull/5698). This tutorial makes it clear how Jekyll processes files as it renders the static HTML output. This order-of-interpretation info is important for troubleshooting and generally understanding Jekyll. It's important to know how Jekyll generates out the files, what rules it uses, what order it processes things, and so forth. (Note: Please process 5698 before this request, because 5698 includes the tutorial collection/navigation that this tutorial fits into. I also need to update this commit to add a link in the Tutorials nav to this topic, but I'm waiting for 5698 to be merged so that menu becomes available.) @jekyll/documentation @dirtyf --- docs/_tutorials/orderofinterpretation.md | 133 +++++++++++++++++++++++ 1 file changed, 133 insertions(+) create mode 100644 docs/_tutorials/orderofinterpretation.md diff --git a/docs/_tutorials/orderofinterpretation.md b/docs/_tutorials/orderofinterpretation.md new file mode 100644 index 00000000..e4e003be --- /dev/null +++ b/docs/_tutorials/orderofinterpretation.md @@ -0,0 +1,133 @@ +--- +layout: tutorials +permalink: /tutorials/orderofinterpretation/ +title: Order of interpretation +--- + +Jekyll's main job is to convert your raw text files into a static website. It does this by rendering Liquid, Markdown, and other transforms as it generates the static HTML output. + +In this conversion process, it's important to understand Jekyll's order of interpretation. By "order of interpretation," we mean what gets rendered, in what order, and what rules get applied in converting content. + +If an element isn't converting, you can troubleshoot the problem by analyzing the order of interpretation. + +## Order of interpretations + +Jekyll converts your site in the following order: + +1. **Site variables**. Jekyll looks across your files and populates [site variables]({% link _docs/variables.md %}), such as `site`, `page`, `post`, and collection objects. (From these objects, Jekyll determines the values for permalinks, tags, categories, and other details.) + +2. **Liquid**. Jekyll processes any Liquid formatting in pages that contain [front matter]({% link _docs/frontmatter.md %}). All Liquid tags, such as `include`, `highlight`, or `assign` tags, are rendered. (Anything in Jekyll with `{% raw %}{{ }}{% endraw %}` curly braces or `{% raw %}{% %}{% endraw %}` is usually a Liquid filter or tag.) + +3. **Markdown**. Jekyll converts Markdown to HTML using the Markdown filter specified in your config file. Files must have a Markdown file extension and front matter in order for Jekyll to convert them. + +4. **Layout**. Jekyll pushes content into the layouts specified by the page's front matter (or as specified in the config file). The content from each page gets pushed into the `{% raw %}{{content}}{% endraw %}` tags within the layouts. + +5. **Files**. Jekyll writes the generated content into files in the [directory structure]({% link _docs/structure.md %}) in `_site`. Pages, posts, and collections get structured based on their [permalink]({% link _docs/permalinks.md %}) setting. Directories that begin with `_` (such as `_includes` and `_data`) are usually hidden in the output. + +## Scenarios where incorrect configurations yield problems + +For the most part, you don't have to think about the order of interpretation when building your Jekyll site. These details only become important to know when something isn't rendering. + +The following scenarios highlight potential problems you might encounter. These problems stem from misunderstanding the order of interpretation and can be easily fixed. + +### Variable on page not rendered because variable is assigned in layout + +In your layout file (`_layouts/default.html`), suppose you have a variable assigned: + +``` +{% raw %}{% assign myvar = "joe" %}{% endraw %} +``` + +On a page that uses the layout, you reference that variable: + +``` +{% raw %}{{myvar}}{% endraw %} +``` + +The variable won't render because the page's order of interpretation is to render Liquid first and later process the Layout. When the Liquid rendering happens, the variable assignment isn't available. + +To make the code work, you could put the variable assignment into the page's front matter. + +### Liquid tag in data reference not rendered + +In `_data/mydata.yml`, suppose you have this mapping: + +``` +{% raw %}somevalue: {{myvar}}{% endraw %} +``` + +On a page, you try to insert this value: + +``` +{% raw %}{{site.data.mydata.somevalue}}{% endraw %} +``` +Nothing renders because first the site variables populate, and then Liquid renders. When the site variables populate, the value for `{% raw %}{{site.data.mydata.somevalue}}{% endraw %}` is simply `{% raw %}{{myvar}}{% endraw %}`, which registers as a string and gets printed as a string. You can't use Liquid in data files. + +Similarly, suppose you have a `highlight` tag in your `_data/mydata.yml` file: + +``` +{% raw %}myvalue: > + {% highlight javascript %} + console.log('alert'); + {% endhighlight %}{% endraw %} +``` + +On a page, you try to insert the value: + +``` +{% raw %}{{site.data.mydata.myvalue}}{% endraw %} +``` + +This renders as a string for the same reasons described above. When the `site.data.mydata.myvalue` tag populates, the value gets stored as a string and printed to the page as a string. + +To make the code work, consider populating content from includes. + +### Markdown in include file not processed + +Suppose you have a Markdown file at `_includes/mycontent.md`. In the Markdown file, you have some Markdown formatting: + +```markdown +This is a list: +* first item +* second item +``` + +You include the file into an HTML file as follows: + +```liquid +{% raw %}{% include mycontent.md %}{% endraw %} +``` + +The Markdown is not processed because first the Liquid (`include` tag) gets processed, inserting `mycontent.md` into the HTML file. *Then* the Markdown would get processed. + +But because the content is included into an *HTML* page, the Markdown isn't rendered. The Markdown filter processes content only in Markdown files. + +To make the code work, use HMTL formatting in includes inserted into HTML files. + +However, note that `highlight` tags don't require Markdown to process. Suppose your include contains the following: + +```liquid +{% raw %}{% highlight javascript %} +console.log('alert'); +{% endhighlight %}{% endraw %} +``` + +The `highlight` tag *is* Liquid. (Liquid passes the content to Rouge or Pygments for syntax highlighting.) As a result, this code will actually convert to HTML with syntax highlighting. Jekyll does not need the Markdown filter to process `highlight` tags. + +### Liquid mixed with JavaScript isn't rendered + +Suppose you try to mix Liquid with JavaScript, like this: + +```liquid +{% raw %}if page.type == "home" { + $("intro").addClass("bright"); +elsif page.type == "normal" { + $("intro").addClass("muted"); + }{% endraw %} +``` + +The Liquid renders long before the page gets converted to HTML. So when JavaScript executes in the browser, the Liquid is no longer present. + +You can never mix Liquid with JavaScript because Liquid processes when the site builds. In contrast, JavaScript processes in the browser when a user interacts with your site. + +To make the code work, don't mix Liquid with JavaScript. If you need the code to execute in real-time in the browser, use JavaScript. From a7cba8a8a6686af2c8395bd627e2e8a2a2819a5e Mon Sep 17 00:00:00 2001 From: Tom Johnson Date: Mon, 30 Jan 2017 11:45:24 -0800 Subject: [PATCH 2/4] Made updates as suggested by reviewers --- docs/_tutorials/orderofinterpretation.md | 59 ++++++++++++++++-------- 1 file changed, 40 insertions(+), 19 deletions(-) diff --git a/docs/_tutorials/orderofinterpretation.md b/docs/_tutorials/orderofinterpretation.md index e4e003be..bf3614a1 100644 --- a/docs/_tutorials/orderofinterpretation.md +++ b/docs/_tutorials/orderofinterpretation.md @@ -20,11 +20,11 @@ Jekyll converts your site in the following order: 3. **Markdown**. Jekyll converts Markdown to HTML using the Markdown filter specified in your config file. Files must have a Markdown file extension and front matter in order for Jekyll to convert them. -4. **Layout**. Jekyll pushes content into the layouts specified by the page's front matter (or as specified in the config file). The content from each page gets pushed into the `{% raw %}{{content}}{% endraw %}` tags within the layouts. +4. **Layout**. Jekyll pushes content into the layouts specified by the page's front matter (or as specified in the config file). The content from each page gets pushed into the `{% raw %}{{ content }}{% endraw %}` tags within the layouts. 5. **Files**. Jekyll writes the generated content into files in the [directory structure]({% link _docs/structure.md %}) in `_site`. Pages, posts, and collections get structured based on their [permalink]({% link _docs/permalinks.md %}) setting. Directories that begin with `_` (such as `_includes` and `_data`) are usually hidden in the output. -## Scenarios where incorrect configurations yield problems +## Scenarios where incorrect configurations create problems For the most part, you don't have to think about the order of interpretation when building your Jekyll site. These details only become important to know when something isn't rendering. @@ -41,7 +41,7 @@ In your layout file (`_layouts/default.html`), suppose you have a variable assig On a page that uses the layout, you reference that variable: ``` -{% raw %}{{myvar}}{% endraw %} +{% raw %}{{ myvar }}{% endraw %} ``` The variable won't render because the page's order of interpretation is to render Liquid first and later process the Layout. When the Liquid rendering happens, the variable assignment isn't available. @@ -53,15 +53,16 @@ To make the code work, you could put the variable assignment into the page's fro In `_data/mydata.yml`, suppose you have this mapping: ``` -{% raw %}somevalue: {{myvar}}{% endraw %} +{% raw %}somevalue: {{ myvar }}{% endraw %} ``` On a page, you try to insert this value: ``` -{% raw %}{{site.data.mydata.somevalue}}{% endraw %} +{% raw %}{{ site.data.mydata.somevalue }}{% endraw %} ``` -Nothing renders because first the site variables populate, and then Liquid renders. When the site variables populate, the value for `{% raw %}{{site.data.mydata.somevalue}}{% endraw %}` is simply `{% raw %}{{myvar}}{% endraw %}`, which registers as a string and gets printed as a string. You can't use Liquid in data files. + +This renders as a string (`{% raw %}"{{ site.data.mydata.somevalue }}{% endraw %}"` rather than the variable's value. This is because first the site variables populate, and then Liquid renders. When the site variables populate, the value for `{% raw %}{{ site.data.mydata.somevalue }}{% endraw %}` is simply `{% raw %}{{ myvar }}{% endraw %}`, which registers as a string. You can't use Liquid in data files. Similarly, suppose you have a `highlight` tag in your `_data/mydata.yml` file: @@ -75,7 +76,7 @@ Similarly, suppose you have a `highlight` tag in your `_data/mydata.yml` file: On a page, you try to insert the value: ``` -{% raw %}{{site.data.mydata.myvalue}}{% endraw %} +{% raw %}{{ site.data.mydata.myvalue }}{% endraw %} ``` This renders as a string for the same reasons described above. When the `site.data.mydata.myvalue` tag populates, the value gets stored as a string and printed to the page as a string. @@ -102,9 +103,9 @@ The Markdown is not processed because first the Liquid (`include` tag) gets proc But because the content is included into an *HTML* page, the Markdown isn't rendered. The Markdown filter processes content only in Markdown files. -To make the code work, use HMTL formatting in includes inserted into HTML files. +To make the code work, use HMTL formatting in includes that are inserted into HTML files. -However, note that `highlight` tags don't require Markdown to process. Suppose your include contains the following: +Note that `highlight` tags don't require Markdown to process. Suppose your include contains the following: ```liquid {% raw %}{% highlight javascript %} @@ -116,18 +117,38 @@ The `highlight` tag *is* Liquid. (Liquid passes the content to Rouge or Pygments ### Liquid mixed with JavaScript isn't rendered -Suppose you try to mix Liquid with JavaScript, like this: +Suppose you try to mix Liquid's `assign` tag with JavaScript, like this: -```liquid -{% raw %}if page.type == "home" { - $("intro").addClass("bright"); -elsif page.type == "normal" { - $("intro").addClass("muted"); - }{% endraw %} +```javascript +{% raw %} + +

+ +{% endraw %} ``` -The Liquid renders long before the page gets converted to HTML. So when JavaScript executes in the browser, the Liquid is no longer present. +This won't work because the `assign` tag is only available during the Liquid rendering phase of the site. In this JavaScript example, the script executes when a user clicks a button ("Click me") on the page. At that time, the Liquid logic is no longer available, so the `assign` tag wouldn't return anything. -You can never mix Liquid with JavaScript because Liquid processes when the site builds. In contrast, JavaScript processes in the browser when a user interacts with your site. +However, you can use Jekyll's site variables or Liquid to *populate* a script that is executed at a later time. For example, suppose you have the following property in your front matter: `someContent: "This is some content"`. You could do this: -To make the code work, don't mix Liquid with JavaScript. If you need the code to execute in real-time in the browser, use JavaScript. +```js +{% raw %} + +

+ +{% endraw %} +``` + +When Jekyll builds the site, this `someContent` property populates the script's values, converting `{% raw %}{{ page.someContent }}{% endraw %}` to `"This is some content"`. + +The key to remember is that Liquid renders when Jekyll builds your site. Liquid is not available at run-time in the browser when a user executes an event. From 4b325a65afde21830b026ee978c847ac4c2c3b5b Mon Sep 17 00:00:00 2001 From: Tom Johnson Date: Fri, 3 Feb 2017 20:46:05 -0800 Subject: [PATCH 3/4] updated based on review I moved the section about liquid and yaml to the end and shortened it. i also clarified that isn't an order-of-interpretation issue why liquid doesn't render in yaml. I also fixed the type with HMTL. --- docs/_tutorials/orderofinterpretation.md | 60 +++++++++--------------- 1 file changed, 23 insertions(+), 37 deletions(-) diff --git a/docs/_tutorials/orderofinterpretation.md b/docs/_tutorials/orderofinterpretation.md index bf3614a1..8ffb9d7e 100644 --- a/docs/_tutorials/orderofinterpretation.md +++ b/docs/_tutorials/orderofinterpretation.md @@ -48,41 +48,6 @@ The variable won't render because the page's order of interpretation is to rende To make the code work, you could put the variable assignment into the page's front matter. -### Liquid tag in data reference not rendered - -In `_data/mydata.yml`, suppose you have this mapping: - -``` -{% raw %}somevalue: {{ myvar }}{% endraw %} -``` - -On a page, you try to insert this value: - -``` -{% raw %}{{ site.data.mydata.somevalue }}{% endraw %} -``` - -This renders as a string (`{% raw %}"{{ site.data.mydata.somevalue }}{% endraw %}"` rather than the variable's value. This is because first the site variables populate, and then Liquid renders. When the site variables populate, the value for `{% raw %}{{ site.data.mydata.somevalue }}{% endraw %}` is simply `{% raw %}{{ myvar }}{% endraw %}`, which registers as a string. You can't use Liquid in data files. - -Similarly, suppose you have a `highlight` tag in your `_data/mydata.yml` file: - -``` -{% raw %}myvalue: > - {% highlight javascript %} - console.log('alert'); - {% endhighlight %}{% endraw %} -``` - -On a page, you try to insert the value: - -``` -{% raw %}{{ site.data.mydata.myvalue }}{% endraw %} -``` - -This renders as a string for the same reasons described above. When the `site.data.mydata.myvalue` tag populates, the value gets stored as a string and printed to the page as a string. - -To make the code work, consider populating content from includes. - ### Markdown in include file not processed Suppose you have a Markdown file at `_includes/mycontent.md`. In the Markdown file, you have some Markdown formatting: @@ -103,7 +68,7 @@ The Markdown is not processed because first the Liquid (`include` tag) gets proc But because the content is included into an *HTML* page, the Markdown isn't rendered. The Markdown filter processes content only in Markdown files. -To make the code work, use HMTL formatting in includes that are inserted into HTML files. +To make the code work, use HTML formatting in includes that are inserted into HTML files. Note that `highlight` tags don't require Markdown to process. Suppose your include contains the following: @@ -132,7 +97,7 @@ function someFunction() { {% endraw %} ``` -This won't work because the `assign` tag is only available during the Liquid rendering phase of the site. In this JavaScript example, the script executes when a user clicks a button ("Click me") on the page. At that time, the Liquid logic is no longer available, so the `assign` tag wouldn't return anything. +This won't work because the `assign` tag is only available during the Liquid rendering phase of the site. In this JavaScript example, the script executes when a user clicks a button ("Click me") on the HTML page. At that time, the Liquid logic is no longer available, so the `assign` tag wouldn't return anything. However, you can use Jekyll's site variables or Liquid to *populate* a script that is executed at a later time. For example, suppose you have the following property in your front matter: `someContent: "This is some content"`. You could do this: @@ -152,3 +117,24 @@ function someFunction() { When Jekyll builds the site, this `someContent` property populates the script's values, converting `{% raw %}{{ page.someContent }}{% endraw %}` to `"This is some content"`. The key to remember is that Liquid renders when Jekyll builds your site. Liquid is not available at run-time in the browser when a user executes an event. + +## Note about using Liquid in YAML + +There's one more detail to remember: Liquid does not render when embedded in YAML files or front matter. (This isn't related to order of interpretation, but it's worth mentioning because it's a common question about element rendering.) + +For example, suppose you have a `highlight` tag in your `_data/mydata.yml` file: + +``` +{% raw %}myvalue: > + {% highlight javascript %} + console.log('alert'); + {% endhighlight %}{% endraw %} +``` + +On a page, you try to insert the value: + +``` +{% raw %}{{ site.data.mydata.myvalue }}{% endraw %} +``` + +This would render as a string rather than a code sample with syntax highlighting. To make the code render, you might use an include instead. From 755cc6c137dedefe7a070fdf03f427e102b5e866 Mon Sep 17 00:00:00 2001 From: Tom Johnson Date: Sun, 5 Feb 2017 20:55:16 -0800 Subject: [PATCH 4/4] Fixes based on latest review Mostly I added more detail in the Liquid section. --- docs/_tutorials/orderofinterpretation.md | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/docs/_tutorials/orderofinterpretation.md b/docs/_tutorials/orderofinterpretation.md index 8ffb9d7e..1146c636 100644 --- a/docs/_tutorials/orderofinterpretation.md +++ b/docs/_tutorials/orderofinterpretation.md @@ -16,7 +16,10 @@ Jekyll converts your site in the following order: 1. **Site variables**. Jekyll looks across your files and populates [site variables]({% link _docs/variables.md %}), such as `site`, `page`, `post`, and collection objects. (From these objects, Jekyll determines the values for permalinks, tags, categories, and other details.) -2. **Liquid**. Jekyll processes any Liquid formatting in pages that contain [front matter]({% link _docs/frontmatter.md %}). All Liquid tags, such as `include`, `highlight`, or `assign` tags, are rendered. (Anything in Jekyll with `{% raw %}{{ }}{% endraw %}` curly braces or `{% raw %}{% %}{% endraw %}` is usually a Liquid filter or tag.) +2. **Liquid**. Jekyll processes any [Liquid](https://github.com/Shopify/liquid) formatting in pages that contain [front matter]({% link _docs/frontmatter.md %}). You can identify Liquid as follows: + * **Liguid tags** start with `{% raw %}{%{% endraw %}` and end with a `{% raw %}%}{% endraw %}`. For example: `{% raw %}{% highlight %}{% endraw %}` or `{% raw %}{% seo %}{% endraw %}`. Tags can define blocks or be inline. Block-defining tags will also come with a corresponding end tag — for example, `{% raw %}{% endhighlight %}{% endraw %}`. + * **Liquid variables** start and end with double curly braces. For example: `{% raw %}{{ site.myvariable }}{% endraw %}` or `{% raw %}{{ content }}{% endraw %}`. + * **Liquid filters** start with a pipe character (`|`) and can only be used within **Liquid variables** after the variable string. For example: the `relative_url` filter in `{% raw %}{{ "css/main.css" | relative_url }}{% endraw %}`. 3. **Markdown**. Jekyll converts Markdown to HTML using the Markdown filter specified in your config file. Files must have a Markdown file extension and front matter in order for Jekyll to convert them. @@ -28,7 +31,7 @@ Jekyll converts your site in the following order: For the most part, you don't have to think about the order of interpretation when building your Jekyll site. These details only become important to know when something isn't rendering. -The following scenarios highlight potential problems you might encounter. These problems stem from misunderstanding the order of interpretation and can be easily fixed. +The following scenarios highlight potential problems you might encounter. These problems come from misunderstanding the order of interpretation and can be easily fixed. ### Variable on page not rendered because variable is assigned in layout @@ -137,4 +140,4 @@ On a page, you try to insert the value: {% raw %}{{ site.data.mydata.myvalue }}{% endraw %} ``` -This would render as a string rather than a code sample with syntax highlighting. To make the code render, you might use an include instead. +This would render only as a string rather than a code sample with syntax highlighting. To make the code render, consider using an include instead.