0
votes

According to this, "Jekyll will read-in a _config.yml at the root of the theme-gem and merge its data into the site’s existing configuration data." But I've created a theme with a config that looks like this: image

And I'm referencing the variables like this in my theme's css: (Notice empty frontmatter and liquid tag on last line.) image

And the result comes out like this in the rendered site: (Notice the emptystring where my liquid tag used to be.) image

If I put the variables in the _config of my site rather than in the one for the theme, everything works as expected. But I want these variables tied to the theme.

To make matters more mysterious, I can find examples in the common minimal-mistakes theme where site variables are defined in the theme and then used, just as I've used these, in theme files with no issues. (Notice site.yadda.yadda, which are defined in the root directory's config.yml.)

I am not creating a full gem; I'm using github-pages' remote_theme feature. I would suspect that were the cause, except that themes like minimal-mistakes work fine by this method.

What is going on?

1

1 Answers

0
votes

I also posed this question over on the Jekyll GitHub and was able to arrive at some answers:

The feature doesn't work on GitHub pages because it's using Jekyll 3.8.6 to deploy, not 4.0.0, and this ability to use variables from a theme's _config.yml is a new feature in the new version.

Minimal mistakes and other themes define variables in their config files only as examples of what you the user might do in your site's config file and so the index.html and other demos defined in the theme directory itself have something to reference when they're jekyll served. In some cases you really need to provide those values, or the themes don't look as intended. In other cases, the theme _includes have conditional Liquid tags, so entire portions of a page simply aren't rendered if variables are missing in the child site.

Solutions?

  1. Wait for GitHub to use 4.0.0, which looks like people have been asking about and waiting on for nearly a year.
  2. Define all variables in the child-site. Not workable if you truly need the theme to include this information so it can be reused across several sites, e.g. this use case.
  3. Instead of using variables and Liquid code, hard-code values everywhere a variable appears.
  4. Build with Jekyll 4.0.0 locally, and push the _site artifacts up to a gh-pages branch manually or with continuous integration. (Labor-intensive to set up, not very workable for a User Pages site because it renders from master, and currently not possible with remote_themes because it's broken for 4.0.0)
  5. Use some other service that supports Jekyll 4.0.0 to deploy, like Netlify. But this sort of defeats the purpose of making this seamless with my GitHub repos to display my work.

Because I don't have many variables, I'm going with hard-coding for now and just waiting out the Jekyll 3.8.6/4.0.0 thing.