Light switch default behavior seems unexpected

[dlindberg]

Recognizing that it is probably too late to change this behavior, the current setup seems really weird and unintuitive.

Logically if a light switch filed doesn't exist on an entry type the position should be assumed false not whatever the default for the filed happens to be for the purpose of a database query.

Example, we have an entry type that has a special mode that when true should exclude it from a feed. None of the other entry types have this mode as it should always be false for them. But new special entries should start out in the special mode, so the filed default should be true. But it cannot be true by default, which is not ideal for users, and be able to have this work. It seems logical to assume a field that doesn't exist would return null for an entry type .Either that, or add a configurable option for how the filed should be treated when queried on entry types that don't have it. But the current behavior seems a lot more like a bug than anything else.

[brandonkelly]

If a field doesn’t exist in a field layout, it doesn’t get a property on the element either, so you’d actually get an error if you tried to access the lightswitch value when Dev Mode is enabled (and Twig is set to strict mode); or it would be null if Dev Mode is disabled.

[dlindberg]

Hmm, that doesn't seem to be what happens. And it seems like it is following what the documentation says for light switch.

Doing:

{# Fetch entries with the Lightswitch field enabled #}
{% set entries = craft.entries()
  .myFieldHandle(false)
  .all() %}

If the default value of myFieldHandle is set to false, it will include all entries that don't have .myFieldHandle as a field as well as entries that have it set to false. If you set default to true it will exclude all entries but those that have the field explicitly set to false. That seemed to happen in dev mode strict as well. And I think by the documentation is what it is supposed to do. But the behavior is a bit unintuitive and it would be nice to separate the default value and the how it gets treated in a query when it doesn't exist.

[brandonkelly]

Sorry… I missed that this is in the context of a database query.

Unfortunately there’s no performant way to fix this. You could solve it by explicitly listing the entry types you care about retrieving via the type entry query param.

[dlindberg]

Ahh, that makes sense. In the current situation I can't quite do that. Basically I have a news feed with a regular news type and a special news type (that has a bunch of other stuff it can do). And the light switch basically controls when the special news items are special. When they aren't special they should just show up like regular news. Would using an orWhere on the entry type do what I'm expecting?

[brandonkelly]

That could work.

{% set specialType = craft.app.entries.getEntryTypeByHandle('mySpecialType') %}
{% set lsField = specialType.fieldLayout.getFieldByHandle('myLightswitchField') %}

{% set entries = craft.entries()
  .andWhere([
    'or',
    {
      'entries.sectionId': ['foo', 'bar']|map(h => craft.app.entries.getSectionByHandle(h).id),
    },
    {
      'entries.sectionId': craft.app.entries.getSectionByHandle('baz').id,
      (lsField.getValueSql()): true,
    },
  ])
  .all() %}

[dlindberg]

Thanks, this approach worked and seems to work pretty well.