Using Environment variables in Shopify themes

Why would I need environment variables for my Shopify store?

During the Shopify theme development process it may be appropriate to have features change slightly depending on whether they’re being used by a customer, a developer or a test suite. We might decide to send API requests to an alternative endpoint during testing, for example. This would allow us to run tests without changing live data, or allow us to mock failed API requests, for example. We can’t trust that we’ll always remember to change this endpoint back to live before deploying to a live theme though, so we can avoid the risk by using an environment dependent setting to control this.

Another time at which we might want to use environment specific settings is to ensure that on the live theme we’re always sending minified assets to our users, whilst on test themes we can use development versions. This allows us to take advantage of faster compiles for modern browsers in our development environments, and source mapping, so that we can see which JS module has failed.

So what’s the trick?

There are two simple ways to do this. The first method is to use global settings. Chances are that when deploying theme updates, you already ignore config/settings_data.json, as doing so would overwrite all of the settings that have been changed in the store and haven’t been tracked in your theme. For this reason, you could simply add an environment option in your config/settings_schema.json, like so:

[
  ...
  {
    "name": "Developer",
    "settings": [
      {
        "label": "Environment",
        "id": "environment",
        "type": "select",
        "options": [
	        {
            "label": "Development",
            "value": "development"
          },
          {
            "label": "Production",
            "value": "production"
          }
        ],
        "default": "production"
      }
    ]
  }
  ...
]

Using this method you can quickly switch between environments via the customizer.

If you wanted to use some test API endpoints for development, you might then use the following snippet:

<script>
{%- if settings.environment == 'production' -%}
  {%- assign api = 'https://imanapi.com' -%}
{%- else -%}
  {%- assign api = 'https://test.imanapi.com' -%}
{%- endif -%}

fetchUserData('{{ api }}/user_info')
  .then(
    //...
  )
</script>

In some situations you might not be able to use the method above though. For example, if you’re developing a theme for somebody else, you might not trust them to ignore those settings. After all, Developer Settings are where the shiny new features in Chrome and Android are found, so they’ll be able to get their hands on goodies here too, right? You might also need to be able to deploy your config/settings_data.json, although I’d imagine that this is rarely the case. Whatever the reason may be, there is another way that we can change environment settings in our Shopify themes.

First of all create a snippet called env.liquid in your live and development themes on Shopify. Type the following into your snippet, but change the value to development for any themes that aren’t live:

{%- assign env = 'production' -%}

Now, add the following line to your layout/theme.liquid before any other liquid in the file (preferably line 1):

{%- include 'env' -%}

Next add your new snippet to the ignored files in Slate config file. If you’re using Slate v1, this will be your .env file, and Slate v0 will be your config.yml. Now, if you deploy your theme, not only will the env.liquid snippet not be deployed, but theme deployments won’t delete the snippet from the theme on Shopify either, because Slate is just told to ignore it.

From here, in all of the templates that build upon the theme.liquid layout, you have access to a liquid env variable, that you can use in the same manner as settings.environment from the first method.

Which method should I use?

Either approach is simple, and functionally the same, so the method you choose will likely be whatever is most convenient at the time. The first method described is the easiest to work with as it’s as simple as changing the selected option in a dropdown input, however if you’re not the only person managing the store it opens you up to the risk of those settings being changed without your knowledge. The risk is for you to weigh up.