Hi,
I added get/set variables on a whim, because I needed to pass the same long string in several places. So that’s interesting that you’ve already found use for it.
For passing a field value, I tested the following and they’re working on my end.
[pass field=slug] The post slug is: {FIELD}. [/pass]
[pass fields=slug] The post slug is: {SLUG}. [/pass]
It’s a bit confusing, the field (singular) parameter passes to {FIELD} and fields (plural) will pass to uppercased field name. I would change it, but I don’t want to break backward compatibility.
Does it not work that way on your end? If so, could you give me an example of code that’s not working as expected?
I was looking for a way to store fields from one query to pass on to another query. I managed to do it with a couple of nested loops and [pass fields] but this way the code is cleaner:
[loop type="blurb" name="quarter" count="1"][content]
[set current_quarter][field r_quarter][/set]
[/loop]
[pass vars]
[loop type="blurb" category="classes" field="r_quarter" value='{CURRENT_QUARTER}' orderby="date" order="DESC"]
...
[/loop]
[/pass]
A-ha! I see my error. It is a bit confusing in the documentation. For the singular field I interpreted {FIELD} to be the uppercased field name, not realizing that it’s supposed to be the literal {FIELD}. Thanks for the clarification. It makes sense now. Is one better (more efficient) than the other?
It used to work in the previous version and now it doesn’t. This is the code where I encountered the issue:
[loop type='blurb' category='series' paged="5"]
[pass field='title']
<h4><a href="/resources/archive/series/?r_series={TITLE}">{TITLE}</a></h4>
<h6>[content]</h6>
[/pass]
[/loop]
If I change it to the plural fields it works, and if I change {TITLE} to {FIELD} it works as well.
No harm done as I tested before going live. Forget I even brought it up. I appreciate all the excellent work you put into this plugin and the outstanding support you give. My site is pretty much built on it. All other plugins can be replaced, but there is just no equal for this one. Thanks!!!
Yes, sorry for the confusing syntax with field and fields. This feature went through several changes over time, and now I don’t see a way to improve it without breaking backward compatibility or (slightly) worse performance by replacing both versions {FIELD} and {FIELD_NAME}.
not realizing that it’s supposed to be the literal {FIELD}
I’ll try to make this more clear in the documentation.
