Consider this siteNav code:
<navigation>
{% macro show_sitenav_items(items, is_flat=false) %}
* abc :expanded:
* [xyz]({{ baseUrl }}/dg/index.html)
{% endmacro %}
{{ show_sitenav_items(dg_sitenav_items) }}
</navigation>
It results in this:

Note how xyz is marked in blue as that is the current page loaded.
Now, imagine the macro is moved to another page like this:
<navigation>
{% from "scripts/macros.njk" import show_sitenav_items %}
{{ show_sitenav_items(dg_sitenav_items) }}
</navigation>
The site nav works as normal except the loaded page is not marked in blue anymore.

The link itself shouldn't work as well, this is by design of nunjucks. You could declare baseUrl as a parameter as a quick workaround though:
Imported templates are processed without the current context, so they do not have access to any of the current template variables.
The link itself shouldn't work as well, this is by design of nunjucks. You could declare
baseUrlas a parameter as a quick workaround though:
Thanks for looking into it. That's not the problem though. The link works because baseUrl is a built-in global variable. I compared the HTML of the two files and it seems there is a subtle difference of a > in one version.
Here is a live example of the problem https://reposense.org/dg/index.html
The link works because baseUrl is a built-in global variable.
It works in this case because baseUrl = ''. Did a little more searching though, seems like nunjucks supports jinja's {% from ... import ... with context %}, although it is undocumented, could try that.
https://github.com/mozilla/nunjucks/issues/ 522
https://jinja.palletsprojects.com/en/2.9.x/templates/#import-context-behavior
I compared the HTML of the two files and it seems there is a subtle difference of a > in one version.
Which file / link is this?
It works in this case because
baseUrl = ''. Did a little more searching though, seems like nunjucks supports jinja's{% from ... import ... with context %}, although it is undocumented, could try that.
Good catch. Yes that seems to be the case. I usually throw in with context most of the time just in case but didn't use it for this particular case because I didn't think it matters for supposedly _global_ variables. This is the second time I got burned by leaving out with context (#1259 is the other). Thanks again for helping to solve this mystery. I've been trying to figure this out for a long time (happened in other places too).
I compared the HTML of the two files and it seems there is a subtle difference of a > in one version.
Which file / link is this?
Seems this was a false alarm. I guess the difference was caused by an event handler modifying the menu item to make it blue.
@damithc there is a quick solution around having to use with context for global variables, the downside being that it will change the priority of site variables to the lowest. (currently it has priority over page / imported variables)
should we go with that? I'm not sure of why site variables had higher priority than page /imported variables, since if you didn't want the page / imported variables, you could just omit them.
edit: add <include><variable>...</variable></include>s to that list
By _site variables_, do you mean things defined in the site.json?
nope, those in the respective (sub)site's variables.md
including built in variables (baseUrl, ...)
I think best to leave this alone for now. The with context works. I'd rather not go for a change that _might_ have unforeseen side effects, especially in the middle of the semester. We can revisit this later. Can reopen and put on hold if you prefer.