gitea-pages/doc_conditional_logic.md

---
title: Conditional logic
tags: [single-sourcing]
audience: writer, designer
keywords: 
last_updated: 
summary: 
---
{% include linkrefs.html %} 

If you want to create different outputs for different audiences, you can do all of this using a combination of Jekyll's Liquid markup and values in your configuration file.

{{tip}} Definitely check out [Liquid's documentation](http://docs.shopify.com/themes/liquid-documentation/basics) for more details about how to use operators and other liquid markup. The notes here are a small, somewhat superficial sample from the site.{{end}}

## Where to store filtering values

You can filter content based on values that you have set either in your config file or in a file in your \_data folder. If you set the attribute in your config file, you need to restart the Jekyll server to see the changes. If you set the value in a file in your \_data folder, you don't need to restart the server when you make changes. 

## Required conditional attributes

This theme requires you to add the following attributes in your configuration file:

* project 
* audience
* product 
* platform 
* version

If you've ever used DITA, you probably recognize these attributes, since DITA has mostly the same ones. I've found that most single-sourcing projects I work on can be sliced and diced in the ways I need using these conditional attributes.

If you're not single sourcing and you find it annoying having to specify these attributes in your sidebar, you can rip out the logic from the sidebar.html file; then you wouldn't need these attributes in your configuration file.

## Conditional logic based on config file value

Here's an example of conditional logic based on a value in the configs/config_writer.yml file. In my config_writer.yml file, I have the following:

```
audience: writers
```

On a page in my site (it can be HTML or markdown), I can conditionalize content using the following:


```liquid
{% raw %}
{% if site.audience == "writers" %}
The writer audience should see this...
{% elsif site.audience == "designers" %}
The designer audience should see this ...
{% endif %}
{% endraw %}
```

This uses simple `if-elsif` logic to determine what is shown (note the spelling of `elsif`). The `else` statement handles all other conditions not handled by the `if` statements. 

Here's an example of `if-else` logic inside a list:


```liquid
{% raw %}
To bake a casserole:

1. Gather the ingredients.
{% if site.audience == "writer" %}
2. Add in a pound of meat.
{% elsif site.audience == "designer" %}
3. Add in an extra can of beans.
{% endif %}
3. Bake in oven for 45 min.
```
{% endraw %}

## Or operator

You can use more advanced Liquid markup for conditional logic, such as an `or` command. See [Shopify's Liquid documentation](http://docs.shopify.com/themes/liquid-documentation/basics/operators) for more details. 

For example, here's an example using `or`:

```
{% raw %}
{% if site.audience contains "vegan" or site.audience == "vegetarian" %}
    // run this.
{% endif %}
{% endraw %}
```

With conditional statements, you don't need the `elsif` or `else` options. But you do always need the `endif`.

## Storing conditions in the \_data folder

Here's an example of using conditional logic based on a value in a data file:

{% comment %}
```
{% raw %}
{% if site.data.options.output == "alpha" %}
show this content...
{% elsif site.data.options.output == "beta" %}
show this content...
{% else %}
this shows if neither of the above two if conditions are met.
{% endif %}
{% endraw %}
```
{% endcomment %}

To use this, I would need to have a \_data folder called options where the audience property is stored. 

I don't really use the \_data folder as much for project options. I store them in the configuration file because I usually want different projects to use different values for the same property. 

For example, maybe a file or function name is called something different for different audiences. I currently single source the same content to both a fraud-prevention audience and an advertising technology audience. The identification technology is largely the same. 

For the fraud audience, the function name might be called `generate`, but for the ad tech audience, the same function is called `expand`. In my content, I'd just use `{% raw %}{{site.function}}{% endraw %}` in the configuration file and change its value appropriately for the audience.

## Specifying a data source

You can also specify a `data_source` for your data location in your configuration file. Then you aren't limited to simply using `\_data` to store your data. 

For example, suppose you have 2 projects: alpha and beta. You might store all the data files for alpha inside data_alpha, and all the data files for beta inside data_beta.

In your configuration file, specify the data source like this:

```
data_source: data_alpha
```

Then create a folder called data_alpha.

## Conditional logic based on page namespace

You can also create conditional logic based on the page namespace. For example, create a page with front matter as follows:


```liquid
{% raw %}
---
layout: page
user_plan: full
---
 {% endraw %}
```

Now you can run logic based on the conditional property in that page's front matter:


```liquid
{% raw %}
{% if page.user_plan` == "full" %}
// run this code
{% endif %}
{% endraw %}
```

## Conditions versus includes

If you have a lot of conditions in your text, it can get confusing. As a best practice, whenever you insert an `if` condition, add the `endif` at the same time. This will reduce the chances of forgetting to close the if statement. Jekyll won't build if there are problems with the liquid logic. 

If your text is getting busy with a lot of conditional statements, consider putting a lot of content into includes so that you can more easily see where the conditions begin and end.