After updating to 3.4.13, all of my sub navigation is not rendering. It has something to do with the .hidden property as removing it causes them to render again.
At some point I had to add the .hidden('not 1') property to make the top level element not double render (I think that's why it's there - it was built a couple of years ago so I'm a little fuzzy). Anyhow, as of this update, it's causing the whole second level of navigation to just not render which isn't good!
My question is did something change that would cause this, and if so can I remove the .hiddenparameter safely? Or maybe the syntax changed? I'm still looking but haven't found anything related to this yet.
Existing code example below:
<li class="dropdown {{ craft.app.request.segments|first == 'about' ? 'current' }}"><a href="{{ url('about') }}">About</a>
{% set topEntry = craft.entries.level(1).slug('about').one() %}
<ul id="nav_sub">
<li><a href="{{ url('about') }}">History</a>
{% nav subEntry in topEntry.getDescendants.hidden('not 1').level(2).all() %}
<li><a href="{{ subEntry.url }}">{{ subEntry.title }}</a></li>
{% endnav %}
</ul>
</li>
Craft doesn’t have a hidden entry query param. Guessing that’s a Lightswitch field.
We did fix a bug in 3.4.13, where Lightswitch query params were assuming that elements without a value explicitly set should be treated as disabled — even if the default value was enabled (see #5866). Guessing that’s what’s affecting you here, and you should be able to fix by editing your “Hidden” Lightswitch field and change its default value to disabled.
So you're right it is a lightswitch field that I'm using to hide or show entries in the navigation.
However, the default value was already set to disabled, and even after re-saving the lightswitch field AND re-saving a few entries AND re-saving the whole section AND clearing template caches, I'm still not seeing the pages in my navigation (you turn the lightswitch "on" to hide the page from the navigation).
The lightswitch should have already had a value if it was "off" when these pages were created years ago. Maybe something else is going on here related to that bug?
I've just upgraded from Craft 3.4.11 to 3.4.13 and my primary nav has disappeared.
I tried @brandonkelly suggestions, but this didn't bring back my nav.
I'm using a light switch field that is disabled by default. It's attached to an entry. If it's enabled on the entry, it's hidden.
I then use an element query like this to show non hidden entries:
{% set navigation = craft.entries()
.section('navigation')
.toggleHidden('not 1') << light switch field
.level(1)
.all()
%}
Removing the single quotes around not 1 seems to get my navigation back @jonlongnecker - not sure if that's a legit fix :)
.toggleHidden(not 1)
Yeah looks like there’s a bug here. Working on a fix and will get 3.4.14 out asap.
Removing the single quotes "fixes it" for me, too. But like @jonleverrier says I'm not sure if that's a legit fix. I'll put everything back to normal for now and wait for 3.4.14...
I had forgotten people were using 'not 1' syntax to search for disabled values. You could swap that string out for boolean false and get the expected result:
.hidden(false)
not 1 (no quotes) is a Twig condition that would equate to not true, or in other words, false. So that explains why removing the quotes works for you.
Hahaha my brain is mush after dealing with new Google event properties all day. Soooo....do I need to change my syntax now or will an update let it keep working?
I’d change it to .hidden(false) since that’s more clear than 'not 1' anyway. Last comment was just explaining why “removing the quotes” was working for you (because not 1 equates to false, just a more verbose way of saying the same thing).
Craft 3.4.14 is out now with a fix for the 'not 1' (with quotes) syntax, as well as ':empty:'.
(We’ve been referring to “3.4.14” this whole time, but the latest release was actually 3.4.13.)
Most helpful comment
I’d change it to
.hidden(false)since that’s more clear than'not 1'anyway. Last comment was just explaining why “removing the quotes” was working for you (becausenot 1equates tofalse, just a more verbose way of saying the same thing).