Distill

Bloke · 2017-03-30 15:31:49

Destry wrote #305150:

I hope it works like that, because that would be useful for lots of other things.

ymmv, but I don’t know if you can access page-level variables in an include. Like you say, it’d be neat if you could, but the example I saw passed in the info via a variable name and then used that in the included file.

Compare yours with:

{% if ref="{{ page.figure }} %}{% include figure.html figure_info=page.figure site_info=site.github %}{% endif %}

And then in your include:

<figure>
  <img alt="{{ include.figure_info[fig_alt] }}" src="{{ site_info.url }}/assets/images/{{ include.figure_info[fig_slug] }}.png">
  <figcaption>{{ include.figure_info[fig_caption] }}</figcaption>
</figure>

Note that variables inside includes are prefixed with include instead of page because they’re passed in. After that you can reference them as you would on the main page.

It might work the easy way, it depends how Liquid is scoped.

Destry · 2017-03-30 15:54:45

Bloke wrote #305151:

it’d be neat if you could, but…

Drat.

figure_info … site_info

Where did those come from? Does liquid just understand them like that? Constants?

You can’t assume I know anything when it comes to code conventions outside of regular ol’ HTML/CSS.

Note that variables inside includes are prefixed with include instead of page because they’re passed in.

Okay, that’s good to know.

I see that figure_info again.

Bloke · 2017-03-30 15:58:19

Destry wrote #305152:

Where did [figure_info et al] come from?

I just made them up. You could call them jim and bob if you like, then use them as include.jim and include.bob. Just variables of your choice.

Destry · 2017-03-30 16:05:26

Ah, okay, I see what you mean. You just created a new variable on the spot and that’s what’s used in the include. I would have never realized/figured you could do something like that. I think it takes someone with coding experience to grasp this stuff.

I’ll give it a whirl.

Destry · 2017-03-30 16:15:34

I think I’ll have to try that with the authors/affils parts too, because I kind of set that block up in a similar way yesterday.

Bloke · 2017-03-30 16:22:30

Destry wrote #305154:

I think it takes someone with coding experience to grasp this stuff.

^{Stef just found an example on the internet and copied it. Stef not clever. Google clever.}

Destry · 2017-03-30 16:36:10

Might be getting somewhere. The site finally built that time without throwing an error, though it’s all messed up still somewhere. Some elements not showing up. But at least it’s a change. ;)

Destry · 2017-03-30 16:55:10

Victory! There were some stray tabs in the authors/affiliations array in front matter. That shite is tricky because you can’t see it. you basically have to position cursor on each line and arrow key back for forth to see what’s going on. Spaces only for the win.

Anyway, figuring out the home index page will be a monster. But that’s a fight for another day. Cheers, Bloke!

Bloke · 2017-03-30 17:02:45

Ah yes, like Python, YAML is very keen on spaces as it’s a positional language. Tabs really screw things up, as you found.

Destry · 2017-03-31 06:01:59

Arg! False victory. In my excitement to see the build happen, I overlooked that the authors/affils and figure blocks don’t even show up at all. So there must be something wrong with the way I’ve done that.

Frankly, this yaml and liquid shite seems way too touchy and confusing to be worth a damn. I’m ready to go back to HTML and say, ‘if we don’t need a figure in this one, just delete the block for it. It should not be this hard to add an include and use it in combination with front matter.

Also, after looking at various resources, some of which you’ve pointed out, Bloke, I can say that any help site that based its examples on yaml/liquid/html patterns would be very popular. Everything is just the yaml, or liquid, but not all three together, which is what is needed to make sense of it. I guess the world of GitHub/Jekyll doesn’t count on HTML noobs messing in a repo. Or YAML/Liquid noobs like me trying to build a site.

</rant>

Destry · 2017-03-31 06:27:15

Just got this from GitHub (after I complained):

Rendering Liquid: user-story.md

Liquid Exception: Invalid syntax for include tag. File contains invalid characters or sequences: authors.html ref=”“ Valid syntax: {% include file.ext param=‘value’ param2=‘value’ %} in user-story.md

Fatal: ArgumentError
Invalid syntax for include tag. File contains invalid characters or sequences: authors.html ref=”“ Valid syntax: {% include file.ext param=‘value’ param2=‘value’ %}

The file is now called writers.html (not authors.html), so I’m not sure they actually tested against the current structure-state or not.

But it appears the problem — or at least the first instance of one — was in the include tag. Whether it was how I had it wrong before, or with defining the local variable, I don’t know. But I know neither way works as I had it.

Now we go back to my gripe again, because even though they give me this valid syntax pattern…

{% include file.ext param='value' param2='value' %}

I don’t know how to use it for a hash/array.

For example, if my front matter is this:

yaml
collaborators:
  - 
    who: "Jane Doe"
    affiliation: "That Place"
    affiliation_url: "https://domain.tld"
  - 
    who: "John Updike"
    affiliation: "The Other Spot"
    affiliation_url: "https://domain.eek"

Then instead of this…

{% include writers.html authors_info=page.collaborators %}

How do I structure it? What if there were 10 collaborators on a given definition? How does that impact building the include tag?

And then what should the markup look like in the include content?

So you see, a yaml/liquid/markup pattern library is really needed. Maybe that should be a new repo, if I could figure this crap out.

They also tell me I should install Jekyll locally and test that way so I suffer with it on my own. I knew that would be the inevitable end.

Bloke · 2017-03-31 08:19:49

Hmmm, I’m not familiar enough with Jekyll and don’t have it locally so I’m kind of shooting blind. But I guess there are a few things at play here.

Firstly, are you sure your frontmatter syntax is correct? If you try to pass something that isn’t a proper structure to an include, it will probably throw that error you’re seeing because it thinks you’re passing junk into the include. This resource might help as it gives a fairly complex example that you might be able to glean something from and pare down to your uses.

Secondly, your include syntax looks okay, but I can’t tell from the (many) conflicting sources on the web what the actual syntax is for passing variables in. Presumably there are a few flavours, either now or in the past that may have changed over time. As far as I can tell, you can:

{% include writers.html myvar='Some static text' %}

and you’d access that in your writers.html like this: {{include.myvar}}, which would just print out Some static text.

Then we have:

{% include writers.html myvar=page.collaborators %}
or
{% include writers.html myvar={{page.collaborators}} %}

I’m not sure which is correct as I’ve seen both in examples on the internet.

Either way, if your collaborators is a valid structure, you should be able to access those in writers.html like this:

{% for loopvar in include.myvar %}
   // now each value in your structure is available via loopvar.name
   // e.g. {{loopvar.who}}
   // {{loopvar.affiliation}}
   // etc
{% endfor %}

You can call loopvar anything you like and use it inside the for...endfor to access the variables in your structure.

This is just one of those frustrating situations where you need to start small and build up, changing only one thing at a time until it breaks, figure that out, then move on. Welcome to the murky world of programming ;-)

Destry · 2017-03-31 13:46:55

It seems the place where things are tripping up is with the liquid structure in the include file (function?) markup.

I’m working with just the Figure for now, because that’s a simpler/fixed front matter hash with 3 keys. It will never be more, as opposed to the situation with authors, which could keep growing, so I think each function will need a different liquid structure, yes?

If I edit the figure.html markup to straight HTML (no liquid), it outputs with no build or display problems using this function call:

{% if page.figure %}
{% include figure.html figure_info=page.figure %}
{% endif %}

The local variable isn’t used for anything, of course, but it at least confirms the pattern is written correctly.

But whether I need to use a variable (myvar=newvariable) or a parameter string (param="value") or both, I don’t know, because I’m having trouble getting my head around the liquid needed in the function markup first.

Here’s the figure function without any liquid (this passes without problems)

<figure>
  <img alt="A placeholder image." src="http://content-strategy-forum.github.io/csf-glossary/assets/images/placeholder.png">
  <figcaption>A belle figure of mysterious nature.</figcaption>
</figure>

The front matter:

yaml
figure:
  fig_slug: placeholder 
  fig_alt: "A placeholder image."
  fig_caption: "A belle figure of mysterious nature."

Now, how to dress up the markup with Liquid to grab those three values? This is the part I can’t get my head around. That tutorial says:

You cannot return an “array” or any other variable than a string. If you need to do so, then convert the variable into some string format that you can then capture and reconvert into variable in the caller.

Unfortunately, that lingo makes no sense to me.

I’ve been testing with just the figure caption to isolate one spot.

The key values in the figure function do qualify as strings, I think, so I tried this:

{% if page.figure %}
{% include figure.html figslug="figure_slug" figalt="fig_alt" figcap="fig_caption" %}
{% endif %}

And that did output a caption (the test key), but the value was “fig_caption”, not the key value is in the front matter. I figured that would be an easy win, but hell no.

Then I thought, ‘Wait! is the figure front matter variable supposed to be its own front matter in the figure function file? Test says: Nope.

So I’ve got no clue, except to say, screw this. I’m going back to good ol’ HTML. Collaborators be damned. I need someone smarter than me doing the yaml and liquid on this project if it’s going to happen at all.

Bloke · 2017-03-31 13:59:14

What happens if you do this?

{% if page.figure %}
{% include figure.html figslug="figure_slug" figalt="fig_alt" figcap=page.fig_caption %}
{% endif %}

or this:

{% if page.figure %}
{% include figure.html figslug="figure_slug" figalt="fig_alt" figcap={{page.fig_caption}} %}
{% endif %}

Does your frontmatter figure caption get output then?

Destry · 2017-03-31 14:16:50

This first one builds but there’s no output.

The second one throws a build error, so that’s probably not allowed structure.

This is all I have in the markup: <figcaption>{{ include.figcap }}</figcaption>. Could be the problem. I don’t know.

Don’t waste anymore time on it, brother. I’ve spent hours and hours and hours this week on it. It’s f-ing ridiculous. I will never do another Jekyll site. I’ve got better things to do, like spring yard work.

By the way, I’ve started issues for these, which might be a better place to throw down at this point:

Textpattern CMS

Textpattern CMS support forum

#16 2017-03-30 15:31:49

Re: Distill

Destry wrote #305150:

#17 2017-03-30 15:54:45

Re: Distill

Bloke wrote #305151:

#18 2017-03-30 15:58:19

Re: Distill

Destry wrote #305152:

#19 2017-03-30 16:05:26

Re: Distill

#20 2017-03-30 16:15:34

Re: Distill

#21 2017-03-30 16:22:30

Re: Distill

Destry wrote #305154:

#22 2017-03-30 16:36:10

Re: Distill

#23 2017-03-30 16:55:10

Re: Distill

#24 2017-03-30 17:02:45

Re: Distill

#25 2017-03-31 06:01:59

Re: Distill

#26 2017-03-31 06:27:15

Re: Distill

#27 2017-03-31 08:19:49

Re: Distill

#28 2017-03-31 13:46:55

Re: Distill

#29 2017-03-31 13:59:14

Re: Distill

#30 2017-03-31 14:16:50

Re: Distill

Board footer