If/Else condition in HTML attribute


I need to dynamically insert an HTML <a href="…"> value from different ACF fields depending on the post term.

This works:

<If loop type=taxonomy_term taxonomy=output_type include=video post=current>
  <a href="{Field output_video}" target="_blank" rel="noopener">View this <Taxonomy output_type><Field title /></Taxonomy></a>
<Else />
  <a href="{Field output_link}" target="_blank" rel="noopener">View this <Taxonomy output_type><Field title /></Taxonomy></a>

Then i tried to lighten the code to avoid redundancy:

<a href="{If loop type=taxonomy_term taxonomy=output_type include=video post=current}{Field output_video}{Else /}{Field output_link}{/If}" target="_blank" rel="noopener">View this <Taxonomy output_type><Field title /></Taxonomy></a>

Unfortunately, it doesn’t work well, the L&L conditional code doesn’t seem to be parsed correctly.
I tried to remove the slash in {Else /}, not better.

This is not a big concern, i can use the first code but maybe it’s simply a syntax error on my end?

Interesting! That’s a lot of code to pack into the value of an attribute, haha! I’m not sure why that’s not working, but your conditional logic statement is pretty long so it might be helpful to start with a simpler conditional statement and see if that works, and then build back up to your complicated statement and see which attribute seems to be causing this not to work.

This might be slightly less efficient since I’m setting a variable here, but if your goal is to simply avoid redundancy, I imagine you could also approach it like this:

<If loop type=taxonomy_term taxonomy=output_type include=video post=current>
  <Set output_field><Field output_video /></Set>
  <Else />
  <Set output_field><Field output_link /></Set>

<a href="{Get output_field}" target="_blank" rel="noopener">View this <Taxonomy output_type><Field title /></Taxonomy></a>
1 Like

Oh yes, elegant, thanks for sharing!

Just did a quick test and I can confirm this is a bug. I made a really simple template:

<Set href_value>home</Set>

<a href="{If variable=href_value value=home}{Url home}{Else /}{Url current}{/If}">Click here.</a>

And the URL that’s getting displayed is https://website.com%7Belse%7D%7B/Else%7Dhttps://website.com/my-page-name

So it seems that what’s going on here is that the Else tag is being converted to a regular HTML tag (thus the two else tags in my URL where <Else /> is converted to <else></else>) and then it’s just being added directly into my URL as text (converting { to %7B). Pretty odd. We’ll get a dev to take a look at what’s going on there.

1 Like

Exactly what i got in the link during the test.
Good catch!

Hey @avanti, I got an answer from a dev and it turns out the solution here is really simple: the docs were wrong. :upside_down_face: Up until a few minutes ago, this page about the syntax of L&L said:

To do this, replace the angle brackets that would usually surround a dynamic tag (like in the example below) with curly braces. Since these attributes usually contain a space, be sure to wrap them in quotes. Closed tags like <Field /> don’t need the slash / to close themselves when they’re inside an attribute.

It turns out this has been fine in 99.99% of cases I’ve seen on the forum, but it’s actually what’s causing the issue in your template. What’s happening in my example is that L&L’s parser sees {Url home} as an opening tag and then tries to look for a closing {/Url} tag. When it doesn’t find one, it assumes that everything after that tag is its children (nested inside it), which breaks the whole tree. When you leave the closing slashes on the tags, this works as expected:

<Set href_value>home</Set>

<a href="{If variable=href_value value=home}{Url home /}{Else /}{Url current /}{/If}">Click here.</a>

I guess what happened was that when Eliot first design the language and wrote the docs, he didn’t expect people to be writing a whole bunch of tags inside an attribute. The trouble is that L&L is so flexible that people like you and me did and (until now) it worked flawlessly! haha

So the moral of the story is that while it’s fine to omit the closing slash most of the time, doing so seems to cause issues when you’ve got lots of tags in your attribute.

I feel kinda bad because I’ve been telling people for over a year that they don’t need closing slashes because that’s what the docs say, but it turns out I was wrong this whole time. I’ve updated the docs to clarify this for now, but it would probably be more clear for everyone if I just combed through the docs and left the closing slashes everywhere just to avoid confusion and issues like this, so I’ll try to do that eventually.

Well done on finding this tiny but significant oversight in the docs! I guess we all learned something by looking into this.